repost schema push sends the current schema to an environment without recording a migration, the equivalent of Prisma's db push. It is meant for development and staging loops where the schema changes faster than you want to version it.
The server refuses a push to any environment that already has migration history, so a push can never fork a production lineage. Pushing an unchanged schema is a no-op.
Usage#
repost schema push [options]Options#
| Option | Description |
|---|---|
--dry-run | Print the payload instead of sending it. Never touches the network. |
--schema <path> | A .repost file or a directory of them. Defaults to ./repost/schema.repost, else ./repost/schema/. |
There is deliberately no --force: replacing deployed migration history from a dev loop is exactly the mistake the deploy protocol exists to prevent. Authentication works like migrate deploy: .env is loaded, REPOST_TOKEN is required, and REPOST_API_URL overrides the API host.
Example#
repost schema push✔ deployment applied
created: user.createdA repeat push of the same schema prints ✔ already up to date. Pushing to an environment with migration history is rejected by the server, and the CLI prints the rejection with its reason.