Confirmation
Affected resource(s)
cloudflare_d1_database- Proposed new
cloudflare_d1_database_migrations resource
Description
Provider v5.24.0 can provision a D1 database, but it has no first-class way to apply and track the database's schema migrations.
This prevents a Terraform deployment from bringing a D1-backed Worker from zero to a usable state in one dependency graph. The database can be created in Terraform, but a separate wrangler d1 migrations apply ... --remote step is still required before the Worker can safely serve traffic.
Please add first-class D1 migration support, preferably as a separate resource whose lifecycle is explicitly append-only rather than as arbitrary SQL on cloudflare_d1_database.
Additional Info
Cloudflare already defines the migration contract: ordered SQL files are applied once, and their names are recorded in a configurable migration table. The public D1 query API accepts SQL, including multiple statements.
A possible configuration could mirror Wrangler's established inputs:
resource "cloudflare_d1_database" "app" {
account_id = var.account_id
name = "app"
}
resource "cloudflare_d1_database_migrations" "app" {
account_id = var.account_id
database_id = cloudflare_d1_database.app.id
migrations_directory = "${path.module}/migrations"
migrations_pattern = "*.sql"
migrations_table = "d1_migrations"
}Expected lifecycle semantics:
- On create and update, discover migrations in deterministic order, read the migration journal, and apply only pending files.
- Preserve the Cloudflare/Wrangler behavior for a failed migration instead of marking it applied.
- Removing the Terraform resource should remove it from state without attempting to reverse already-applied schema changes.
- Changes to an already-applied migration should produce a clear diagnostic rather than silently re-running it.
The provider already has a precedent for hashing and uploading local directory content in the Workers static-assets implementation.
References
Confirmation
Affected resource(s)
cloudflare_d1_databasecloudflare_d1_database_migrationsresourceDescription
Provider v5.24.0 can provision a D1 database, but it has no first-class way to apply and track the database's schema migrations.
This prevents a Terraform deployment from bringing a D1-backed Worker from zero to a usable state in one dependency graph. The database can be created in Terraform, but a separate
wrangler d1 migrations apply ... --remotestep is still required before the Worker can safely serve traffic.Please add first-class D1 migration support, preferably as a separate resource whose lifecycle is explicitly append-only rather than as arbitrary SQL on
cloudflare_d1_database.Additional Info
Cloudflare already defines the migration contract: ordered SQL files are applied once, and their names are recorded in a configurable migration table. The public D1 query API accepts SQL, including multiple statements.
A possible configuration could mirror Wrangler's established inputs:
Expected lifecycle semantics:
The provider already has a precedent for hashing and uploading local directory content in the Workers static-assets implementation.
References