# Development and production (/docs/orm/v6/prisma-migrate/workflows/development-and-production) Location: ORM > v6 > Prisma Migrate > Workflows > Development and production This page explains how to use Prisma Migrate commands in development and production environments. Development environments [#development-environments] In a development environment, use the `migrate dev` command to generate and apply migrations: #### npm ```bash npx prisma migrate dev ``` #### pnpm ```bash pnpm dlx prisma migrate dev ``` #### yarn ```bash yarn dlx prisma migrate dev ``` #### bun ```bash bunx --bun prisma migrate dev ``` Create and apply migrations [#create-and-apply-migrations] > [!CAUTION] > `migrate dev` is a development command and should never be used in a production environment. This command: 1. Reruns the existing migration history in the [shadow database](/orm/v6/prisma-migrate/understanding-prisma-migrate/shadow-database) in order to detect schema drift (edited or deleted migration file, or a manual changes to the database schema) 2. Applies pending migrations to the shadow database (for example, new migrations created by colleagues) 3. If it detects changes to the Prisma schema, it generates a new migration from these changes 4. Applies all unapplied migrations to the development database and updates the `_prisma_migrations` table 5. Triggers the generation of artifacts (for example, Prisma Client) The `migrate dev` command will prompt you to reset the database in the following scenarios: * Migration history conflicts caused by [modified or missing migrations](/orm/v6/prisma-migrate/understanding-prisma-migrate/migration-histories#do-not-edit-or-delete-migrations-that-have-been-applied) * The database schema has drifted away from the end-state of the migration history Reset the development database [#reset-the-development-database] You can also `reset` the database yourself to undo manual changes or `db push` experiments by running: #### npm ```bash npx prisma migrate reset ``` #### pnpm ```bash pnpm dlx prisma migrate reset ``` #### yarn ```bash yarn dlx prisma migrate reset ``` #### bun ```bash bunx --bun prisma migrate reset ``` > [!WARNING] > `migrate reset` is a development command and should never be used in a production environment. This command: 1. Drops the database/schema¹ if possible, or performs a soft reset if the environment does not allow deleting databases/schemas¹ 2. Creates a new database/schema¹ with the same name if the database/schema¹ was dropped 3. Applies all migrations 4. Runs seed scripts ¹ For MySQL and MongoDB this refers to the database, for PostgreSQL and SQL Server to the schema, and for SQLite to the database file. > **Note**: For a simple and integrated way to re-create data in your development database as often as needed, check out our [seeding guide](/orm/v6/prisma-migrate/workflows/seeding). Customizing migrations [#customizing-migrations] Sometimes, you need to modify a migration **before applying it**. For example: * You want to introduce a significant refactor, such as changing blog post tags from a `String[]` to a `Tag[]` * You want to [rename a field](/orm/v6/prisma-migrate/workflows/customizing-migrations#example-rename-a-field) (by default, Prisma Migrate will drop the existing field) * You want to [change the direction of a 1-1 relationship](/orm/v6/prisma-migrate/workflows/customizing-migrations#example-change-the-direction-of-a-1-1-relation) * You want to add features that cannot be represented in Prisma Schema Language - such as a partial index or a stored procedure. The `--create-only` command allows you to create a migration without applying it: #### npm ```bash npx prisma migrate dev --create-only ``` #### pnpm ```bash pnpm dlx prisma migrate dev --create-only ``` #### yarn ```bash yarn dlx prisma migrate dev --create-only ``` #### bun ```bash bunx --bun prisma migrate dev --create-only ``` To apply the edited migration, run `prisma migrate dev` again. Refer to [Customizing migrations](/orm/v6/prisma-migrate/workflows/customizing-migrations) for examples. Team development [#team-development] See: [Team development with Prisma Migrate](/orm/v6/prisma-migrate/workflows/team-development) . Production and testing environments [#production-and-testing-environments] In production and testing environments, use the `migrate deploy` command to apply migrations: #### npm ```bash npx prisma migrate deploy ``` #### pnpm ```bash pnpm dlx prisma migrate deploy ``` #### yarn ```bash yarn dlx prisma migrate deploy ``` #### bun ```bash bunx --bun prisma migrate deploy ``` > **Note**: `migrate deploy` should generally be part of an automated CI/CD pipeline, and we do not recommend running this command locally to deploy changes to a production database. This command: 1. Compares applied migrations against the migration history and **warns** if any migrations have been modified: ```bash WARNING The following migrations have been modified since they were applied: 20210313140442_favorite_colors ``` 2. Applies pending migrations The `migrate deploy` command: * **Does not** issue a warning if an already applied migration is *missing* from migration history * **Does not** detect drift (production database schema differs from migration history end state - for example, due to a hotfix) * **Does not** reset the database or generate artifacts (such as Prisma Client) * **Does not** rely on a shadow database See also: * [Prisma Migrate in deployment](/orm/v6/prisma-client/deployment/deploy-database-changes-with-prisma-migrate) * [Production troubleshooting](/orm/v6/prisma-migrate/workflows/patching-and-hotfixing) Advisory locking [#advisory-locking] Prisma Migrate makes use of advisory locking when you run production commands such as: * `prisma migrate deploy` * `prisma migrate dev` * `prisma migrate resolve` This safeguard ensures that multiple commands cannot run at the same time - for example, if you merge two pull requests in quick succession. Advisory locking has a **10 second timeout** (not configurable), and uses the default advisory locking mechanism available in the underlying provider: * [PostgreSQL](https://www.postgresql.org/docs/9.4/explicit-locking.html#ADVISORY-LOCKS) * [MySQL](https://dev.mysql.com/doc/refman/5.7/en/locking-functions.html) * [Microsoft SQL server](https://learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-getapplock-transact-sql?view=sql-server-ver15) Prisma Migrate's implementation of advisory locking is purely to avoid catastrophic errors - if your command times out, you will need to run it again. Since `5.3.0`, the advisory locking can be disabled using the [`PRISMA_SCHEMA_DISABLE_ADVISORY_LOCK` environment variable](/orm/v6/reference/environment-variables-reference#prisma_schema_disable_advisory_lock) ## Related pages - [`Baselining a database`](https://www.prisma.io/docs/orm/v6/prisma-migrate/workflows/baselining): How to initialize a migration history for an existing database that contains important data. - [`Customizing migrations`](https://www.prisma.io/docs/orm/v6/prisma-migrate/workflows/customizing-migrations): How to edit a migration file before applying it to avoid data loss in production. - [`Data migrations`](https://www.prisma.io/docs/orm/v6/prisma-migrate/workflows/data-migration): How to migrate data using Prisma ORM with the expand and contract pattern. - [`Generating down migrations`](https://www.prisma.io/docs/orm/v6/prisma-migrate/workflows/generating-down-migrations): How to generate down migrations - [`Native database functions`](https://www.prisma.io/docs/orm/v6/prisma-migrate/workflows/native-database-functions): How to enable PostgreSQL native database functions for projects that use Prisma Migrate.