---
name: deploy-to-cloudflare-workers
description: "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. Use when a Cloudflare Worker is ready to ship and needs its wrangler config, bindings, routes, secrets and rollback path worked out. Do not use for writing the Worker's request-handling logic or tuning cache rules. Related topics: devops, coding."
---

# Deploy to Cloudflare Workers

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.

## When to use

Use this skill when a Cloudflare Worker is ready to ship and needs its wrangler config, bindings, routes, secrets and rollback path worked out. Do not use it for writing the Worker's request-handling logic or tuning cache rules.

## Workflow

1. Ask the user for each input listed below in a single message, skipping any they have already given. Where options are listed, offer them, but accept other answers too.
2. Write the wrangler configuration with a separate environment block for each environment and its own binding resources.
3. Give the creation command and config entry for every selected binding, using distinct resource names per environment.
4. Define routes explicitly and confirm none overlap another Worker.
5. List the secrets by name with the command that sets each, and check none appear in the config.
6. Lay out the staged test sequence, then the rollback steps including what a code rollback leaves behind in storage.

## Inputs

- **Worker purpose** (longer free text)
- **Entry file and language** (free text, e.g. "src/index.ts")
- **Bindings needed** (choose any: KV, D1, R2, Durable Objects, Queues, Service binding, None)
- **Route or domain** (free text, e.g. "Pattern such as example.com/api/*")
- **Secret names** (longer free text)
- **Environments** (choose one: Production only, Staging and production, Dev and staging and production)

## Output

A wrangler config, a binding and resource table, a secrets list, a four-stage test sequence, rollback steps and a list of platform limits to check.

## Prompt template

Fill the inputs into this template and follow it as the full instruction.

### Deploy to Cloudflare Workers

Plan the deploy of this Worker.

- Worker purpose: {{Worker purpose}}
- Entry file and language: {{Entry file and language}}
- Bindings needed: {{Bindings needed}}
- Route or domain: {{Route or domain}}
- Secret names: {{Secret names}}
- Environments: {{Environments}}

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.

## Pitfalls

- Sharing one KV or D1 resource between staging and production, so a test run overwrites live data.
- Assuming rollback restores data, when only the code returns to the earlier version.
- Using a broad route pattern that captures traffic meant for another Worker.