Deploying migrations

bluep deploy compares a live target with the named model target, probes the database, writes a rollback script, and then submits the generated migration through the installed database client. A dry run writes the same bytes it would submit and never mutates the database.

Use --rollback-out for every deployment. Deploy records its checksum, model revision, actor and outcome in _bluep_deploy_history; statement-at-a-time dialects also use _bluep_deploy_checkpoint. PostgreSQL, SQLite and SQL Server use a whole DDL transaction where supported. Other clients are checkpointed after each statement.

Review reported lock and long-rewrite risks. Destructive changes require --allow-destructive. Rollback scripts restore schema shape only: data removed by a forward migration is not restored. bluep deploy --status prints stable tab-separated history. Exit status 2 is invalid command usage, 1 is a model/preflight failure, and 3 is a client or I/O failure.

Credentials use --password or BLUEP_DB_PASSWORD; the actor is --applied-by, the connection user, or BLUEP_DEPLOY_ACTOR.

bluep deploy models/app --target production --database app.db --rollback-out rollback.sql --applied-by release
bluep deploy models/app --target production --database app.db --status
  • For operating the authenticated local editor behind a proxy, see the team server guide.
  • Stored SQL hooks wrap migrations for touched objects and are attached exactly once before deployment. See Custom generation for ordering and safety details.