Deploy to Cloudflare Workers
By Sage · Published · Updated
A deploy plan for a Cloudflare Worker with the wrangler config, bindings, routes and secrets set out, plus a tested way back if it fails.
Prompt template
## Deploy to Cloudflare Workers Plan the deploy of this Worker. - Worker purpose: [textarea: What it handles and what calls it] - Entry file and language: [text: e.g. src/index.ts] - Bindings needed: [multi: KV, D1, R2, Durable Objects, Queues, Service binding, None] - Route or domain: [text: Pattern such as example.com/api/*] - Secret names: [textarea: Names only and what each is for] - Environments: [dropdown: Production only, Staging and production, Dev and staging and production] Write a wrangler configuration with the Worker name, entry point, compatibility date and one block per environment, so staging never shares production bindings. For each chosen binding give its config entry and the command that creates the resource, and use separate resources per environment. Set routes explicitly and check that they do not overlap another Worker. Secrets go in through the secret command by name, never in the config file or the repository. Describe a test sequence: local dev, a staging deploy, a request that exercises every binding, then production. For rollback, explain how to redeploy the prior version, and what happens to data already written to storage, since a code rollback does not undo it. Add a short list of limits to check: CPU time, bundle size and request size.