Client sites that live in one GitHub organisation and one Cloudflare account.

Who it is for

Agencies that build marketing sites for other people. Today that is one agency, and it is us.

It is built around a job an agency does: a new client every few weeks who needs a small, fast, static site, launched quickly and edited for years afterwards. What it no longer asks of anyone is the infrastructure. There is one GitHub organisation and one Cloudflare account, both Rocket Lab's, and a client never sees either.

Read the rest of this page with one thing in mind, settled on 19 August 2026 and amended the same day. Rocket Sites is a Rocket Lab tool and Rocket Lab is the only agency using it. There is no price and nobody outside the company running it. The amendment is the part worth carrying: one agency is a count and not a design. A second one is possible, the product still has an agency in its data model rather than assuming there is only ever us, and the things that were decided on the strength of there being one would be reopened rather than inherited. The largest of those is that a Cloudflare credential comes to rest here, which was settled when the credential was ours.

What that changes about this page. It used to be written in the second person to an agency who brought a GitHub organisation and a Cloudflare account of their own, and it promised, in a dozen places, that both stayed theirs and Rocket Lab was in neither. That is no longer what happens, so those sentences have been rewritten rather than softened, and each one says what it used to claim. "You" now means whoever is running the tool, which is us, and where a paragraph is about the person who asked for the website it says so.

How it works

Four steps, then the site is a repository with its own history.

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. From the extension nothing has left the browser except the calls made to your AI provider with your own key. From the console the brief passes through a request of ours on its way to the model and to GitHub, and is discarded with that request.

4. 4

   Publish

   From the console, nobody makes a repository: the console does. It derives a name from the business name, resolves it against the one organisation so that two clients with the same name are an ordinary outcome rather than an error, creates the repository, commits the site into it, seals the Cloudflare credential into that repository's Actions secrets, and the deploy the commit triggers publishes it to a Cloudflare Pages project. Nobody is in the loop for any of it. The console's own audit log records who asked and what was done.

   The three paragraphs that stood here until 20 August 2026 said the opposite, and the code overtook them. They said a site began with an empty repository you made yourself in your own organisation; that Rocket Sites created no repository on any surface, with tests enumerating the reachable surface to keep it so; and that the decision to change that was settled but unbuilt. The first was a description of the old model, the second is now true of the extension and false of the console, and the third has been overtaken: creation shipped. The extension is the half that did not change, and deliberately so, which is the next paragraph.

   From the extension it still works the older way: somebody makes an empty repository, the extension reads it, refuses unless it can be proved empty so that nothing is written over, and commits the site into it. That is not a gap waiting to be closed. Creating a site was put in the console rather than given to the extension precisely so that the extension keeps making no request to us and holds no capability to create a repository at all, and the capability is in a file the extension does not ship.

   Being exact about the permission, because a security review will ask. Repository Administration is what GitHub bundles repository creation into, and the same permission allows deleting, transferring, renaming and flipping to public every repository in an organisation. The App holds it, and now has a caller for it. Until 19 August 2026 this page said the code had given it up and that the registration was waiting on a form somebody had to submit; that plan is cancelled rather than delayed, because unattended setup calls the endpoint this permission guards. While it is still granted the App can do all four of those things to every repository in an organisation that installed it, and since every client site is in one organisation, that is all of them at once. What limits it: creation, topic-setting and reading are the only calls made with it, there is no delete, transfer, rename or visibility change anywhere in the product, every write is in git history, and uninstalling the app ends every permission at once.

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, and there is no registry anywhere doing that lookup:

<meta name="source-repo" content="Rocket-Sites/acme-dental">

One tag, no registry, and no hostname guessing. The extension reads the page it is attached to and asks nobody, and it asks you once to confirm that this address really is published from that repository before it reads a line of it, because a page is something anybody can put a tag on. The console does keep a list of which repositories are sites, and it is a crawl of GitHub that can be thrown away and rebuilt rather than a record only we have.

A change you are not making now becomes a GitHub issue on that site'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 travels with the repository, 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 now everyone with access to the one organisation, and the issues travel with the repository if it is ever transferred to a client at the end of a relationship. That 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

We hold the whole site. What the control plane holds is a much shorter list.

This heading read "Three things get held, and none of them is your client's site" until 20 August 2026, and that is the single largest correction on this page. It was written when a client's site lived in an agency's own GitHub organisation and deployed to their own Cloudflare account. Since 19 August 2026 there is one organisation and one Cloudflare account and both are Rocket Lab's, so the site is in our repository, on our hosting, reachable by our credentials. Anybody weighing this product should start from that sentence and not from the one it replaced.

The shorter list is still worth having and it is what the rest of this section is about. The control plane is the console's own database, and it is a different thing from the GitHub organisation and the Pages account: it signs a person in, keeps a rebuildable index of which repositories are sites, records what was done in the console, and keeps the Cloudflare credential it needs to set the next site up. It holds no page body, no brief and no generated copy. Those transit a request and are discarded, and the repository is the record.

This page used to say there is no backend at all, 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 has grown exactly once, by one row, which is the Cloudflare token and is written up below the box.

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 a Cloudflare API token came to rest here in no form whatsoever: Connect Cloudflare checked it, sealed it into the site 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. There was an option that would have kept all three of unattended setup, one Cloudflare account, and no credential at rest, which was moving the GitHub organisation to a paid plan where an organisation-level secret reaches a private repository. It was put to the repo owner and declined.

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 being set up. If a holder of the account would rather nothing came to rest here, the two values can be set on the site repository by hand and Connect Cloudflare used never, in which case nothing of ours ever receives the token. Either way it stays a credential that can be revoked in the Cloudflare account without telling the console. The privacy policy sets out both routes and the difference between them.

