opschain server migrate
Included from Basic tier
The offline database maintenance lane. opschain admin database migrations rides the server's API, so the one scenario where migration
introspection matters most — the server refusing to boot on a migration
problem — is exactly when it is unavailable. These verbs run in the same
binary, read the database connection from the server host's own
config.yaml ($OPSCHAIN_HOME/server/config.yaml, resolved via --home;
host access, not API access, is the trust boundary), and connect straight
to the store — PostgreSQL or embedded SQLite — with no running server and
no new credential surface.
| Subcommand | Purpose |
|---|---|
status | The migration integrity verdict, read-only; exit 1 on any finding — opschain docs cli/server-migrate-status. |
list | Every migration with its ledger verdict, read-only — opschain docs cli/server-migrate-list. |
up | Apply pending migrations exactly as server startup would — opschain docs cli/server-migrate-up. |
The output shapes match the server-side verbs
(opschain admin database migrations list|status|apply), so runbooks can
cite either. status and list are read-only and safe against a running
server; run up only while the server is stopped. There are no
destructive verbs here — recovery beyond up is a deliberate manual
operation.
The recovery recipe (server down → status to see the refusal's cause →
fix → up or restart) is in opschain docs database-maintenance.
See also
opschain docs cli/admin-database-migrations— the same verbs through the API of a healthy server.opschain docs database-maintenance— the offline recovery recipe and theOPSCHAIN_SKIP_MIGRATION_VERIFY=1emergency escape hatch.