Vetrix Docs

Vetrix Admin Documentation

Operator and administrator documentation for self-hosted Vetrix. Pages are organized by type. Use the section that matches the surface you are operating.

UI / administration surface

  • Administration Surface — the /api/v1/admin/ surface: health and runner endpoints, the runtime settings store, the security policy it enforces, account administration, and the audit record.

Repositories

  • Repositories — bare repositories on disk and the space they consume, replication to and from remote hosts, and reassigning ownership.

CI/CD

  • CI/CD — the instance-wide settings that govern whether and how jobs run, and the runner and worker wiring a job needs before it can launch containers and return artifacts.

Registry

  • Registry — where blobs land, the tables that index them, who may pull, push, and delete, and the tooling for auditing and reclaiming storage.

Email

  • Email Template System — operator guide — customising, previewing, publishing, exporting, and monitoring the operator-editable templates, including merge fields, bundles, unsubscribe, and the queue.

Maintenance

  • Maintenance — keeping the database recoverable, keeping the search index consistent with the relational store, and moving the deployment onto a new release.

Runbooks

Incident-response and rollout procedures live in the runbook set alongside this one.

Contributing — operator-manual guardrail

These pages are an operator manual. Before opening a pull request, run the manual doc-lint. The command below works from any directory inside a clone:

bash "$(git rev-parse --show-toplevel)/llm-documentation/admin-docs/doc-lint.sh"

The script switches to the repository root itself and scans every tracked Markdown and YAML file, so a single run covers all five documentation sets. Each set holds an identical copy of the script; running any one of them lints the whole tree, so this is not a per-set lint.

The script fails — listing file:line — when an operator-manual rule is violated. The Docs Reviewer enforces the same rules:

  • Use gitvetrix.com as the only product host (the .test dev host is fine).
  • Refer to the platform as Vetrix; do not use the legacy product name.
  • Keep tracker IDs out of the prose.
  • Link to other pages with relative .md paths. A markdown link whose target is an absolute git-host URL (https://www.gitvetrix.com/... or https://gitvetrix.com/...) fails the lint, because it sends the reader out of the manual and into the repository file browser; this is checked case-insensitively across inline links, reference-style link definitions, bare autolinks (a URL wrapped only in < >, no square brackets), and angle-bracket-wrapped destinations, including a userinfo-prefixed form (e.g. https://user:token@ in front of the host). Bare-text host mentions, curl examples and code blocks are unaffected.
  • Write in present-tense operator-manual tone, without decision or history narration.

doc-lint.sh must pass before review.