ChatGPT Sites + D1 + Drizzle migrations: how does Sites know which migration to apply?

[bringamosa29]

I’m using ChatGPT Sites with a Sites-managed Cloudflare D1 binding called DB, and the project uses Drizzle-generated SQL migrations.

The deployment package currently contains:

• .openai/drizzle/0000_...sql
• .openai/drizzle/0001_...sql

Production already reflects the schema from 0000, but I cannot find any visible migration ledger such as a d1_migrations table, and Sites does not expose the underlying production D1 database name/UUID.

The next migration (0001) is additive and adds three columns to an existing newsletter_signups table.

What is confusing me is that I’ve seen two different directions:

1. Current Sites guidance says generated Drizzle migrations own production schema changes and are applied before Worker upload.
2. Support previously suggested that, because Sites exposes no standalone production migration action, the workable pattern is app-managed runtime migrations with an idempotent/fail-closed readiness gate.

Those two models seem incompatible unless Sites has its own hidden migration-tracking mechanism.

Has anyone here actually deployed a Sites project with a second D1 migration?

I’m specifically trying to understand:

• Does Sites automatically execute packaged files under .openai/drizzle/?
• If yes, when does that happen relative to Worker activation?
• How does Sites know 0000 is already applied and avoid replaying it?
• Is there a Sites-specific migration ledger that is not visible in the D1 database?
• On a deployment containing 0000 and 0001, will Sites apply only the new migration?
• If migration fails, does the previous Worker version remain live?
• Is runtime/app-managed migration actually supported/recommended, or should Sites own the migration lifecycle?

I’ve paused the production release because I don’t want both the platform and the app trying to own the same schema change.
Any first-hand experience with Sites + D1 + Drizzle migrations would be very helpful.

[parnika0110]

The key distinction seems to be between standard Cloudflare D1 migrations and whatever migration orchestration ChatGPT Sites adds on top.

For normal D1/Workers deployments, Cloudflare's migration system keeps applied-migration state in a d1_migrations table and wrangler d1 migrations apply applies only migrations that haven't already been recorded as applied. Cloudflare also documents that an applied migration is recorded in that table.

So if Sites is using the standard D1 migration mechanism underneath, 0000 would normally be recorded there and a later deployment containing 0000 + 0001 would apply only 0001.

However, I don't see public Sites documentation that establishes that .openai/drizzle/ is passed through wrangler d1 migrations apply, or that Sites exposes the same d1_migrations ledger. Because of that, I wouldn't assume that the absence of a visible d1_migrations table means Sites has no migration tracking, nor would I assume that the platform automatically executes those files.

Given that you've already seen conflicting guidance, I'd avoid adding a second app-managed migration system until the Sites-specific behavior is confirmed. Otherwise you could end up with two independent migration owners.

The most useful thing to confirm from the Sites implementation/docs would be:

1. Whether .openai/drizzle/*.sql is automatically applied during deployment.
2. Whether Sites maintains migration state in the D1 database or in platform-side deployment state.
3. Whether deployment is blocked/rolled back if a migration fails.
4. Whether runtime/app-managed migrations are officially supported.

Until those are documented, I'd treat the Sites-specific migration lifecycle as an implementation detail rather than assuming standard Wrangler behavior.