Six Domains, One Operator: Multi-Brand Infrastructure on Cloudflare Workers, D1, and Pages

There's a version of my setup that a normal agency would run with a platform team: half a dozen production domains, static marketing sites, an e-commerce storefront, client dashboards, lead-capture APIs, a rank tracker, transactional email, DNS for all of it. I run that estate alone, with AI agent fleets doing most of the keystrokes and me doing the governance. This post is the infrastructure tour — what's on Pages, what needs a Worker and a D1 database, how the accounts are separated, and why this shape is the one a solo operator should copy.

The estate, at a glance

The properties span three ownership categories, and the category determines everything downstream — which account hosts it, which credentials agents get, and how careful a deploy has to be.

Notice what's not in the table: no VPS, no Kubernetes, no Next.js app servers waiting for traffic, no database cluster. Everything is either a static file on a CDN or a function that runs when a request arrives.

Why serverless-static beats framework sprawl for a solo operator

The honest constraint of one-person operations is not build capacity — agents give you nearly unlimited build capacity. The constraint is maintenance surface. Every running process is something that can be down at 3 a.m. with nobody on call but you.

Framework sprawl is how solo operators drown. A Next.js app per brand means a Node version per brand, a dependency tree per brand, a hosting bill shaped like compute-hours, and a rebuild treadmill every time a framework major ships. Multiply by six domains and you've hired yourself as a full-time platform team, unpaid.

The serverless-static shape inverts that:

• Static by default. Marketing sites, blogs, portfolios — all of it is HTML on Cloudflare Pages. A static site cannot crash. It has no dependencies to patch. My blog posts here are generated by a small Python build script from markdown; the output is plain HTML with the schema baked in. There is nothing to keep alive.
• Workers only where state or logic genuinely lives. A lead-capture form needs somewhere to POST. A rank tracker needs to run on a schedule and write results. A dashboard needs to read them. Each of those is a small Worker — single-file, no framework — and it scales to zero when idle.
• D1 as the database tier. D1 is SQLite at the edge, and for solo-operator workloads it's the right size on purpose. My lead rail writes form submissions to D1. The rank tracker is a Cloudflare cron trigger that pulls Search Console data and writes positions to D1; the dashboard Worker reads it back. No connection pools, no instance sizing, no migration between environments — a schema file and a wrangler command.
• Email through a Worker. Outbound transactional email (lead notifications, form confirmations) goes through a Worker SMTP rail rather than a marketing platform, because the sending logic lives next to the data that triggers it. DNS records — SPF, DKIM, the MX setup — sit in the same Cloudflare zone as everything else, so deliverability config is one dashboard, not four.
• IndexNow on deploy. The Ecolosophy pattern, now standard across the estate: a key file on the domain and a ping to the IndexNow endpoint as the last step of every deploy. New and changed URLs are announced to search engines the moment they exist, instead of waiting for a crawl. It's a few lines in the deploy script and it turns "publish" into "publish and notify" for free.

The cost profile follows from the architecture rather than from a pricing negotiation: static assets on a CDN and functions that only run on request means the estate's baseline cost is close to the floor of what hosting can cost at all, and it does not grow when I add a seventh brand. I'm not going to quote dollar figures — plans change — but the shape is the point: cost scales with actual requests, not with the number of apps I've promised to keep warm.

Account separation: the right account per brand

Here's the discipline that matters more than any technology choice, and it's a literal written rule in my operating docs: right account per brand.

Each brand lives in its own Cloudflare account. My personal properties are on my account. Ecolosophy has its own Cloudflare account with its own Pages projects, logged in under the Ecolosophy email. Client work runs on the client's accounts — their infrastructure is provisioned under their identity, not mine, so they own what they paid for and my access is revocable.

This sounds like bureaucracy until you run agents. Then it becomes the primary safety mechanism:

