Agentic Domain Ops With Porkbun, Cloudflare, and Wrangler

I wired Porkbun and Cloudflare into an agent that handles the boring parts between “I have an idea” and “the site is actually live.” I was asked to write about how I use Agents to automate Domain Ops with practical use cases and code examples.

Note: I generated this article with a Local LLM that explored my workflows comprehensively. The goal was to explain how the system works without exposing exact paths, hostnames, domains, credentials, or internal structure. It has been reviewed and is found to be accurate and representative of my actual workflows.

What Does The Agent Do?

• check whether a domain is available

• buy or register the domain

• set registrar nameservers

• move DNS authority to Cloudflare

• create and update DNS records

• deploy static sites through Cloudflare Pages

• setup reverse proxy for services / apps

• attach apex and www custom domains

• configure edge redirects

• verify that the live internet sees the intended result

The more useful part of this is the overall structure of how I go about doing this systematically: runbooks, desired-state files, backups, confirmation gates, and verification commands. Agents don’t get to just wing it.

What the Layout Looks Like

The generic version looks like this:

• registrarctl wraps Porkbun registrar and DNS operations.

• cf-zone-migrate moves Porkbun-hosted DNS into Cloudflare DNS authority.

• cf-pagesctl deploys and verifies Cloudflare Pages sites through Wrangler plus the Cloudflare API.

• cf-redirectctl manages Cloudflare Bulk Redirect desired state.

• cf-proxy-audit audits and patches Cloudflare proxy status for web records.

• route-bootstrap handles internet-facing reverse-proxy routes for services that are not Cloudflare Pages.

The agent reads the runbook first, then the desired-state file, then the matching script. That order matters.

I don’t want it “remembering” how DNS worked last time. I want it reading the current runbook and doing the same guarded steps every time.

Credentials Stay Outside the Workflow Files

The workflow files have examples, not secrets.

The agent can invoke workflows, but I keep credentials out of the files it reads and edits.

Script 1: registrarctl

I call registrarctl the Porkbun control surface. It is the single script that talks to the Porkbun API and handles the actual record changes.

The script covers:

• API smoke checks

• pricing checks

• domain availability checks

• portfolio inventory

• expiry and auto-renew audits

• domain registration

• renewal and transfer operations

• registrar nameserver reads and updates

• glue records

• URL forwarding

• DNSSEC records

• Porkbun-hosted DNS reads and writes

The read-only commands are safe for the agent to run often.

The DNS writer checks CNAME coexistence conflicts, refuses ambiguous multi-record updates unless I ask to replace all, and uses idempotency keys for writes.

Script 2: cf-zone-migrate

cf-zone-migrate is for the common case where Porkbun stays the registrar, but Cloudflare becomes the DNS authority.

The workflow is intentionally small:

The migration handles record shape instead of blindly copying everything.

• A, AAAA, CNAME, TXT, and MX records come over as-is.

• MX, TXT, and anything else that can’t be proxied stays DNS-only.

• Web records follow whatever Cloudflare proxy policy you set.

• Registrar-hosted NS records are ignored.

• Provider-specific alias records get flattened into real A and AAAA records.

• Cloudflare zone records are backed up before anything is written.

• TLD delegation is verified during the final check.

That makes nameserver changes much less scary. The agent is not just changing nameservers; it is staging the Cloudflare zone, backing up state, applying records, updating the registrar, and verifying delegation.

Script 3: cf-pagesctl

cf-pagesctl manages Cloudflare Pages sites.

The desired-state file and command surface look like this:

In practice, it handles the deployment loop:

• copies the site to a clean upload directory before deploying

• creates or locates the Pages project

• runs wrangler pages deploy

• points Cloudflare DNS at the Pages hostname

• attaches the apex and www hostnames as Pages custom domains

• checks that custom-domain activation finishes

• checks Web Analytics binding when configured

• runs HTTP probes for expected status codes and redirects

The custom-domain step is kept separate from DNS for a reason. Just having a DNS record that points to Pages is not always enough. The hostname also needs to be attached to the Pages project itself.

Script 4: cf-redirectctl

cf-redirectctl manages Cloudflare Bulk Redirects.

Its command surface is small:

This script handles redirects, not DNS. It manages the Cloudflare account-level redirect list and ruleset, then verifies edge behavior.

The desired state decides whether the redirect:

• includes subdomains

• matches all paths

• preserves path suffixes

• preserves query strings

• collapses all traffic to one exact target

That keeps redirect semantics explicit. The agent doesn’t have to guess whether a campaign domain should preserve deep links or just point everything at a single canonical URL.

Script 5: cf-proxy-audit

cf-proxy-audit is a smaller but useful safety tool.

It audits Cloudflare DNS records that should be proxied and patches drift when I ask it to.

Typical usage looks like this:

I use this for web-facing records where Cloudflare needs to sit in front of the origin for redirects, edge rules, caching, or protection. I do not use it for mail records, verification TXT records, or records that must stay DNS-only.

Script 6: route-bootstrap

Not every hostname is a static Pages site.

For self-hosted services, route-bootstrap creates the reverse-proxy route and the matching Cloudflare DNS record.

The route state is just a small config file:

This path is separate from Pages because it handles a different kind of exposure: reverse proxy plus DNS, rather than Cloudflare Pages plus custom domains.

The Agent Workflow

The agent doesn’t need one giant “do everything” tool. It needs a routing policy.

When I ask for a new domain:

Verification Is Key

I only trust this workflow because it proves the final state.

For registrar and DNS migration, verification checks:

• Porkbun registrar nameservers

• Cloudflare zone status

• Cloudflare record counts

• TLD delegation

• Authoritative DNS answers from Cloudflare nameservers

For Pages, verification checks:

• Pages origin URL

• apex custom domain

• www custom domain

• custom-domain activation

• expected HTTP status codes

• redirect locations

• Web Analytics binding when configured

For redirects, verification checks:

• Cloudflare redirect list state

• account ruleset state

• source hostname DNS

• edge HTTP behavior

• path and query preservation

The thing that makes this actually work is avoiding false negatives while DNS is still propagating. The verifier resolves through Cloudflare authoritative nameservers, then uses curl –resolve to hit the right edge directly.

That tests the intended edge path instead of waiting for every recursive resolver to catch up.

Why This Works

The agent earns its keep by connecting the whole chain:

I keep the workflow safe by making each step narrow:

• reads are cheap

• writes are explicit

• paid operations require exact confirmation

• nameserver cutovers require a separate confirmation

• desired state lives in files

• Cloudflare state is backed up before writes

• DNS delegation is verified authoritatively

• secrets stay outside the workflow files

• Pages custom domains are checked separately from DNS records

• redirects are verified at the edge

Agentic workflows-at the moment-require being explicit: buy the domain, register it, move DNS authority, deploy the site, attach hostnames, configure redirects, and verify the live result through the same operating loop every time.

No more dashboard busywork.

Until next time.

-Ahmad