cloudflare-ops

Just ask

You do not need to run anything. Once the skill is installed, say what you want in your own words and the agent does it:

"connect my Cloudflare account" "point app.mysite.com at my server, the address is 203.0.113.10" "has the DNS updated yet?" "what domains do I have?" "publish this site to Cloudflare and put www.mysite.com on it" "deploy this worker and put api.mysite.com on it" "delete the old staging subdomain"

The agent runs the commands, checks the result, and tells you in plain words whether it worked. It will ask before deleting anything, and it will tell you when a choice matters — such as whether traffic should pass through Cloudflare or go straight to your server.

The only thing it cannot do for you is the one-time account connection: you tick three boxes on Cloudflare's website and paste the result into a file. That is deliberate — it means your token never passes through a chat window. The agent walks you through it and does everything after.

The commands below are for people who would rather drive themselves.

The setup problem this solves

Cloudflare has no "grant everything" control. Building a token by hand means choosing from 392 separate permissions across four scopes, and picking wrong produces an error that means nothing to a beginner. Cloudflare does, however, let a token that can manage tokens create other tokens.

So the flow is: the user ticks three checkboxes to make a temporary token, pastes it into a file, and the script builds the real one — then deletes the temporary one. Two minutes, no jargon.

The token is never typed into the conversation. The script writes an empty file and names it; the user pastes the value in themselves. Storage and handling come from toolkit-credentials.

Requirements

Node 18 or newer. If you do not have it, the skill installs it for you — the agent runs this, or you can:

sh scripts/setup-deps.sh --check    # is everything present?
sh scripts/setup-deps.sh            # show the install command, ask, then run it

.\scripts\setup-deps.ps1            # Windows

It picks the right command for your machine (Homebrew, apt, dnf, pacman, zypper, apk, winget) and never installs anything without asking. Where there is no package manager it prints instructions you can follow yourself, including one that needs no admin rights.

Publishing to Pages or Workers also uses wrangler, but there is nothing to install — it is fetched on demand through npx, which ships with Node, and receives the saved token so it needs no login of its own.

If you prefer the command line

node scripts/cf.mjs whoami
node scripts/cf.mjs zones
node scripts/cf.mjs dns example.com
node scripts/cf.mjs dns-add app.example.com A 203.0.113.10
node scripts/cf.mjs dns-add www.example.com CNAME my-site.pages.dev --proxied
node scripts/cf.mjs dns-remove old.example.com --type A --yes
node scripts/cf.mjs check app.example.com
node scripts/cf.mjs r2

node scripts/cf.mjs pages
node scripts/cf.mjs pages-create my-site
node scripts/cf.mjs pages-deploy my-site ./dist
node scripts/cf.mjs pages-domain my-site www.example.com
node scripts/cf.mjs pages-domains my-site

node scripts/cf.mjs workers
node scripts/cf.mjs worker-deploy ./my-worker
node scripts/cf.mjs worker-domain my-worker api.example.com
node scripts/cf.mjs worker-domains

node scripts/api.mjs search waf rule
node scripts/api.mjs show "/zones/{zone_id}/rulesets" post

dns-remove lists what it matched and refuses to delete without --yes.

check queries public resolvers through Node's own DNS client, so it reports what a visitor would see — and works on Windows, where dig is not installed.

Publishing a site

The whole path, verified end to end — a new project was live on its own hostname over HTTPS about a minute after the domain was attached:

npm run build                                            # your build, whatever it is
node scripts/cf.mjs pages-create my-site
node scripts/cf.mjs pages-deploy my-site ./dist
node scripts/cf.mjs pages-domain my-site www.example.com
node scripts/cf.mjs pages-domains my-site                # certificate status

Re-deploying later is only the third line. Or say "publish this site to Cloudflare and put www.example.com on it" and the agent does all of it.

pages-deploy runs wrangler through npx — nothing to install, no second login, the saved token is handed to it. pages-domain attaches the domain and creates the DNS record, because doing only one leaves it stuck at "pending" forever.

Deploying a Worker

node scripts/cf.mjs worker-deploy ./my-worker
node scripts/cf.mjs worker-domain my-worker api.example.com

The directory needs a wrangler.toml naming the Worker and its entry file. Include workers_dev = false when it will live on your own domain — without it, a first deploy on a fresh account tries to register a workers.dev subdomain named after the folder and fails. worker-deploy checks for that before running and explains it.

Unlike Pages, do not add a DNS record for a Worker hostname: worker-domain is the whole job and Cloudflare manages the record itself.

Anything not wrapped

Cloudflare has about 2000 endpoints and request() reaches all of them with the same credential. The only hard part is knowing which one and what it wants, so the skill can look that up instead of guessing:

node scripts/api.mjs search waf rule
node scripts/api.mjs show "/zones/{zone_id}/rulesets" post

It reads Cloudflare's own API description — downloaded once, cached next to the credentials — and resolves the internal references so the request body is readable rather than a pointer. This is the job the official Cloudflare MCP server does; doing it here means no second server, no OAuth, and it works in every agent rather than one.

What it cannot do

Building is yours. pages-deploy and worker-deploy upload what already exists — run your build first.

The token also cannot create further tokens: Cloudflare refuses to grant token-management permission to a token created by another token. Rotate with begin --force.

Playbooks

references/playbooks.md — pointing a subdomain at a server and waiting for its certificate, replacing a record without downtime, Pages with a custom domain, Workers on your own domain, R2 with a public hostname, and a diagnostic order for "it is not resolving".