how do people actually run d1 migrations in production, is wrangler apply it Wrangler

Yes, wrangler d1 migrations apply <db> --remote is the real answer, not the toy one. The setup most teams converge on:

• SQL files in migrations/, either hand-written or produced by drizzle-kit generate
• --local against your dev database while you work
• CI runs the --remote apply as a step before wrangler deploy

Two things to internalise coming from Rails.

There is no down migration. Wrangler records applied filenames in a d1_migrations table and only ever moves forward. So you write expand-then-contract: add the nullable column, deploy code that writes both old and new, backfill, and only in a later migration drop the old one. A rollback is a new migration, always. This feels primitive for about a month.

And take an export before anything destructive:

wrangler d1 export app-db --remote --output backup.sql

It is slow and you will be glad exactly once, which is enough.

From CI, never from a laptop — that answers your last question and it is the one with the most consequences. The moment two people can apply migrations from their own machines you get a schema nobody can reconstruct from the repository, and you find out during an incident.

drizzle-kit and D1 work well together and it is not either/or. drizzle-kit generate writes plain SQL into your migrations folder and wrangler applies it — you keep typed queries and the migration is still a file a human can read in review. That readability matters more than it sounds when someone has to approve a schema change at 6pm on a Thursday.

One trap specific to this setup: anything in the migrations folder gets applied, including a seed.sql someone dropped in there for convenience. If that file starts with DELETE FROM, it will do exactly what it says against production the first time CI runs the apply. Keep seed data outside migrations/ and run it with an explicit separate command.

Coming from Rails you will miss the schema dump more than the rollbacks — there is no single file you can open to see the current shape of the database. Generate one in CI after applying and commit it, purely so code review can see what changed.