- Home
- Skills
- DevOps & Cloud
- Cloudflare Workers Production Pack
Works with the AI Agents you already use
Cloudflare Workers Production Pack
Eight agent skills and two scripts that make your AI agent ship Cloudflare Workers right: wrangler config, D1, R2, KV, Queues, Durable Objects, limits, CI.
$24
Cloudflare Workers Production Pack
Example session with this skill installed
We're about to do our first production deploy. Staging returns 500s with env.DB is undefined. Here's wrangler.jsonc. Fix it.
{
"name": "orders_api",
"main": "src/index.ts",
"compatibility_date": "2025-11-03",
"routes": [{ "pattern": "api.example.com/*", "custom_domain": true }],
"vars": { "ENVIRONMENT": "production", "STRIPE_SECRET_KEY": "<redacted>" },
"d1_databases": [{ "binding": "DB", "database_name": "orders", "database_id": "<D1_ID>" }],
"durable_objects": { "bindings": [{ "name": "RATE_LIMITER", "class_name": "RateLimiter" }] },
"migrations": [{ "tag": "v1", "new_classes": ["RateLimiter"] }],
"env": {
"staging": {
"vars": { "ENVIRONMENT": "staging" }
}
}
}
- Read your context and instructions
- Compiled the cloudflare workers production
The agent loads cloudflare-workers-production, then workers-wrangler-config, and runs the linter:
$ node lint-wrangler-config.mjs wrangler.jsonc
ERROR name-invalid name "orders_api" may contain only letters, digits and dashes (no underscores).
WARN compat-date-old compatibility_date 2025-11-03 is 344 days old. Read the compatibility flags changelog, bump it, run tests and `wrangler types`.
ERROR secret-in-vars top level: var STRIPE_SECRET_KEY has a secret-like name. Move it to a secret (`wrangler secret put STRIPE_SECRET_KEY`) and .dev.vars for local dev.
ERROR custom-domain-pattern top level: custom domain "api.example.com/*" contains a wildcard. Custom Domains match one exact hostname.
ERROR custom-domain-pattern top level: custom domain "api.example.com/*" contains a path. Custom Domains take the whole hostname; use a route for path matching.
WARN do-legacy-storage migration v1: new_classes creates a key-value backed class (RateLimiter). Use new_sqlite_classes for new classes.
WARN env-missing-binding env.staging: vars entry STRIPE_SECRET_KEY exists at the top level but not in this environment.
WARN env-missing-binding env.staging: "durable_objects" is set at the top level but not in this environment. Bindings and vars are not inherited; this environment deploys without them.
WARN env-missing-binding env.staging: "d1_databases" is set at the top level but not in this environment. Bindings and vars are not inherited; this environment deploys without them.
WARN env-inherits-routes env.staging: inherits the top-level routes (api.example.com/*). Deploying it moves those routes and custom domains to the environment's Worker. Give it its own routes or "routes": [].
INFO observability-unset observability is not set. New Workers default to logs on, but set "observability": { "enabled": true } so the config stays the source of truth.
INFO secrets-undeclared No secrets.required list. Declare secret names so `wrangler deploy` fails when one is missing and `wrangler types` types them without .dev.vars.
WARN types-missing No generated types file (worker-configuration.d.ts). Run `wrangler types` and commit the output; run `wrangler types --check` in CI.
4 error(s), 7 warning(s), 2 note(s)
It explains the 500s: d1_databases and durable_objects are not inherited by env.staging, so the staging Worker has no DB. It flags two problems that would have hit production next: staging inherits routes, so wrangler deploy --env staging would move api.example.com to the staging Worker, and new_classes would create the rate limiter on the key-value backend, which can never be converted to SQLite. Since nothing is deployed yet, it declares the class in exports with SQLite storage, moves the Stripe key to a secret, and gives staging its own bindings and domain:
{
"$schema": "./node_modules/wrangler/config-schema.json",
"name": "orders-api",
"main": "src/index.ts",
"compatibility_date": "2026-10-01",
"workers_dev": false,
"preview_urls": false,
"observability": { "enabled": true, "head_sampling_rate": 1 },
"routes": [{ "pattern": "api.example.com", "custom_domain": true }],
"exports": {
"RateLimiter": { "type": "durable-object", "storage": "sqlite" }
},
"secrets": { "required": ["STRIPE_SECRET_KEY"] },
"vars": { "ENVIRONMENT": "production" },
"d1_databases": [
{ "binding": "DB", "database_name": "orders", "database_id": "<PRODUCTION_D1_ID>" }
],
"durable_objects": {
"bindings": [{ "name": "RATE_LIMITER", "class_name": "RateLimiter" }]
},
"env": {
"staging": {
"routes": [{ "pattern": "staging-api.example.com", "custom_domain": true }],
"secrets": { "required": ["STRIPE_SECRET_KEY"] },
"vars": { "ENVIRONMENT": "staging" },
"d1_databases": [
{ "binding": "DB", "database_name": "orders-staging", "database_id": "<STAGING_D1_ID>" }
],
"durable_objects": {
"bindings": [{ "name": "RATE_LIMITER", "class_name": "RateLimiter" }]
}
}
}
}
It sets the secret per environment with npx wrangler secret put STRIPE_SECRET_KEY --env staging, puts the local value in .dev.vars, runs npx wrangler types (which now types STRIPE_SECRET_KEY: string and ENVIRONMENT: "staging" | "production"), and reruns the checks:
$ node lint-wrangler-config.mjs wrangler.jsonc
0 error(s), 0 warning(s), 0 note(s)
$ npx wrangler deploy --dry-run --env staging
Total Upload: 0.45 KiB / gzip: 0.29 KiB
Your Worker has access to the following bindings:
Binding Resource
env.RATE_LIMITER (RateLimiter) Durable Object
env.DB (orders-staging) D1 Database
env.ENVIRONMENT ("staging") Environment Variable
--dry-run: exiting now.
Both configs, the linter output and the dry-run output above are real runs on wrangler 4.150.0. Finally it adds wrangler types --check, the D1 migrations apply --remote step and the deploy to CI from workers-testing-release.
Connects securely to your tools. The creator never sees your data.
About this skill
Agents write a Worker's fetch handler well. They get production wrong: a staging environment that deploys without its D1 binding because bindings are not inherited, a staging deploy that takes the production Custom Domain because routes are, an API key in vars, BEGIN TRANSACTION in D1, wrangler d1 migrations apply without --remote in CI (it succeeds and changes nothing), KV used as a counter, a queue consumer that throws and redelivers the whole batch, Durable Objects on the key-value backend that can never move to SQLite, test setups built on defineWorkersConfig that the current Vitest integration removed, and size limits quoted from three years ago.
This pack gives the agent current rules, checked against the Cloudflare developer docs, the wrangler 4.150 config schema and CLI help, and the package source:
- cloudflare-workers-production: routing, pre-flight checklist, current versions, the boundaries that change behaviour.
- workers-wrangler-config:
wrangler.jsonc, compatibility dates and flags, environments, vars vs secrets andsecrets.required,wrangler types, Custom Domains vs routes vs workers.dev, Version URLs. - workers-d1-hyperdrive: migrations, prepared statements,
batchtransactions, retryable errors, read replication, Time Travel, the foreign-key cascade trap in table rebuilds; Hyperdrive with node-postgres and Postgres.js. - workers-r2-kv: conditional and range reads, multipart uploads, presigned URLs with a signed content type, bucket CORS, KV consistency and when not to use KV.
- workers-queues-workflows: per-message ack and retry, idempotent consumers, dead letter queues, Workflows steps, retries,
waitForEvent, rollback handlers. - workers-durable-objects: SQLite storage, the
exportsfield, alarms, WebSocket hibernation, RPC, retry rules, duration billing. - workers-limits-caching: CPU, memory, subrequests, size and startup limits with docs page and date, pricing gotchas, Workers Cache, Cache API, Cache Rules precedence.
- workers-testing-release:
@cloudflare/vitest-plugin, D1 migrations in tests, MSW mocking, GitHub Actions deploys, gradual rollouts, rollbacks, logs, tail, traces.
Two zero-dependency Node scripts: lint-wrangler-config.mjs flags old compatibility dates, secrets in vars, bindings missing from environments, inherited routes, bad Custom Domain patterns, Durable Object storage mistakes and stale generated types; check-worker-limits.mjs reads a dry-run bundle and the config and warns on size, CPU, env var, asset and subrequest limits for your plan.
Works with Claude Code (skills folder or plugin), Codex, Gemini CLI and Cursor. Plain Agent Skills format.
Versions: wrangler 4.150, @cloudflare/workers-types 5.x, @cloudflare/vitest-plugin 1.4 with Vitest 4.1 or 5, cloudflare/wrangler-action v4. Reviewed after Wrangler releases that change config or deploys and after limits or pricing changes.
How to use
Skills on Agensi run inside your AI agent. Copy the prompt, paste it into your agent, and it connects to Agensi and installs this skill for you. If a payment is needed, your agent shows it to you first.
Reviews
No reviews yet
Be one of the first to try it. Every listed skill passes our trust checks below.
Security scanned
Passed our 8-point scan before listing
Fresh listing
Recently published to Agensi
Money-back guarantee
Doesn't do what its page promises? You get your money back.
Trust & safety
Security scanned
Verified clean 6 days ago
- Passed all security checks, Safe to install
Requires