Skip to main content
repost schema migrate deploy sends your migration history to an environment, which materializes its event-type registry and answers with the applied diff. It requires a clean local history and refuses any deploy that would lose deployed history.

Usage

Options

Authentication

The command loads the workspace .env (next to or above the schema directory) and then reads: Values already set in the process environment win over .env.

What it does

  1. Validates the schema and builds the payload. No migrations, unmigrated changes, a fork, or a tampered snapshot each abort with instructions; run migrate dev first.
  2. Sends the head, the full lineage, and the accumulated JSON Schemas. The server applies it only when your head descends from the deployed one.
  3. On refusal, the server’s reason is printed: client_behind means pull the newer migrations and redeploy; diverged means merge and reconcile, or use --force.
With --force, the CLI first fetches the deployed head and prints what will be replaced (checksum, kind, migration name, deploy time), then asks Replace the deployed history? [y/N]:. In CI, pass --accept-replace. The reviewed head is sent back as a lease, so a deploy that lands in between makes the server refuse rather than overwrite unreviewed history. Forcing to a previously deployed checksum is the rollback path and prints an extra rewind warning. When --force turns out to be unnecessary, the CLI says so and performs a normal deploy. Exit code 1 on any refusal, unconfirmed replacement, or server rejection.

Examples

Re-deploying the same head:
A refused deploy prints the server’s reason:

Continue

push

The migration-less alternative for development environments.

Migrations & deploys

Ancestry, forks, rollback, and non-destructive archival.

migrate status

Verify the history is deployable before CI runs this.