Declare required secrets; the deploy fails when one is missing

The answer. A Worker that boots without a secret does not fail at deploy time; it fails on the first request that needs the value, often hours later and in production. Wrangler now closes that gap in configuration: list the secret names under secrets.required and wrangler deploy (and wrangler versions upload) checks that every one is set on the target Worker before uploading, failing with the missing names otherwise. The same list becomes the source of truth for wrangler types, so CI can generate Env without a .dev.vars file, and it filters local development: only the listed keys are read from .dev.vars or .env, and missing ones produce a warning at wrangler dev start. Our Workflows port carried a hand-written script to do exactly this check before every release; the config key replaces it.

The pattern.

{
  "secrets": { "required": ["HMAC_SECRET", "PROVIDER_API_KEY", "RESEND_API_KEY"] },
  "env": { "production": { "secrets": { "required": ["HMAC_SECRET", "PROVIDER_API_KEY", "RESEND_API_KEY", "STRIPE_WEBHOOK_SECRET"] } } }
}

$ wrangler deploy --env production
✘ Missing required secrets on my-api: STRIPE_WEBHOOK_SECRET
  Set them with: wrangler secret put STRIPE_WEBHOOK_SECRET --env production

Watch out.

Per-environment lists are allowed and the aggregated Env type marks environment-only secrets as optional; check for undefined in code that runs in every lane.
The check proves presence, not correctness. A rotated key that is set but wrong still passes; keep a /health probe that exercises each provider with a status-only call.
Locally the list is a filter: a key you forgot to list is silently absent from env in wrangler dev, which is the point, and a surprise the first time.