Cloudflare Ops
Operational Cloudflare/Wrangler work: project wiring, D1/KV/R2, env layout, and safe migrations. Deploy-and-prove remains the skill for “ship immutable source and prove production serves it.”
Safety
- Confirm account/target (workers.dev vs custom domain, preview vs production) before mutating remote state.
- Never print secret values, commit
.dev.vars with real secrets, or broaden public env prefixes to make a build pass.
- Prefer read-only inventory first (
wrangler whoami, list DBs/buckets, show migrations pending).
- Back up D1 (or export) before destructive migrate/reset when data may exist.
- Do not treat a successful
wrangler deploy CLI exit alone as product proof — hand live behavioral proof to deploy-and-prove when the user wants “is it live?”
Workflow
- Read repo Cloudflare docs:
wrangler.toml / wrangler.jsonc, package.json scripts, existing D1/KV/R2 bindings, and environment names.
- Inventory remote vs local: login, account, workers/pages projects, D1 databases, KV namespaces, R2 buckets, pending migrations.
- Plan ops explicitly: create resource, bind, migrate, backup, secret set, multi-env split, or proxy/route change. Call out data risk.
- Apply the smallest authorized change with official Wrangler/CLI (no house wrapper scripts unless product-specific glue is required).
- Verify with independent readback: resource exists, binding name matches code, migration applied, secret keys present (not values), routes/DNS as expected.
- If the user also wants production behavior proof, continue with
deploy-and-prove after ops are stable.
Verification
Report:
- account/environment and config files touched;
- resources created/updated (IDs/names only);
- migration/backup commands and outcomes;
- bindings now matching application code;
- secrets keys present vs missing (never values);
- residual risks (orphaned resources, dual config, unapplied envs).
Do not claim Cloudflare is “done” while local config and remote resources disagree, or while a deploy was requested but not proven live.
1---2name: cloudflare-ops3description: Use when the user asks for Cloudflare operational work — wrangler config, D1 create/migrate/backup, KV/R2 hygiene, Workers/Pages project wiring, proxy or secrets layout, multi-env CF setup — as distinct from proving a production deploy is live (use deploy-and-prove for that).4---56# Cloudflare Ops78Operational Cloudflare/Wrangler work: project wiring, D1/KV/R2, env layout, and safe migrations. **Deploy-and-prove** remains the skill for “ship immutable source and prove production serves it.”910## Safety1112- Confirm account/target (workers.dev vs custom domain, preview vs production) before mutating remote state.13- Never print secret values, commit `.dev.vars` with real secrets, or broaden public env prefixes to make a build pass.14- Prefer read-only inventory first (`wrangler whoami`, list DBs/buckets, show migrations pending).15- Back up D1 (or export) before destructive migrate/reset when data may exist.16- Do not treat a successful `wrangler deploy` CLI exit alone as product proof — hand live behavioral proof to `deploy-and-prove` when the user wants “is it live?”1718## Workflow19201. Read repo Cloudflare docs: `wrangler.toml` / `wrangler.jsonc`, `package.json` scripts, existing D1/KV/R2 bindings, and environment names.212. Inventory remote vs local: login, account, workers/pages projects, D1 databases, KV namespaces, R2 buckets, pending migrations.223. Plan ops explicitly: create resource, bind, migrate, backup, secret set, multi-env split, or proxy/route change. Call out data risk.234. Apply the smallest authorized change with official Wrangler/CLI (no house wrapper scripts unless product-specific glue is required).245. Verify with independent readback: resource exists, binding name matches code, migration applied, secret keys present (not values), routes/DNS as expected.256. If the user also wants production behavior proof, continue with `deploy-and-prove` after ops are stable.2627## Verification2829Report:3031- account/environment and config files touched;32- resources created/updated (IDs/names only);33- migration/backup commands and outcomes;34- bindings now matching application code;35- secrets keys present vs missing (never values);36- residual risks (orphaned resources, dual config, unapplied envs).3738Do not claim Cloudflare is “done” while local config and remote resources disagree, or while a deploy was requested but not proven live.
YosefHayim