Named environments inherit nothing that binds: vars, bindings, crons

The answer. Wrangler environments ([env.staging], [env.production]) are separate Workers deployed from one file, and only the inheritable keys cross over: name, main, compatibility_date, compatibility_flags, workers_dev, observability. Everything that binds is non-inheritable and must be restated per environment: vars, kv_namespaces, r2_buckets, d1_databases, queues, ai, services, durable_objects, routes, and triggers. There is no merge and no warning. In our API Worker the production environment once shipped without a cron at all: the top-level [triggers] existed, [env.prod.triggers] did not, and the scheduled handler simply never ran until the block was added. Read the deploy output ("Your Worker has access to the following bindings") as the source of truth for what an environment actually has.

The pattern.

name = "my-api-local"                 # top level = local only; never the production name
compatibility_date = "2026-09-01"
[vars]
APP_ENV = "local"
[triggers]
crons = ["*/15 * * * *"]

[env.production]
name = "my-api"
routes = [{ pattern = "api.example.com", custom_domain = true }]
vars = { APP_ENV = "prod" }           # repeated on purpose: not inherited
[env.production.triggers]
crons = ["*/15 * * * *"]              # repeated on purpose: not inherited
[[env.production.kv_namespaces]]
binding = "CACHE"
id = "<prod-id>"

Watch out.

Secrets are per environment too: wrangler secret put X --env production.
crons = [] removes every trigger; omitting the triggers key leaves whatever is deployed in place. Two different intentions, easy to confuse.
Durable Object bindings in an env resolve to <name>-<env> script names, so each environment gets its own objects and storage.