[Overview](/docs)[Installation](/docs/installation)[Architecture](/docs/architecture)[Integrations](/docs/integrations)[First review](/docs/review)[Operations](/docs/operations)[Acceptance](/docs/acceptance)

# Operations playbooks.

Observe state. Preserve data. Reconcile uncertain outcomes.

## After startup

- Verify TLS and readiness for every role, its PostgreSQL binding and migration status.

- Sign in with real SSO, access only the allowed tenant and run a negative cross-tenant case.

- Verify an allowed MR read, a model call and a useful MCP response. HTTP200 alone is insufficient.

- Record baseline memory, queue latency and disk usage. Set provider budgets and alerts before broad activation.

## Unknown publication outcome

Signals: a timeout after a GitLab call, started/unknown state or a lost reply. Do not click publish, approve or CI again. Reconcile the saved action, SHA, discussions, approvals and pipeline with GitLab. Decide on a retry only after reconciliation, preserving the audit trail. Do not paste secrets or source code into shared tickets.

## Backup and restore

Assign backup ownership, RPO/RTO and retention. Back up the separate PostgreSQL databases and protected configuration consistently. Keep credentials separately with restricted access. Restore into an isolated target and verify history, tenant isolation, migrations and duplicate-publication prevention. A backup file is not a tested restore.

## Inspect public certificates

The operator supplies exact public CA and server-certificate paths. These templates read certificates, not the private key. Validity dates and chain checks do not replace hostname, certificate-usage and live TLS-handshake verification. Never disable TLS checks to bypass a failure.

```sh
set -eu
: "${NULL_CA_FILE:?Set the explicit public CA certificate path}"
: "${NULL_SERVER_CERT:?Set the explicit public server certificate path}"
openssl x509 -in "$NULL_CA_FILE" -noout -dates -checkend 86400
openssl x509 -in "$NULL_SERVER_CERT" -noout -dates -checkend 86400
openssl verify -CAfile "$NULL_CA_FILE" "$NULL_SERVER_CERT"
```

## Restart and upgrade

Before restarting, record queue state and unfinished actions. Afterwards verify history integrity, permissions and duplicate prevention. The current create-only bootstrap does not perform upgrades or rollbacks. An upgrade plan needs compatible migrations, backup and a separately verified target. Do not use down -v or manually stamp migrations to bypass failures.

## Capacity and machine sizing

The initial team target is up to 100 repositories, 500 MR per day and 5 concurrent reviews. These are requirements, not a load-test result. The initial planning reservation below is neither a minimum nor a performance guarantee. GitLab, IdP, runner, backup and any local model are accounted for separately.

| Role | CPU / RAM | Storage hypothesis  |
| --- | --- | --- |

| Application | 4vCPU / 8GiB | 80GiB SSD  |

| Worker + Context | 8vCPU / 16GiB | 100GiB OS + retention-sized data  |

| PostgreSQL | 4vCPU / 16GiB | 200GiB SSD  |

Before sizing sign-off, measure five overlapping real reviews, queue latency, provider quotas, CI duration, cost and data growth. A test with doubles does not replace that wave.