opschain server migrate up
Included from Basic tier
Applies pending migrations directly against the configured database — the
exact migration half of server startup, run without the server. On
PostgreSQL that includes the empty-database bootstrap (the embedded base
schema before the goose migrations); on embedded SQLite it creates the
database file on first use, exactly as server start would.
up honours the same goose ordering rules as startup and adds no
override startup itself would refuse: an out-of-order hole (a migration
below the database's maximum applied version that was never applied — the
incident class this lane exists for) refuses the apply with goose's
missing-migrations error, the same refusal the boot raises. Repairing such
a database is opschain admin database migrations apply on a booted
server (held open with OPSCHAIN_SKIP_MIGRATION_VERIFY=1 if need be), or
a restore — never a silent out-of-order apply. A clean run records every
applied version in the migration ledger as proven and prints one
applied <version> (<name>) line each, matching the server-side apply
verb's output; a current database answers nothing to apply.
Run up only while the server is stopped — it is the same migration run
the next server start would perform, just survivable when that start is
refusing.
Exit codes
| Code | Meaning |
|---|---|
| 0 | Every pending migration applied (or nothing was pending). |
| 1 | The apply failed or was refused (out-of-order hole, integrity findings, unreachable database). |
| 2 | Usage error — no config.yaml at the resolved server home. |
Examples
opschain server migrate up
opschain server migrate up --home /var/lib/opschain
See also
opschain docs cli/server-migrate-status— confirm the verdict is clean afterwards.opschain docs cli/admin-database-migrations-apply— the server-side apply, including single-step rehearsals and hole repair.