Skip to main content
prisma-next migration apply executes previously planned migrations against a live database. It does not plan new migrations — run migration plan first to produce the packages. The command reads all attested packages from disk, reconstructs the migration graph, finds the shortest path from the current database marker to the destination hash, and executes each pending migration in order. Every migration runs in its own transaction with prechecks, postchecks, and idempotency checks enabled.

Options

string
Database connection string. Defaults to config.db.connection if set in prisma-next.config.ts. Required if not set in config.
string
Target a named ref from migrations/refs.json instead of the current contract hash. Enables multi-environment workflows where staging and production track different points in the migration graph.
string
Path to prisma-next.config.ts. Defaults to ./prisma-next.config.ts in the current working directory.
boolean
Emit a machine-readable JSON envelope instead of the default TTY output.
boolean
Quiet mode — suppresses all output except errors.
boolean
Verbose output — includes debug info and timings.

Config requirements

The migration apply command requires a driver in prisma-next.config.ts to connect to the database. A db.connection value or a --db flag must also be provided.

What it does

1

Load and verify migration packages

Reads every migration package from config.migrations.dir. Each package is attested — the loader rehashes (metadata, ops) and confirms the result matches the stored migrationHash. If a package has been hand-edited or partially written since emit, loading fails with MIGRATION.HASH_MISMATCH.
2

Reconstruct the migration graph

Builds a directed graph from all loaded packages using their start and end contract hashes as edges.
3

Determine the destination hash

If --ref <name> is provided, resolves the ref’s hash from migrations/refs.json. Otherwise reads the destination hash directly from contract.json.
4

Connect and read current marker

Opens a database connection using config.driver.create(url) and reads the current marker hash to determine where the database currently sits in the migration graph.
5

Find the path

Uses graph pathfinding to determine the shortest sequence of migration edges from the current marker hash to the destination hash.
6

Execute pending migrations

Runs each pending migration in order. Each migration executes in its own transaction with prechecks, postchecks, and idempotency checks enabled. After each migration the runner verifies the schema and updates the marker and ledger.

Hash attestation

Every migration package on disk is content-addressed. When migration apply loads a package, it independently recomputes the hash over (metadata, ops) and compares it against the stored migrationHash. If they differ — because the file was hand-edited, partially written, or corrupted — the load fails immediately:
Never hand-edit ops.json or migration.json directly. If you need to change the operations in a migration, edit migration.ts and re-run node migrations/<dir>/migration.ts to re-attest the package.

Resume semantics

If a migration fails mid-run, previously applied migrations are preserved. Re-running migration apply resumes from the last successfully applied migration — it will not re-execute migrations that already advanced the database marker.

Ref-based routing

--ref <name> targets the hash associated with a named ref rather than the current contract hash. This is the primary mechanism for multi-environment workflows:
Refs are managed with migration ref set/get/delete/list. See migration ref for details.

Examples

Output format

TTY (migrations applied):
TTY (already up to date):
JSON output: