In development. Nothing is published yet, and there is no download.
Client sites that live in your GitHub and your Cloudflare.
Pick a template, describe the client, and get a complete multi-page site (landing page, privacy policy, terms of use) published to your own Cloudflare from your own GitHub. Then keep editing it by chatting with an AI while you look at the live page.
The unusual part is what is missing. There is no backend: no database, no server, no service. Not one we run for you, and not one you have to trust.
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.
A fit if
- You build sites for clients and hand them over, or hold them on the client's behalf.
- You want each client site in its own repository, with its own history.
- You would rather own the hosting relationship than rent it from a site builder.
- You are comfortable creating a Cloudflare API token and adding two GitHub secrets, once.
Not a fit if
- You want a site for your own business, with a credit card and no GitHub account. Self-serve site builders do that well, and they do it by hosting the site for you, which is the opposite of the model here.
- You need a content management system, dynamic pages, or a shop. These are static sites.
- You need one login that every colleague shares. Every person signs in as themselves.
How it works
Four steps, then the site is a repository you own.
-
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.
-
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.
-
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.
-
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, no hostname guessing, and no list anywhere of who owns what.
The centrepiece
There is no backend.
Most tools in this category are a service with a website attached. This one is three artifacts and no service: a browser extension, a template library, and a reusable GitHub Actions workflow that runs in your organisation. "We do not store your data" is a promise. This is the version of that claim you can check, because there is nowhere for the data to be stored.
Here is every piece of state the product has, and where it lives.
| State | Lives in | Why there |
|---|---|---|
| Site content: HTML and assets | Your GitHub repository | The source of truth. Content is read and written through the GitHub API and only ever transits the browser. |
| Per-site config: template, brand tokens, slot values | rocket-site.json, in the site repository |
Versioned with the site it describes, so the config and the site can never disagree. |
| Site inventory: what sites do we have? | GitHub, as repositories carrying the rocket-site topic |
Crawlable and regenerable. There is no index that can drift out of sync, because there is no index. |
| Auth tokens, AI key, preferences | chrome.storage, in your browser profile |
Never sent anywhere except the provider they authenticate to. |
| Audit trail | Git history and the Actions run log | Genuinely append-only, in your organisation, and it already exists. |
| The published site | Your Cloudflare Pages | Deployed by your own CI, with your own Cloudflare token. |
| Access policy: who can see a site before launch | Your repository variables, reconciled into Cloudflare Access | Declared in the repository, applied on every deploy, so a manual change never quietly persists. |
Nothing about a client's site, prompt, or content touches Rocket Lab infrastructure, because there is no Rocket Lab infrastructure in the path.
What that costs
Four things you give up, stated here rather than discovered later.
Having no backend is not free. These are the consequences, and they are permanent for as long as the design holds. If you read one section on this page, it should probably be this one.
There is no free tier, and there cannot be one
You bring your own AI provider key: Anthropic, OpenAI, or GitHub Models. A free tier would mean a server holding a provider key on your behalf, and there is no server. Generating a site costs you whatever your provider charges for it, billed to you, visible to you.
No seats, no metering, no billing through us
There is no dashboard showing who at your agency used what, no per-seat pricing, and no usage report, because counting usage requires somewhere to count it. How the product itself is paid for is genuinely not settled yet.
Nothing central to revoke
Access control is GitHub's and Cloudflare's. Removing someone means uninstalling the app or rotating your Cloudflare token. There is no kill switch anyone owns, including us. That cuts in your favour and against it: nobody can switch you off, and nobody can switch anything off for you either.
No cross-device sync
Settings, tokens, and your AI key live in one browser profile. A second laptop means signing in again and pasting the key again. Nothing follows you around, because nothing is holding it.
There is one more, and it belongs here rather than in a footnote: setup is manual. Your Cloudflare API token has to be added to your GitHub organisation by hand, once, because the alternative is shipping encryption into a browser extension so it can handle your most powerful credential.
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.
| Mode | Who can reach it | What a deploy has to prove |
|---|---|---|
| Public, the default | Anyone | The site returns HTTP 200 and the response body carries that repository's source-repo tag. |
| Gated, opt in for the review window | Only the client email addresses you name, through Cloudflare Access | An unauthenticated request redirects. No access gate means no publish. |
Restriction is never inferred
A site is gated because its repository says so, and for no other reason. Not from the branch, not from the environment, and not from an access rule the publisher happens to find lying around on your Cloudflare account. Asking for the review window is an explicit change committed to the repository, reviewable before it happens and visible in the history afterwards.
Proof, not assumption
A deploy never reports success on an unproven state. HTTP 200 on its own is not proof a site is live, because placeholder pages and unrelated projects return 200 too. A gate is proven by a redirect, and it covers wildcard preview URLs as well as the main address, since a static host cannot simply turn preview deployments off.
What you bring
Three things, all of which you keep.
A GitHub organisation
Client site repositories are created inside it. You install the app on the organisation, and you uninstall it whenever you like. Two Cloudflare values go into the organisation's Actions secrets by hand, once, and every future site repository inherits them.
A Cloudflare account
Sites deploy to Pages projects in your account. You create one API token, scoped to Pages and to Access, and it never leaves your GitHub organisation. Worth knowing before you start: Cloudflare allows 100 Pages projects per account, and this model uses one per client site.
An AI provider key
Anthropic, OpenAI, or GitHub Models. Your key, your account, your bill, your rate limits. The prompt goes from your browser to that provider and nowhere else.
FAQ
The questions an agency should ask.
Every answer below follows from how the thing is built, not from a promise about how we intend to behave.
- 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. It does not pass through us at any point, and there is no copy of it anywhere we control.
- What happens if Rocket Lab disappears?
- Every published site stays up, because the sites are static files in your repositories served from your Cloudflare account, deployed by a workflow running in your Actions. Nothing about serving them involves us. What you would lose is future improvements to the tool, and eventually the ability to sign in to the extension, since sign-in goes through a GitHub app we register. You would lose the editor, not the sites, and the sites would still be plain HTML you can edit any way you like.
- Can you see our prompts?
- No. The prompt goes from your browser directly to the AI provider you chose, authenticated with your key. There is no intermediary to log it, and no key of ours involved. The same is true of your clients' content and the names of your clients.
- What if we stop paying?
- Nothing is switched off, because there is nothing central to switch off. However this ends up being paid for, it cannot be a subscription that holds your sites hostage: your sites run on your infrastructure with your credentials, and the repositories are yours whatever happens to the relationship. Being honest about the current state: pricing does not exist yet.
- 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. 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.
Interested, or unconvinced?
Both are useful. It is being built for agencies, so the fastest way to change it is to be an agency with an opinion about it.