Source: https://www.hype-stack.dev/docs/backend/migrations

# Migrations

Prisma owns the migration workflow. Local development uses `migrate dev`. Production deploys use `migrate deploy` (wired
into [`deploy`](/docs/cli/deploy) as a release / pre-deploy step).

## Day-to-day commands

From the project root:

```bash
# Create a migration from schema changes and apply it locally (prisma migrate dev)
pnpm --filter @hype-stack/backend migration:create

# Apply committed migrations without prompting (prisma migrate deploy). CI and production
pnpm --filter @hype-stack/backend migration:latest

# Drop and rebuild the local database from the migrations
pnpm --filter @hype-stack/backend migration:reset

# Open Prisma Studio against your local database
pnpm --filter @hype-stack/backend exec prisma studio
```

The scripts live in `apps/backend/package.json`. [`deploy`](/docs/cli/deploy) runs `migration:latest` as the release
step on Fly and Railway.

## After installing a pack

`compose` and `template` drop each pack's `.prisma` files into `apps/backend/prisma/schema/` and, when the packs added
models, offer to run `prisma migrate dev` right there. Packs ship models, never migrations, so the migration is
generated against your project's own history.

If you declined, or ran with `--yes` before the database was up:

1. Inspect the merged schema under `apps/backend/prisma/schema/`
2. Run `pnpm --filter @hype-stack/backend migration:create`
3. Confirm the generated client and Kysely types still typecheck

Skipping this step is the most common "tables do not exist" failure after adding auth, billing, or teams.

## Seed data

When the project defines a seed script:

```bash
pnpm --filter @hype-stack/backend exec prisma db seed
```

Seeds are for local and demo data. Do not treat seed SQL as the production source of truth for roles or tenants.

## Staging and production discipline

Before a production deploy:

1. Generate migrations intentionally on a feature branch
2. Review the generated SQL
3. Apply with `migrate deploy` (or let `hype-stack deploy web` run it)
4. Verify the app against the migrated schema

Never point a local `migrate dev` at a shared staging database. That command can reset and rewrite history.

## Related

- [Prisma and Kysely](/docs/backend/prisma-kysely) for when to use each tool
- [Deploy](/docs/cli/deploy) for how Fly and Railway run migrations
- [Going to production](/docs/getting-started/going-to-production) for the full checklist
- [Troubleshooting](/docs/development/troubleshooting) if migrate cannot connect