Site config reference

A site’s wrangler.json or wrangler.jsonc, in its root directory, says what the Worker is and which resources it needs. The build reads it twice: once to bundle the Worker and its assets as wrangler deploy would, and once to find the KV namespaces, D1 databases, R2 buckets, queues and Durable Objects to make and bind. Digize makes every resource on its own account and binds it under the name you give, so the IDs in your config are never used.

wrangler.jsonc

{
  "name": "shop",
  "main": "src/index.ts",
  "compatibility_date": "2026-10-01",
  "assets": { "directory": "./public", "binding": "ASSETS" },
  "kv_namespaces": [{ "binding": "CACHE" }],
  "d1_databases": [{ "binding": "DB", "database_name": "shop" }],
  "r2_buckets": [{ "binding": "UPLOADS", "bucket_name": "uploads" }],
  "queues": { "producers": [{ "binding": "JOBS", "queue": "jobs" }] },
  "durable_objects": { "bindings": [{ "name": "CARTS", "class_name": "Cart" }] },
  "migrations": [{ "tag": "v1", "new_sqlite_classes": ["Cart"] }]
}

The file is JSON with comments and trailing commas, up to 1 MiB. wrangler.json is read before wrangler.jsonc. A wrangler.toml can still be bundled when wrangler is one of the project’s dependencies, but its resources aren’t read: declare them in wrangler.jsonc to have them made and bound.

How resources are kept

Each resource is known by its key: the name the config gives it (database_name, bucket_name, queue) or, without one, its binding. The same key on the next build binds the same resource, with its data. Renaming a binding keeps the resource when the key stays.

When a build’s config no longer declares a resource, it’s deleted once that version is deployed, data and all, unless a newer push or a deploy that’s still running may need it. A config with a key that looks like a binding but isn’t one (say d1_database for d1_databases) holds every removal until it’s fixed, so a typo never deletes a database.

A site can have at most 5 of each resource type. Binding names must be unique across everything the Worker is given: the config’s resources and Durable Objects, the Bindings tab, and the variables and secrets. A name used twice fails the deploy.

Bundling keys

These work as they do with wrangler deploy, since the build bundles the Worker with wrangler deploy --dry-run and the project’s own Wrangler (or Wrangler 4 from npm if it has none):

Key	What it does here
main	The Worker’s entry. Without main and with assets, the site is assets only.
assets	directory is uploaded as the site’s static files. binding (default ASSETS), not_found_handling, html_handling and run_worker_first are kept. See Static assets.
compatibility_date	Wins over the Worker’s setting.
compatibility_flags	Added to the Worker’s setting. nodejs_compat is always on; global_fetch_strictly_public is always removed.
name	Optional; a Durable Object’s script_name may only name it.
no_bundle, rules, alias, define, minify, find_additional_modules, base_dir, build	As in Wrangler. The bundled Worker is at most 10 MiB.

Resource keys

kv_namespaces

Field
binding	Required. A JavaScript identifier of up to 64 characters. It’s also the key.
id, preview_id, remote, experimental_remote	Allowed, for local development; not used when deploying.

d1_databases

Field
binding	Required.
database_name	The key, up to 64 characters. Defaults to the binding.
migrations_dir	Where the database’s migrations are, relative to the root directory and inside the repository. Defaults to migrations.
migrations_pattern	Which files in it are migrations, such as migrations/*/up.sql. It needs migrations_dir and must start with it; * matches within one path segment, and **, ?, [], {} and ! aren’t supported. Defaults to *.sql.
migrations_table	The table that records applied migrations. Defaults to d1_migrations.
database_id, preview_database_id, database_internal_env, remote, experimental_remote	Allowed; not used when deploying.

Every build applies the migrations that haven’t run yet, in path order, before the new version goes live. A migration that fails fails the deploy and leaves the live version as it was.

r2_buckets

Field
binding	Required.
bucket_name	The key, up to 64 characters. Defaults to the binding.
jurisdiction	eu or fedramp, made in that jurisdiction. One key declared with two jurisdictions is refused.
preview_bucket_name, local_dev, remote, experimental_remote	Allowed; not used when deploying.

queues

Field
producers[].binding	Required.
producers[].queue	The key, up to 64 characters. Defaults to the binding.
producers[].delivery_delay	Seconds, from 0 to 43,200.
consumers	Not read: the queues are made for producers only. To consume a queue, make the Worker its consumer on the Bindings tab.

durable_objects and migrations

durable_objects.bindings[] takes name and class_name. A script_name other than this config’s own name is refused: a site binds only the classes its own Worker exports. A build that declares Durable Objects but produces no Worker fails.

migrations[] take a tag and new_classes, new_sqlite_classes, renamed_classes and deleted_classes. Each deploy sends the migrations after the tag the live script has; transferred_classes is refused.

exports

The newer way to declare Durable Objects: { "Cart": { "type": "durable-object" } }, with state (created, deleted or renamed), storage (sqlite or legacy-kv) and renamed_to. Other fields, such as containers or transfers, are refused. An export of "type": "workflow" is skipped with a note, since Workflows aren’t available to sites. A config can declare Durable Objects with migrations or with exports, not both.

Keys that are read but not used

The build goes on and its log says why:

Key	Why
vars	Not deployed. Set them as variables in the Worker’s settings, where the dashboard and the API can change them without a push.
triggers.crons	Not read. Set them on the Worker’s Triggers tab (Cron triggers).
env	Named environments are ignored; resources come from the top level. Resources declared only under env that the site already has are kept, not deleted.
queues.consumers	See queues.

Deployment settings that Wrangler would apply, such as routes, workers_dev, observability, placement and limits, have no effect: a site’s hostnames, routes, logs, placement and limits come from Digize (Domains and routes, Limits).

Keys sites can’t use

These bindings and features aren’t available to sites. A config that has them still builds, without them, and the log names each one:

• services
• workflows
• hyperdrive
• vectorize
• ai
• ai_search
• ai_search_namespaces
• agent_memory
• analytics_engine_datasets
• send_email
• browser
• images
• media
• stream
• mtls_certificates
• dispatch_namespaces
• pipelines
• secrets_store_secrets
• artifacts
• ratelimits
• worker_loaders
• vpc_services
• vpc_networks
• containers
• tail_consumers
• streaming_tail_consumers
• version_metadata
• unsafe

A Worker that needs to send email gets a send_email binding from Sites › Email sending instead, and a Worker can reach storage the workspace made in the dashboard through its Bindings tab.

Note

Errors that stop a build name the file and the field, such as wrangler.jsonc: d1_databases.0.binding: must be a JavaScript identifier. They’re on the deployment’s log and in its error.