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

   You make an empty repository in your own GitHub organisation. The site is committed into it as its first commit, and your own GitHub Actions deploys it to your own Cloudflare Pages. You are asked before that commit, and it shows up in your organisation's audit log.

   Rocket Sites does not create repositories, on any surface. No code in the extension, the console or the shared library makes that call, and tests enumerate the whole reachable surface to keep it that way. The permission it would need, repository Administration, also allows deleting, transferring and flipping to public every repository in an organisation, which is more than saving one click is worth.

   Being exact about that permission, because a security review will ask and the honest answer has two halves. The code gave it up on 13 August 2026. The App registration still carries it, and taking it off is a form only the App's owner can submit, followed by a re-approval round in every organisation that installed it. Until that happens the capability exists even though nothing uses it, and this page is not going to describe it as gone while our own record of the App says otherwise. What you can do about it in the meantime is the thing that always worked: uninstall the app, which ends every permission at once.

   Before the commit, the repository is read and refused unless it can be proved empty, so a site is never written over anything you already have. Attaching a custom domain is yours too.

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.

A change you are not making now becomes a GitHub issue on that client's own repository, labelled so the product never touches an issue it did not create, and when a commit answers it the issue gets one comment naming the file, the lines added and removed, and the commit. The backlog is the client's, in the client's repo, and it outlives us and the extension both.

The conversation is in there too, and this page said the opposite until 15 August 2026. It told a reader the issue carried the request and not the exchange that produced it. That stopped being true on 13 August, when the decision was reversed on the grounds that a conversation living in one person's Chrome profile is single-player and this is a tool a team uses. The issue body is the request and the comments are the turns, so your prompts and the model's replies are written to the client's repository, and the browser's copy became a cache you can throw away.

Read that as a privacy consequence rather than a feature note, because it is both. An issue is readable by everyone who can read the repository, which is your whole organisation, and the issues travel with the repository when a client relationship ends and you transfer it. That now includes what you tried, how you phrased it, and any candid remark typed into the composer. Better met here than at handover. Two things are still kept out by a check rather than by a habit: no credential ever reaches an issue, and a file body is refused, meaning a unified diff, a whole HTML page, or a fenced block over 2,000 characters. A short fenced snippet is allowed on purpose, since refusing every fence would refuse a model explaining itself with three lines of HTML.

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 was 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 was built, and what it is allowed to hold was published before it existed rather than after. It now exists, and the list below did not grow on the way.

One line moved from the right-hand list to the left on 18 August 2026, and it is the most sensitive line on this page. Until that day this box promised that we held your Cloudflare API token at rest in no form whatsoever: Connect Cloudflare checked it, sealed it into your repository, and threw it away inside the one request. That is no longer what happens, and you are owed the reason rather than a quiet edit. Rocket Sites now sets a client site up with nobody in the loop, and a repository that did not exist an hour ago has to be given a Cloudflare credential before its first deploy runs. GitHub never hands a secret back, not even to the app that wrote it, so the only way to give the new repository one is to have kept it. What you get for that is a token you paste once instead of once per site.

How it is kept, stated plainly so you can weigh it rather than take our word for the shape of it. One row per Cloudflare account. Encrypted with a key generated for that row and used for nothing else, which is itself wrapped by a key that lives outside the database and is separate from the one protecting our sessions, so replacing either does not force the other. No screen and no part of our API will return it, in full or in part, and there is one function in the product that can decrypt it: the one that seals it into a repository we are setting up for you. If you would rather we held nothing, set the two values on your repository yourself and use Connect Cloudflare never, in which case nothing of ours ever receives the token. Either way it stays a credential you can revoke in your own Cloudflare account without telling us. The privacy policy sets out both routes and the difference between them.

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 we hold no credential that can reach your Cloudflare: your token either never reaches us at all, or reaches us for the length of one request and is gone when it ends.

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.

The same list, said once more in the language a compliance question is asked in, is the privacy policy. It goes further than this section does: every column the console stores, the retention answer that does not exist yet, and the claims we are not making.

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.

