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
Themigration 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. Whenmigration 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:
Resume semantics
If a migration fails mid-run, previously applied migrations are preserved. Re-runningmigration 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:
migration ref set/get/delete/list. See migration ref for details.