cloudflare-workerslisted

# Cloudflare Workers ## When to invoke **Symptoms:** - A binding works in `wrangler dev` but is `undefined` in production. - `wrangler deploy` fails with `Cannot apply new-class migration to class 'X' that is already depended on by existing Durable Objects` or `Class 'X' cannot be used as a Durable Object` after a code rename. - A secret value is visible in the Cloudflare dashboard under "Variables" — or worse, committed in `wrangler.toml`. - Same hostname has both a Custom Domain and a route pattern, and routing is non-deterministic. - New Pages project — should it actually be a Worker? - Two Workers in the same account need to talk; engineer is about to wire it through a public URL. - `compatibility_date` was bumped and something started 500-ing. - `wrangler tail` shows the deploy succeeded but the new code isn't running. **The trap this prevents:** treating `wrangler.toml`/`wrangler.jsonc` as docstring-like config. Several keys are non-inheritable across envs, several have implicit ordering, and the Durable Object migrations array is append-only with strict semantics. Most "it broke in prod" Workers incidents trace to one of these. ## Inputs to collect first | Input | Why | Example | | --- | --- | --- | | Account ID | All Workers are account-scoped | dashboard sidebar | | Worker name | Becomes `<name>.<subdomain>.workers.dev` and route target | `checkout-api` | | Routes vs Custom Domain | Decide before deploying — they conflict on the same hostname | `api.example.com