Record a change
migrate dev diffs your schema against the last migration. When something changed, it writes a timestamped snapshot under repost/migrations/, bumps the version of each affected event type, and regenerates your client. When nothing changed, it does nothing. The migration directory is committed, so every schema change shows up in git diff and code review.
Each migration records its parent and a checksum of its snapshot, which lets the CLI verify the whole history.
Merging branches
Two branches that each ranmigrate dev merge cleanly in git, since migration directories are timestamp-prefixed and don’t collide. After the merge the history briefly has two heads, called a fork. Commands that read migrations detect this and fail with the names of both directories rather than guessing.
To resolve a fork, run repost schema migrate dev once on the merged schema. It diffs against each parent, prints what each branch contributed, and writes a single reconciling migration that records both parents. Commit it.
Check it in CI
migrate status exits non-zero on a fork, on unmigrated changes (the schema is ahead of the recorded history), or on a hand-edited snapshot (checksum mismatch). It exits 0 when the history is clean. Run both commands on every pull request.
Deploy
REPOST_TOKEN, an environment-scoped token with the schema:deploy scope, read from repost/.env before the process environment. REPOST_API_URL overrides the API host. Pass --dry-run to print the payload instead of sending it.
The ancestry check
The server refuses any deploy whose head does not descend from what is already deployed, so production history can never be lost by accident.
Every deploy records which token performed it and whether it was forced.
Forcing and rolling back
Some histories can never fast-forward: you squashed your migrations, re-initialized the directory, or restored from another repo.repost schema migrate deploy --force replaces the deployed history. Before doing anything it fetches the deployed head, prints exactly what will be replaced, and asks for confirmation (--accept-replace in CI).
Force is checked against the head you were shown. If another deploy moved it in the meantime, the server refuses instead of overwriting a head nobody reviewed. Forcing to an older, previously deployed checksum is the supported rollback path.
Archival is non-destructive. Event types removed by a deploy are archived, not deleted; they still accept publishes and still deliver. A wrong deploy or a rollback never drops in-flight traffic, and redeploying the correct head restores the registry.
Development loops
push sends the current schema without writing a migration, like Prisma’s db push. It is intended for development and staging, and it is refused on environments that already have migration history, so it can never fork production. Pushing an unchanged schema does nothing.
Importing from Svix
repost schema import svix export.json converts a Svix environment export into a repost/ workspace: one catalog member and event binding per event type, a payload model per schema, and an initial migration that preserves the source’s version history. Names are kept verbatim. Anything that cannot be represented is reported as an error listing every case, rather than being silently changed.
Continue
SDKs
Your events are live. Generate a client and publish.
Schema CLI reference
Every
repost schema command and flag.Event docs
Each deploy rebuilds your customer-facing event documentation.