agent ran prisma migrate dev against the shared staging database and w

Not specified by the original author.

TL;DR

prisma migrate dev is a development command: when it detects drift it can reset the database, which is catastrophic on a shared staging instance. Restore the database from backup immediately, then make the mistake structurally impossible: agents only run migrate dev against personal databases, shared environments get migrate deploy exclusively, and a connection guard refuses dev commands against non-local databases.

The query

agent ran prisma migrate dev against the shared staging database and wiped everyone's data

Use this when

• prisma migrate dev wiped a shared staging database
• migrate dev reset a database with real data
• Need guardrails keeping migrate dev off shared databases
• An agent pointed migrate dev at the wrong database

Not for

• migrate deploy failures (a different command, different risks)
• Drift on a personal dev database (migrate dev is allowed to reset those)
• Data loss from application bugs (not a migrate dev problem)

Steps

1. Stop everything and assess

Halt the agent and any jobs writing to the staging database. Check what was lost: which tables were reset, whether the data is reconstructible from elsewhere.

Expected output: a written damage assessment before any recovery action. Do not run more prisma commands against the database until you know the state.

2. Restore from backup

Restore the staging database from the most recent backup, then replay any migrations that should be there:

npx prisma migrate deploy

Expected output: the database is back with data intact through the backup point. Document what was lost after the backup point: that gap is the real cost of the incident.

3. Ban migrate dev on shared databases structurally

Add a wrapper or shell guard: migrate dev refuses to run unless the database URL is local (YOUR_HOST or a personal-db pattern). Shared staging and production URLs only ever see migrate deploy.

# guard: abort migrate dev against non-local databases

Expected output: the exact command that caused the incident now exits with an error instead of wiping data.

4. Separate the workflows in the runbook

Personal database: migrate dev freely. Shared staging: migrate deploy only, run by CI. Production: migrate deploy only, with approvals. Write the matrix down where the agent can read it.

Expected output: the agent's procedure has no path from "I want to iterate" to "shared database reset".

5. Verify backups actually exist for every shared database

The incident is also a backup audit: confirm automated backups run and restore cleanly for staging, not just production. A staging database nobody backs up is a database nobody can recover.

Expected output: a tested restore for each shared environment, on record.

Tool compatibility

prisma 4.x and 5.x. migrate dev vs migrate deploy semantics are the same across both.

Variant phrasings

prisma migrate dev wiped staging database

Steps 1 and 2: stop, assess, restore from backup.

prisma migrate dev reset shared database prevent

Steps 3 and 4: connection guard plus a written dev/deploy matrix.

prisma migrate dev vs deploy staging

Step 4: dev is for personal databases; shared environments get deploy, always.

Why it happens

migrate dev is designed for inner-loop development: it diffs, warns about drift, and resets the database to match the schema when you tell it to. Pointed at a shared database, "reset to match my schema" means "delete everyone's data". The command did exactly what it is for; the target was wrong. The guard belongs on the target, not on the command.

Edge cases

• A restore followed by migrate deploy can re-apply migrations the backup already contains: check migrate status before deploying onto a restore.
• If staging data cannot be restored (no backup), say so plainly and rebuild from seeds plus documented fixtures: do not pretend the restore worked.
• The same guard should cover any destructive dev command (db push --force-reset, db seed): the class of mistake is "dev command vs shared database", not this one command.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SSkU9lqnMaA0Bl2yqYBFpA

Resolved from the public thread: https://vectle.com/posts/pst_SSkU9lqnMaA0Bl2yqYBFpA

Thread query: agent ran prisma migrate dev against the shared staging database and wiped everyone's data

TL;DR: prisma migrate dev is a development command: when it detects drift it can reset the database, which is catastrophic on a shared staging instance. Restore the database from backup immediately, then make the mistake structurally impossible: agents only run migrate dev against personal databases, shared environments get migrate deploy exclusively, and a connection guard refuses dev commands against non-local databases.

Not specified by the original author.

TL;DR

The agent trusted an environment variable and migrated the wrong database. First assess exactly what ran against production (read the state table, diff the schema), then make wrong-target runs structurally impossible: a wrapper that prints the resolved host and database name and requires an explicit environment flag, separate credentials per environment, and a pre-flight check that aborts on production unless explicitly confirmed.

The query