• Blast radius. An agent with a scoped API token for the Ecolosophy account physically cannot touch a client's DNS. The worst mistake is contained to one brand's estate. When your workforce is software that executes at machine speed, you don't get containment from "being careful" — you get it from credentials that can't reach the wrong zone.
• Clean exits. When a client engagement ends, nothing needs migrating out of my accounts. Their Pages projects, Workers, and DNS were always theirs.
• Billing truth. Each brand's infrastructure spend lands on that brand's card. No allocation spreadsheet, no "whose bill is this" archaeology at tax time.
• Identity hygiene. Deploys, API tokens, and dashboard logins map one-to-one with a brand email. When something changes in a zone, the audit log answers which operator context did it without forensics.

The failure mode this prevents is the one every multi-brand freelancer eventually hits: five clients' domains in one personal account, one compromised token away from a very bad week, and an ownership dispute waiting in every zone. Separation costs a browser profile per brand. It's the cheapest insurance in the stack.

What agents touch, and what they don't

The agent fleets do the volume: writing and deploying blog content, running scheduled SEO jobs, regenerating sitemaps, pinging IndexNow, watching dashboards. But the estate stays healthy because the permission map is explicit, written down, and enforced by more than good intentions. I covered the governance model in depth in the manual-first permissions post; the infrastructure-level summary:

Agents may: build and edit locally, run the blog build scripts, deploy to designated Pages projects on the correct brand account, write to their own D1 tables, ping IndexNow, and read analytics.

Agents may not: touch production DNS records without an explicit task, deploy to a client zone outside a scoped engagement, modify another brand's projects (the account separation makes this structurally impossible, not just forbidden), or push anything to a frozen surface — some sections of my sites are marked do-not-touch in the operating docs, and agents route around them.

And nothing ships blind. Every automated publishing pipeline in the fleet runs behind a safe-rollout gate — the same pattern I use in the daily content engine that runs five brands: deploy to a preview URL, verify with a real browser check, then promote. On a serverless-static stack this is nearly free, because Cloudflare Pages gives every deploy a preview URL by default. The architecture and the governance reinforce each other: static output is easy to diff, preview deploys are easy to inspect, and a bad deploy is a one-command rollback to the previous immutable build.

The compounding part: infrastructure as a content substrate

The reason this stack matters beyond uptime is that it's the substrate the content engines run on. The 500-post SEO/GEO blog engine on Acromatico exists because deploying a new post is a static build plus a Pages deploy plus an IndexNow ping — cheap enough that agents can do it on a schedule without me in the loop. The rank tracker exists because a cron-triggered Worker writing to D1 is an afternoon of work, not a SaaS subscription. Each brand's estate is the same small set of primitives arranged slightly differently, which means an agent that has learned to operate one brand's stack can operate all of them. That's the real answer to "how does one person run five brands": not heroics, but an infrastructure shape with almost nothing in it that can break.

FAQ

Is Cloudflare Workers + D1 enough for a real multi-brand operation?

For the workloads a solo operator actually runs — marketing sites, blogs, lead capture, dashboards, scheduled jobs, transactional email — yes, comfortably. The things it's not suited for (heavy long-running compute, large relational workloads with complex joins across huge datasets) are things a one-person estate mostly shouldn't be running anyway. When a brand genuinely needs a bigger database or a full app framework, that brand gets it — in its own account — without dragging the rest of the estate along.

Why not one Cloudflare account with multiple zones?

One account with many zones works technically and fails organizationally. Scoped tokens per brand, contained blast radius for agents, clean client handoffs, and per-brand billing all come free with separate accounts and are awkward to reconstruct inside a shared one. The rule is right account per brand, no exceptions — client infrastructure goes on client accounts.

How do you manage deploys across accounts without confusing yourself or your agents?

Each brand's repo carries its own operating doc stating which account, which Pages project, and which token to use, and deploy scripts are per-repo so the correct target is encoded in the code, not remembered. Agents inherit only the credentials for the brand they're working on. The confusion you'd expect mostly can't happen, because the wrong deploy target isn't reachable from the wrong context.

What does IndexNow on deploy actually change?

It collapses the gap between publishing and discovery. Instead of waiting for crawlers to find new URLs via sitemap re-checks, the deploy script announces changed URLs directly to participating search engines the moment the deploy finishes. For content engines shipping on a daily schedule, it means the index reflects the estate within hours, not weeks — for the cost of a static key file and one HTTP request in the deploy script.

— Italo Campilii