Client sites that live in your GitHub and your Cloudflare.

Who it is for

Agencies that build marketing sites for other people.

It assumes you already work the way an agency works: a GitHub organisation, a Cloudflare account, and a new client every few weeks who needs a small, fast, static site that you will keep editing after launch.

How it works

Four steps, then the site is a repository you own.

1. 1

   Pick a template

   Each template is a complete, launch-ready site rather than a fragment: a landing page, a privacy policy, terms of use, and a 404. Plain HTML with Tailwind classes, so what the AI edits is what the browser renders.

2. 2

   Describe the client

   Write a brief. The model fills named slots in the template rather than doing freehand HTML surgery, which is what makes the result predictable enough to review. The legal pages keep their placeholders for entity, jurisdiction, and contact, with a visible banner saying so, because a confident-looking policy full of invented specifics is worse than an obviously unfinished one.

3. 3

   Review the preview

   Look at the site before anything is committed. Nothing has left your browser except the calls you made to your AI provider with your own key.

4. 4

   Publish

   A repository is created in your GitHub organisation, the site is committed to it, and your own GitHub Actions deploys it to your own Cloudflare Pages. You are asked before the repository is created, and every creation shows up in your organisation's audit log.

After that, open the client's live page in a browser and keep going. The side panel attaches to the page you are looking at, you describe a change, you review the diff, and the edit is committed to the repository under your own GitHub identity. The page knows which repository backs it because every page it generates says so:

<meta name="source-repo" content="your-agency/acme-dental">

One tag, no registry, and no hostname guessing. The extension reads the page it is attached to and asks nobody. The console does keep a list of which of your repositories are sites, and it is worth being exact about that rather than letting the old sentence stand: it is a crawl of your own GitHub that can be thrown away and rebuilt, not a record only we have.

The centrepiece

Three things get held, and none of them is your client's site.

This page used to say there is no backend, and that was the strongest sentence on it. It is being retired on purpose, so the reason belongs here rather than in a quiet edit. An agency running forty client sites wants a fleet console, and a console needs somewhere to sign you in and somewhere to write down what happened. Neither of those fits inside a browser extension. So a control plane is being built, and the honest move is to publish what it is allowed to hold before it exists rather than after.

That leaves two surfaces with two genuinely different answers, and blurring them together would be the easy dishonest move. So, separately:

Here is every piece of state the product has, and where it lives.

Your clients' site content, briefs and generated copy never land on Rocket Lab infrastructure. They transit and are discarded, and the one credential we handle that can reach your Cloudflare is one we do not keep.

And the part an outage makes real: no piece of ours sits between a visitor and a client's page, or between a repository and its deploy. If everything of ours is down, you can still ship a client's site.

This is a weaker claim than the one it replaces, and it would be a poor start to pretend otherwise. "There is nowhere to hold it" was something you could check by reading a manifest and a workflow. "We hold it briefly and discard it" is something you have to believe, and every competitor in this category says it too. What is still checkable is narrower, and it is what the argument now rests on: the sites are in your repositories, the deploys run in your Actions, the pages answer from your Cloudflare, and the token that reaches it is one you can rotate without asking us.

What that costs

Four consequences, stated here rather than discovered later.

Adding a console is not free either, and the bill is different from the old one rather than smaller. This section used to list what having no backend cost. It now lists what having one costs, which is the more useful list because most of it did not exist before. If you read one section on this page, it should probably still be this one.

One thing gets easier, and it belongs next to the costs rather than in a brochure. The Cloudflare token step stops being a manual copy into your organisation's settings page: you hand it over once during setup, it is checked against Cloudflare before anything else happens, sealed into your own organisation's secrets, and discarded. It is still your token, in your organisation, and it still never touches the extension. Cross-device sync only half improves in the same way: your identity and your site list follow you to a second laptop, and your AI key still does not, because it stays in one browser profile.

Publishing model

Public by default. Gated only when you ask for it.

A client's marketing site exists to be found, so that is the default and it is not something you have to remember to switch on. The opposite mistake is the dangerous one: a site that is quietly gated is invisible to the customers it was built for, answers every visitor with a login page, drops out of search, and nobody notices, because the only people who check are the ones who can get past the gate.

What you bring

Three things, all of which you keep.

FAQ

The questions an agency should ask.

Some of these still follow from how the thing is built, which is the strongest kind of answer. Since there is now a console, some of them are promises about how we intend to behave. Those two are not worth the same and they are marked apart below rather than blended.

Where does my client's content go?

Into a repository in your GitHub organisation, and onto a Cloudflare Pages project in your Cloudflare account. On the way there it passes through your browser and your AI provider, because you asked a model to write it. Through the extension it passes through nothing else at all. Through the console it passes through a request of ours on its way to GitHub, and is discarded with that request rather than written down. That second sentence is a promise about our code and the first is a property of the design, and the difference is real.

What happens if Rocket Lab disappears?

Every published site stays up. The sites are static files in your repositories served from your Cloudflare account, deployed by a workflow that runs in your Actions, and nothing about serving them involves us. That much is unchanged and it is the part worth relying on. What is no longer true is that you would lose nothing else. An agency whose Cloudflare token we sealed into their organisation, whose fleet view lives in our database, and whose console audit trail we hold half of, loses the operations around their sites even though the sites keep serving: the inventory, the deploy statuses, the record of who changed what through the console, and eventually the ability to sign in at all. The sites survive us. The way you run them does not, and that is a real change from what this page used to say.

Can you see our prompts?

Not from the extension. The prompt goes from your browser directly to the AI provider you chose, authenticated with your key, with no intermediary to log it and no key of ours involved. From the console a prompt passes through our origin, so the accurate answer there is that it is not stored rather than that it could not be seen. Two related things we should not have claimed in the same breath before: your clients' page content follows the same rule as the prompt, and the names of your clients do not, because the site list is built from your repository names and those are usually client names.

What if we stop paying?

This answer used to be "nothing is switched off, because there is nothing central to switch off", and that is no longer true: a console account can be disabled. What cannot happen is the part that mattered. Your sites keep serving, because they serve from your Cloudflare. Your deploys keep running, because they run in your Actions. Your repositories stay yours, and the extension does not check in with anyone before it works. So a lapsed relationship costs you the console and not the websites. Being honest about the current state: pricing does not exist yet, so there is nothing here to sign.

Who owns the repository?

You do. It is created in your organisation, at your request, and every commit is attributed to the GitHub account of the person who made it. Commits go straight to the default branch, and where a branch protection rule blocks that, a pull request is opened instead and you are told it happened.

Is it available yet?

No. It is in development, there is no store listing and no download, and this page describes a design rather than a shipped product. The console is the newest part of that design and the least built: there is no server code at the time of writing, so nothing described here is a thing you can log into. If it sounds like it fits how your agency works, the most useful thing you can do is tell us which part of it does not.