Documentation Index
Fetch the complete documentation index at: https://mintlify.com/prisma/prisma-next/llms.txt
Use this file to discover all available pages before exploring further.
prisma-next migration ref manages named refs stored in migrations/refs.json. A ref is a named pointer to a contract hash — analogous to a git ref — that lets you label specific points in the migration graph with meaningful names like staging or production. Commands such as migration apply --ref and migration status --ref use these refs to target a specific graph position rather than always advancing to the latest contract hash. This makes it straightforward to operate staging and production databases that track different points in the same migration history.
Subcommands
ref set
Assign a contract hash to a named ref. Creates the ref if it does not exist; updates it if it does.The ref name to create or update. Must be lowercase alphanumeric with hyphens or forward slashes (e.g.,
staging, prod/us-east). No . or .. path segments are allowed.The contract hash to assign. Must be a valid
sha256:<64 hex chars> hash or the special value sha256:empty.Path to
prisma-next.config.ts. Defaults to ./prisma-next.config.ts.Emit a machine-readable JSON envelope.
Quiet mode — suppresses all output except errors.
ref get
Print the hash that a named ref currently points to.The ref name to look up.
Path to
prisma-next.config.ts. Defaults to ./prisma-next.config.ts.Emit a machine-readable JSON envelope.
Quiet mode — suppresses all output except errors.
ref delete
Remove a named ref fromrefs.json. Has no effect on the migration packages or the database.
The ref name to delete.
Path to
prisma-next.config.ts. Defaults to ./prisma-next.config.ts.Emit a machine-readable JSON envelope.
Quiet mode — suppresses all output except errors.
ref list
List all refs currently stored inmigrations/refs.json.
Path to
prisma-next.config.ts. Defaults to ./prisma-next.config.ts.Emit a machine-readable JSON envelope.
Quiet mode — suppresses all output except errors.
Ref naming rules
Ref names must match the pattern: lowercase alphanumeric characters, hyphens (-), and forward slashes (/). Forward slashes allow hierarchical names for multi-region or multi-tier environments.
Valid names:
Ref value format
All ref values must be valid contract hashes in the formsha256:<64 hex chars>, or the special value sha256:empty (used for the initial state before any migration has been applied).
Atomic writes
refs.json is written atomically via a temp file followed by a rename. This prevents refs.json from being observed in a partially-written state if a concurrent write or process interruption occurs.
Multi-environment workflow
The typical pattern is to keep refs aligned with your deployment pipeline. After validating migrations in staging, update thestaging ref to the new hash, then later advance production once the release is confirmed.
Advance the staging ref
Record the new state for staging in Commit
refs.json:migrations/refs.json to version control alongside the new migration packages.