cloudflare_ship_workerlisted

# Ship a Cloudflare Worker > Unofficial, agentstack-authored. Not affiliated with or endorsed by Cloudflare. Use this skill when deploying a Cloudflare Worker (new or existing) and you want the deploy to be repeatable, reviewable, and safe to roll back. ## Workflow 1. Read `wrangler.toml` (or `wrangler.jsonc`) end to end. Confirm `name`, `main` (the entry script), and `compatibility_date` are set. A missing or stale `compatibility_date` is the most common cause of surprising runtime behavior — set it to the day you are shipping unless the project pins one deliberately. 2. Inventory every binding the Worker needs and confirm it exists in config: KV namespaces, R2 buckets, D1 databases, Queues, Durable Objects, service bindings, and `vars`. A binding referenced in code but absent from config fails at runtime, not at build. 3. Set secrets out of band with `wrangler secret put <NAME>` — never commit them to `wrangler.toml` or `vars`. Verify with `wrangler secret list`. 4. Validate before shipping: `wrangler deploy --dry-run --outdir dist` builds the bundle without publishing. Read the binding summary it prints and confirm it matches step 2. 5. Deploy to the intended environment explicitly: `wrangler deploy` for the default, or `wrangler deploy --env staging` / `--env production`. Do not let ambiguity decide which environment ships. 6. Verify the live deploy: hit the route or `workers.dev` URL, then tail logs with `wrangler tail` to confi