opschain admin database migrations
Included from Basic tier
Migration integrity: the server records every applied migration's
name and content SHA-256 in a migration_ledger table beside goose's
version table, and verifies that ledger against its own embedded migration
set on every boot — so a renumbered or edited migration fails the boot
loudly instead of surfacing as request-time internal errors. These verbs are
the same machinery on demand, server-side, against whichever store the
server runs (PostgreSQL or embedded SQLite).
| Subcommand | Purpose |
|---|---|
list | The binary's migrations with per-version applied/pending/mismatched state and the assumed-backfill flag — opschain docs cli/admin-database-migrations-list. |
status | The verification verdict; exit 1 on any finding — opschain docs cli/admin-database-migrations-status. |
apply | Apply pending migrations in order (--all, or --id for exactly the next pending version) — opschain docs cli/admin-database-migrations-apply. |
Versions applied before the ledger existed are backfilled at boot from the binary's set and marked assumed: their historical content cannot be proven, so they verify by name only — which is exactly the signal a renumber moves.
Like every database verb, these authenticate with the admin bearer
(--auth-token, then OPSCHAIN_ADMIN_TOKEN, then the token stored by
opschain admin login) against --server, OPSCHAIN_SERVER or the active
context.
See also
opschain docs database-maintenance— the integrity story, the boot failure text and theOPSCHAIN_SKIP_MIGRATION_VERIFY=1escape hatch.