Skip to main content
crewship db operates on the local SQLite database in the configured data directory. It does not perform maintenance on a remote server selected with --server, a profile, or CREWSHIP_SERVER; it prints a notice when those settings point elsewhere. Stop crewshipd before commands that write or replace the database. The commands are host-side operations and do not require an API session.

​
crewship db migration-status

Reads the local migration ledger and reports the applied schema version plus outstanding post-deployment migrations. It is read-only and can run while the server is stopped.

​
crewship db repair-ledger

Repairs a migration version collision after a migration was renumbered. It moves ledger version numbers only; it does not change table data or schema.
--dry-run is read-only and may be used while the server is running. Applying the repair refuses to proceed while the database is in use — see When the in-use check cannot answer. The command fails closed when the ledger names a migration unknown to the current binary; that case requires a newer binary or a snapshot restore.

​
crewship db restore-snapshot

Restores a pre-migration snapshot created beside the local database. Before an actual restore, the current database is copied to a reversible .before-restore-* file. Stop the server first.
Restoring is the database half of a downgrade: run the matching older binary afterwards. A remote --server target does not change which local file this command operates on.

​
When the in-use check cannot answer

Both commands ask the database file itself whether anything is holding it open, rather than probing a port — a server on a non-standard port used to sail straight through. The probe is checked twice: once up front, and again immediately before the write, because the confirmation prompt is unbounded and a supervised crewshipd can come back while you are reading it. There are three outcomes, and --force only lifts one of them: “Cannot tell” is mostly one situation: a database corrupt enough that it cannot answer the probe — file is not a database (26) — which is exactly the state a snapshot restore exists for. Check that no crewshipd is running, then re-run with --force.