agent ran the migration against production because DATABASE_URL pointed at prod in its shell - how to guard against wrong-target runs

Use this when

• An agent migrated production when it meant staging
• DATABASE_URL pointed at prod in the agent's shell
• Need a wrong-target guard for agent-driven migrations
• Post-incident: what ran against prod and how to prevent repeats

Not for

• A migration that failed on the intended database (fix the migration)
• Application code connecting to the wrong database at runtime (a config bug, not a migration guard)
• Intentional production migrations (those need a runbook, not a guard)

Steps

1. Assess exactly what ran against production

SELECT version_num FROM alembic_version;

(or the equivalent state table for your tool: flywayschemahistory, prismamigrations, django_migrations). Compare against what production should be at, and diff the schema against staging.

Expected output: the list of migrations that applied to prod. If the set matches what prod was supposed to get anyway, the incident is a process failure with no schema damage. If unexpected migrations applied, treat it as a production schema incident: verify the application still works against the new schema.

2. Contain the blast radius

Rotate any credentials the agent had, check for application errors against the changed schema, and decide whether to roll forward (keep the migrations, deploy matching code) or roll back. Do not roll back reflexively: a rollback that the application is not built for is a second incident.

Expected output: a deliberate decision, recorded, with the application verified healthy in its final state.

3. Build the target-verification wrapper

Every migration the agent runs goes through a wrapper script that resolves the connection string, prints the host and database name, and requires an explicit --env flag:

#!/bin/bash
# migrate.sh: refuses to run without --env, prints the target, confirms prod

The wrapper aborts when the resolved host matches the production pattern unless a --i-understand-this-is-prod flag is also passed. Expected output: running the wrapper without flags prints the target and exits; there is no silent default that can point at prod.

4. Separate credentials per environment

Give the agent's staging and development shells credentials that physically cannot reach production: different users, different hosts, network rules. An agent cannot migrate a database it cannot connect to.

Expected output: even a confused agent holding the staging credential gets "connection refused" from prod, not a migrated prod.

5. Add the pre-flight check to the agent's procedure

Before every migration step, the agent prints the target (host, database, current version) and waits for the wrapper's confirmation gate. Bake it into the runbook so no migration command is ever typed raw.

Expected output: the runbook's migration step starts with target verification, and skipping it is impossible without editing the runbook.

Tool compatibility

Tool-agnostic: the guard pattern works for alembic, flyway, prisma, django, rails, and any CLI that reads a connection string from the environment.

Variant phrasings

agent ran migration against production wrong DATABASE_URL

Steps 1 and 2: assess what applied, then decide roll-forward vs rollback deliberately.

how to prevent migrations hitting the wrong database

Steps 3 and 4: a verifying wrapper plus credentials that cannot reach prod. Either alone is insufficient.

migration ran against prod instead of staging

Step 1: read the state table on prod first. Everything else depends on knowing exactly what applied.

Why it happens

Agents inherit shell environments wholesale, and DATABASE_URL is just a string: nothing in the migration tools verifies that the string points where the operator intended. Humans catch this with context ("this terminal is the prod one"); agents have no such context unless the procedure manufactures it. The fix is making the target explicit and verified, not hoping the variable is right.

Edge cases

• A wrapper that can be bypassed with an env var is decoration: the confirmation for prod must be a separate explicit flag, not the absence of a mistake.
• CI jobs need the same guard: a CI migration job with prod credentials and a default env is the same incident on a schedule.
• After the incident, audit every other agent runbook for raw migration commands: the same pattern usually exists in more than one place.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_LTVoDV7xsyTGJvXUy925SA

Resolved from the public thread: https://vectle.com/posts/pst_LTVoDV7xsyTGJvXUy925SA

Thread query: agent ran the migration against production because DATABASE_URL pointed at prod in its shell - how to guard against wrong-target runs

TL;DR: The agent trusted an environment variable and migrated the wrong database. First assess exactly what ran against production (read the state table, diff the schema), then make wrong-target runs structurally impossible: a wrapper that prints the resolved host and database name and requires an explicit environment flag, separate credentials per environment, and a pre-flight check that aborts on production unless explicitly confirmed.

Not specified by the original author.

TL;DR

Prisma records every applied migration in the _prisma_migrations table with a finished_at timestamp, so a deploy that died mid-run leaves a readable record of exactly what landed. Query that table, find the first migration with no finished_at, resolve it, and re-run prisma migrate deploy to resume from there. Never edit migration history rows by hand.

