Configuration

Every setting is a vars entry or a binding in wrangler.jsonc, and every one has a working default. A deploy that sets nothing beyond what the canonical config already carries serves a site.

Values arrive from wrangler as strings, so a boolean is "1" or "0" and a number is a decimal string. An unparseable value falls back to the default and never throws: these are read on the serving path, and a typo must not take a site down.

Three layers decide what a value is, most specific first:

1. A request parameter, where the route exposes one (?prefill=, ?all=1).
2. The CONFIG_KV namespace, for the plan and the runtime levers on Runtime Overrides. No redeploy needed.
3. The vars entry, then the per-plan default in src/ops/plan-profile.ts, then the constant.

Pages

• Site Identity and Origin Settings: the CMS selector, site id, location hint and origin.
• Plan and Extensibility Routes: the plan variable and the extensibility routes.
• Migrated Project Settings: settings a migrated project carries over from its old host.
• Diagnostics: diagnostic variables and logging.
• Serving and Caching: page tiers, static assets, limits, prefill, files and images.
• Runtime: cron, warming, the interpreter lifecycle, boot and storage.
• Replicas: replica lanes and pool sizing.
• Operations: maintenance, owner access, database updates, reconciliation and runtime overrides.
• Integrations: mail, outbound TCP, Workers AI, OIDC login and Spool.

Variable Index

Every variable and binding on the configuration pages, once each.

Bindings

wrangler.jsonc is the canonical config and declares seven of the nine. FILES and SEND_EMAIL are the two it leaves out.

FILES is left out of the shipping config because naming it breaks the deploy button. R2 has to be enabled from the Cloudflare dashboard before any bucket can exist, so a config that names one is refused with "Please enable R2 through the Cloudflare Dashboard. [code: 10042]" on every account that has not done that. Enabling R2 requires a payment card on either Workers plan, even when usage stays inside the monthly allocation. KV and D1 have no such requirement: wrangler creates CONFIG_KV and FLEET_DB on first deploy.

Once R2 is enabled, wrangler creates the named bucket on deploy as it does for KV and D1. Add the binding when you want the mirror:

"r2_buckets": [{ "binding": "FILES", "bucket_name": "drupflare-files" }]

The managed config

wrangler.managed.jsonc is the canonical config plus the two bindings it leaves out, FILES and SEND_EMAIL, and one var, CACHE_API=off. A user Worker in a Workers for Platforms dispatch namespace cannot read caches.default: the property access throws, and every dynamic request failed with error 1101 before the var existed. With CACHE_API=off the serving path never touches the Cache API and answers from the KV page tier and the object instead. Unset, it is on. The managed config is what a managed deployment deploys with, where the control plane has enabled R2 on the account and set up Email Routing, which a deploy button cannot do:

bunx wrangler deploy -c wrangler.managed.jsonc

tests/node/oneclick-config.spec.ts holds the two files together. It fails when the managed config differs from the canonical one in any key but those two, and when the canonical config names a binding that needs an account resource it cannot create. bun run release:check dry-runs both configs and prices each bundle against the 64 MiB limit, and the release workflow bundles both before it publishes. Whether a deploy that names send_email is refused on an account without Email Routing has not been measured, so the managed config assumes the control plane has set it up.

A binding goes into this file when the code that reads it lands, not before. Service bindings, worker_loaders and a facade Worker are listed in the roadmap as managed-only and are not here yet, because nothing in src/ reads them and a binding nothing reads fails a deploy for no gain.

An unbound optional binding always wins over the var that would enable the feature. Asking for a tier that is not bound is a configuration error, and answering it with a crash on the serving path would be the wrong trade.

Related

• Repository layout: every path outside src/ and how it arrives
• Building from source: how a source build runs
• Measurement classes: which instrument may produce which class of number
• Recovery: which primitive answers which failure
• External database: why the site database lives in the Durable Object