The blast radius, because accepting it is part of the decision. One Cloudflare account now holds every client site's hosting, and one stored token reaches all of it: redeploy, deface, delete a Pages project, or take the pre-launch gate off a site that has not launched. That is written down in the architecture as the largest security regression in the design, ahead of the GitHub App key, and it is written down there rather than discovered here.

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.

Briefs, prompts and generated copy do not come to rest in the control plane. They transit and are discarded, and the commit in the repository is what survives. The one credential that comes to rest here is the Cloudflare API token, in which case one copy is kept encrypted and no screen or API of ours will return it.

And the part an outage makes real: no service of ours sits between a visitor and a client's page, or between a repository and its deploy. If everything of ours is down, a published site keeps serving and a site that already exists keeps deploying. Creating a new one stops, and that half is written up under what it costs.

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 keep one copy and here is how it is encrypted" is something you have to believe, and every competitor in this category says something like it. That second sentence replaced "we hold it briefly and discard it" on 18 August 2026, which was itself a claim you had to believe, so the weakening is a step further along a road this page was already on rather than a turn off it.

What is still checkable is narrower again since 19 August 2026, and this paragraph is where that shows. It used to end: the sites are in your repositories, the deploys run in your Actions, the pages answer from your Cloudflare, and the token is one you can rotate without asking us. Every clause in that list was a fact about somebody else's account, and there is no such account now. Two checkable things did survive intact, and they are both about mechanism rather than conduct. A published page is static files answered by Cloudflare with no service of ours behind it, which anybody can verify by looking for a request that never happens. And the extension reaches no Rocket Lab host at all, which is enforced against the built bundle rather than promised, so a build that so much as resolves one of our hostnames does not ship.

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 three times, in three 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. The correction to that promised the token could not outlive the request it arrived in, and on 18 August 2026 it stopped being able to make that promise. All three are gone. What is true today: there are still two routes, and which one is taken is a choice. Set the two secrets on the repository yourself and nothing of ours receives the token, or use Connect Cloudflare and it is verified, sealed into that repository, and one copy is kept encrypted under a key held outside the database. The first is a claim anyone can check without trusting us; the second is a claim about code we wrote and tested and which cannot be seen from outside. We would rather say which is which than let the convenient one borrow the checkable one's credibility. Since 19 August 2026 the honest footnote is that the account holding the token is ours either way, so the choice is now about where our own credential rests rather than about whether we hold somebody else's. Cross-device sync improves only halfway too: identity and the site list follow you to a second laptop, and the 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.

The 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 there is 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 the account. Since 19 August 2026 that account holds every client site, which makes this paragraph larger rather than smaller. 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 it runs on

Three things, and a client brings none of them.

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 Rocket Lab's GitHub organisation, and onto a Cloudflare Pages project in Rocket Lab's Cloudflare account. That answer changed on 19 August 2026: it used to be your GitHub organisation and your Cloudflare account, and it was the reason people liked this page. On the way there the content passes through the browser and the AI provider, because somebody 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 last sentence is a promise about our code; the one before it is a property of the design; the first two are simply where the site now lives.

What happens if Rocket Lab disappears?

This answer was rewritten on 20 August 2026 and it got worse, which is why it is rewritten rather than trimmed. It used to say the sites were static files in your repositories served from your Cloudflare account, so nothing about their survival involved us at all. That is no longer the shape of it. The repositories are in our organisation and the Pages projects are in our account, so a company that disappears takes the accounts with it, and what protects a site is a handover rather than the fact that you already hold the keys.

What is still true, and is a property of the design rather than a promise: a Rocket Lab outage cannot take a published site down and cannot stop a site that already exists from deploying. Serving is Cloudflare answering with static files and no service of ours behind them. A deploy runs in the site repository's own Actions with the credential already sealed into it, so one started while every host of ours is dark still finishes. Creating a new site is the half that does need us, and since 20 August 2026 that is a description of shipped code rather than a plan. The extension survives us too, because it never calls us.

The practical answer to the wider question is that a Rocket Site is an ordinary git repository of plain, hand-editable HTML, with its history, its issues and its deploy workflow in it, on a Pages project anybody with the account can redeploy. There is no proprietary format to extract and no runtime of ours to replace. Transferring one to a client is a GitHub transfer and a Cloudflare project, which is work somebody has to do, and this page is not going to describe that as nothing.

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: a client's page content follows the same rule as the prompt, and the names of clients do not, because the site list is built from 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 was described here as your GitHub rather than ours until 20 August 2026, and it is now the one organisation, which makes the readership everyone with access to it. It is deliberate either way, 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?

Also rewritten on 20 August 2026, and in the same direction as the one above. It used to answer: your sites keep serving because they serve from your Cloudflare, your deploys keep running because they run in your Actions, and your repositories stay yours. None of those three is a sentence anybody here is now in a position to say, because the account, the runner and the organisation are all ours. What survives is that a published site keeps serving and a site that exists keeps deploying whatever happens to our console, and that a Rocket Site is plain HTML in an ordinary repository, so there is something concrete to hand over. Being honest about the current state: pricing does not exist yet, so there is nothing here to sign.

Who owns the repository?

Rocket Lab does. It is created in Rocket Lab's organisation, by the console, and every commit is attributed to the GitHub account of the person who made it. This answer used to be "you do", and the change on 19 August 2026 is deliberate rather than a slip: a client asking for a website does not want a GitHub account, and the price of that is that they do not hold one. 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 from the Chrome Web Store. There is no listing, so the extension is installed by hand from a build we publish, which is a real procedure rather than a button and does not update itself; the install page is the whole of it, including what that costs. The rest is further along than that sounds and it would be coy not to say so: the console runs, it creates a client site and publishes it with nobody in the loop, 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.