A fifth thing belongs here because this page has now been wrong about it twice, in opposite directions, and leaving the corrections visible is more use than a silent edit. An early draft said the Cloudflare token step was automated before any code did it. The correction to that then said nothing of ours would ever receive the token, and stayed on this page after the console shipped a form that receives one. Both are gone. What is true today: you choose. Set the two secrets on the repository yourself and nothing of ours receives the token, or use Connect Cloudflare and it transits one request that verifies it, seals it into that repository and discards it. The first is a claim you can check without trusting us; the second is a claim about code we wrote, tested for, but which you cannot see from outside. We would rather say which is which than let the convenient one borrow the checkable one's credibility. Cross-device sync improves only halfway too: your identity and your site list follow you to a second laptop, and your AI key does not, because it stays in one browser profile.

The per-repository part catches people out, so it is worth stating once here rather than only in the docs. On GitHub Free, an organisation-level Actions secret is not readable from a private repository. It does not error: it arrives empty, and the deploy fails somewhere that looks unrelated while the organisation's settings page shows the secret sitting there, apparently correct. Set the two Cloudflare secrets on each site repository.

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.

Your Cloudflare token is never on the machine that builds the site

This one is worth a paragraph because it is not obvious and it is the part of a deploy an agency has the most to lose from. Cloudflare cannot scope a Pages token to a single project, so the token in one client's deploy can reach, redeploy and delete every Pages project on your account. Put that credential on the same machine as anything a client repository can make run, and push access to one site becomes push access to all of them.

That was not hypothetical. Under Tailwind 3 the build read a config file out of the site's own repository and executed it as Node, which is the documented behaviour of the tool rather than a trick played on it, and it happened in the job holding the token. The build now pins Tailwind 4, whose theme is CSS and which has no config module to run, and the brand values are read as JSON and checked before they are written. So nothing in the repository is executed during a build today. The separation stayed anyway, and that is the point: it is what makes the property survive the next tool that decides to read a file.

So the build runs in a separate job with no credential in it at all, on its own machine, and hands the finished files on as an artifact. The job that talks to Cloudflare never checks the site out and never runs a line of its code. That is a job boundary rather than a step boundary, deliberately: every step of one job shares a runner and a user, so code running in an earlier step can read a later step's environment, and the separation has to be a property of the machine to be worth anything. A test plants a config file that really does steal the token, proves it works where the credential lives, and proves it captures nothing where the site is built.

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, indefinitely, with no action from anyone. The sites are static files in your repositories served from your Cloudflare account, and nothing about serving them involves us. Deploying again is very nearly as safe and the difference is worth naming rather than rounding off: the workflow runs in your Actions, but your Actions fetch it from a public GitHub repository we own, so a future deploy wants that repository to still be there. Pin it to a commit and copy it into your own org and even that goes away. What is no longer true is that you would lose nothing else. An agency 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 across all their clients, the deploy statuses, the ability to onboard a new client or create a site from a brief without the extension, and eventually the ability to sign in at all. The console's own record of who did what stops being written, and you lose the screen that reads it back, which is a smaller loss than it sounds: it covers console actions only, and the audit trail that covers your actual work is your git history and your Actions log, in your own organisation. The sites survive us, and so does the extension, which needs nothing from us to work. The way you run a fleet of 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.

Who else can is the more useful question, and the answer changed on 13 August 2026. Prompts and model replies are now written as comments on the issue in the client's own repository, so everyone who can read that repository can read them, and they transfer with it. That is your GitHub rather than ours, and it is deliberate, because a conversation held in one person's browser profile cannot be picked up by a colleague. It is worth knowing before you type something into the composer that you would not put in a ticket.

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?

Not as something you can install. There is no Chrome Web Store listing and no download, so the extension is not a thing you can get today. The rest is further along than that sounds and it would be coy not to say so: the console runs, the publisher has published a real site from a real repository to a real Cloudflare Pages project, and the parts this page describes are built rather than drawn. What has not happened is a release to anybody outside the people building it. 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.