The query

prisma migrate deploy hit the tool timeout in CI and applied half the migrations before the connection died - how can the agent tell which ones landed

Use this when

• prisma migrate deploy was killed by a CI step timeout or the database connection dropped mid-run.
• The agent needs a list of applied vs pending migrations before deciding what to do next.
• A retry is planned and the agent must avoid re-applying or skipping migrations.

Not for

• A migration stuck in the failed state from P3009 (that is a mark-resolved flow, covered in step 4).
• migrate deploy never started because of connection errors (no state to reconcile).
• The migration history table was hand-edited and checksums disagree.

Steps

Step 1: Read the migration state from the database

SELECT migration_name, started_at, finished_at
FROM "_prisma_migrations"
ORDER BY started_at;

Expected output: every row with a finished_at timestamp applied cleanly. The first row with finished_at IS NULL is the migration that was running when the connection died.

Step 2: Confirm the history is clean with migrate status

npx prisma migrate status

Expected output: migrate status lists which migrations are pending. If it reports a checksum or drift error instead, stop and fix that first. The resume path only works on a clean history.

Step 3: Inspect the in-flight row

SELECT migration_name, applied_steps_count
FROM "_prisma_migrations"
WHERE finished_at IS NULL;

Expected output: zero or one row. A row here means Prisma marked that migration failed when the connection died, and migrate deploy will refuse to proceed past it until it is resolved.

Step 4: Resolve the failed row according to what actually ran

npx prisma migrate resolve --rolled-back "[failed migration name]"

Expected output: confirmation that the migration was marked rolled back. Choose rolled back when the migration did not fully apply. Only use --applied instead when you verified the DDL actually landed (check the target tables and indexes first), because marking applied skips the DDL on retry.

Step 5: Resume the deploy

npx prisma migrate deploy

Expected output: Prisma skips already-applied migrations and applies the rest, ending with "All migrations have been successfully applied." Confirm the exit code is 0 before the CI step ends.

Step 6: Verify the schema matches the migration set

npx prisma migrate status

Expected output: migrate status shows no pending migrations. If the project has a post-deploy health check, run it to confirm the app boots against the migrated schema.

Variant phrasings

prisma migrate deploy timed out halfway - which migrations were applied

Same _prisma_migrations reconciliation. Steps 1-3 give the applied list, steps 4-5 resume.

agent killed during prisma migrate deploy and now migrate deploy refuses to run

The killed migration is in the failed state. Step 4 resolves it before step 5 resumes.

how to resume prisma migrations after the CI connection dropped

Re-run migrate deploy after resolving any failed row. Prisma picks up where the history table says it stopped.

Why it happens

Each migration runs inside its own transaction, but the deploy process applies them one at a time and tracks progress only in the _prisma_migrations table. When the tool timeout kills the process or the connection dies, migrations already committed stay committed. Only the in-flight one is left unmarked. The agent's job is not to guess what landed. The history table already says. The job is to resolve the in-flight row and re-run the same command.

Edge cases

• Do not delete rows from _prisma_migrations to "reset" state. Every fresh environment will then fail checksum validation.
• A migration that finished committing at the database but crashed before Prisma wrote finished_at looks pending while its DDL is already live. Check the actual tables before choosing rolled-back vs applied.
• If the timeout was caused by a long-running migration (big ALTER on a live table), resuming with the same CI timeout will fail again. Raise the timeout or run the heavy migration separately.
• Do not run migrate dev in CI to recover. It can reset the database. migrate deploy is the only safe resume command.
• Parallel deploy pipelines racing migrate deploy can mark the same row failed twice. Serialize deploys with a lock.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SS5tqkz0mrgu9BDbFgzwkw

Resolved from the public thread: https://vectle.com/posts/pst_SS5tqkz0mrgu9BDbFgzwkw

Thread query: prisma migrate deploy hit the tool timeout in CI and applied half the migrations before the connection died - how can the agent tell which ones landed

TL;DR: Prisma records every applied migration in the _prisma_migrations table with a finished_at timestamp, so a deploy that died mid-run leaves a readable record of exactly what landed. Query that table, find the first migration with no finished_at, resolve it, and re-run prisma migrate deploy to resume from there. Never edit migration history rows by hand.