Privacy policy
What we hold, what we do not, and where your data actually goes.
This policy covers the Rocket Sites browser extension, the Rocket Sites console at
admin.rocketsites.online, and this marketing site. It does not cover the websites
you build with it: those are published to your own Cloudflare account from your own GitHub
repositories, and what they collect from their visitors is between you and your client.
The short version. The extension sends nothing to us at all. The console holds who is signed in, a list of which of your repositories are sites, and a record of what was done in the console. Your clients' page content, your briefs and your prompts pass through a request on their way to GitHub and are discarded with it. Your Cloudflare API token is the one credential of yours we may hold: put it into your own repository's secrets yourself and nothing of ours ever receives it, or use the console's Connect Cloudflare form, in which case we keep one encrypted copy so that a site we set up for you later needs no second paste.
That paragraph has now been corrected twice, in opposite directions, about the same sentence. It first said the token never reached us in any form, which stopped being true when the console shipped a form that receives one. It then said we never stored it, which stopped being true on 18 August 2026, when setting a client site up stopped needing a person and a brand new repository had to be given a Cloudflare credential nobody was there to paste. The section on the token below sets out both routes, how the stored copy is protected, and which of the two you can check without trusting us.
The rest of this page is the detail behind those sentences, including the parts we cannot yet answer.
Three surfaces, three different answers
Rocket Sites is three separate things, and merging them into one reassuring paragraph would hide the only distinction that matters here. So they are answered separately below:
- The extension runs in your browser and makes no request to any Rocket Lab host.
- The console is a service we run. It has an origin, a session, a database and secrets at rest.
- A published client site is static files on your own Cloudflare, deployed by a workflow that runs in your own GitHub Actions. Nothing of ours sits between a visitor and that page, or between a repository and its deploy.
The extension
The extension makes zero requests to Rocket Lab infrastructure. Not a telemetry ping, not a licence check, not a config fetch, not an error report. That is a rule with a test behind it rather than an intention: a build that reaches a Rocket Lab host fails the check and does not ship. The check is an allow-list rather than a list of banned names, so a hostname nobody thought of fails too, and it follows the extension's imports into the shared code rather than stopping at the folder boundary.
It stores what it needs in chrome.storage, inside your browser profile. That
includes your GitHub access and refresh tokens, your AI provider key, your GitHub username,
and your preferences. We never receive any of it, because there is nowhere for it to be sent
to us.
Your conversations are not kept in the browser, and they are not kept by us either:
they are written to your own GitHub. Since 13 August 2026 a request is an issue on the
client's repository and the turns of the conversation are its comments, so your prompts and the
model's replies live in your organisation, readable by everyone who can read that repository,
and they transfer with it when a client relationship ends. The copy in
chrome.storage is a cache of that. This is a deliberate trade for a tool a team
uses rather than one person, and it is stated here because a policy that describes only the
cache would be describing the smaller half. A credential is refused before any of it is
written, as is a file body: a unified diff, a whole HTML page, or a fenced block over 2,000
characters.
The hosts it may reach are declared in its manifest and enforced by the browser, and you can
read that file. The standing list is GitHub (api.github.com and
github.com/login) and the three AI providers it supports (Anthropic, OpenAI, and
GitHub Models). Your prompt goes from your browser directly to whichever of those you chose,
authenticated with your own key. Your provider's own privacy terms apply to it, and no key or
intermediary of ours is involved.
Beyond that standing list it asks for access to any site, granted per page by you when you use it. That is how in-context editing works: it reads the client page you are attached to in order to edit it. Broad permission is worth understanding rather than glossing, so the exact shape of it is that the browser asks you, per page, and the page it reads goes to your AI provider and to GitHub, and to nobody else.
One honest caveat about your browser, not about us. Settings are written to
chrome.storage.sync as well as to local storage, so that a second machine picks
them up. If you have Chrome profile sync enabled, your browser copies that data to your
Google account, which is Google's service and Google's terms, not ours. If you would rather
that did not happen, turn off extension sync in Chrome, or turn off profile sync. We cannot
see either copy.
The console
The console at admin.rocketsites.online is a service we run on Cloudflare, in
Rocket Lab's own Cloudflare account. What it does, in full: it shows an agency the fleet of
sites it owns, it refreshes that view by crawling their GitHub, it fills an empty repository
with a new site from a brief, it seals a Cloudflare API token into a repository's Actions
secrets and keeps one encrypted copy of that token, it changes how one site publishes by
writing to that site's own repository, and it starts a redeploy. It is a control plane: it is
deliberately not in the path of any client site, and switching it off does not take a
published site down or stop a deploy.
This paragraph used to say the console did three things and that everything else it appeared to offer was a link into GitHub or Cloudflare. The first three are the same three; the last three are real actions and were being described as signposts. They are all writes to the agency's own GitHub, made with the agency's own installation, and none of them stores anything here beyond the index row and the audit row described below.
Here is everything it holds.
| What | Where it lives | Why it exists |
|---|---|---|
| Who is signed in | An encrypted, HttpOnly session cookie in your browser. There is no sessions table and no token column in our database | A console cannot sign anyone in without knowing who they are. The cookie carries your GitHub login, your numeric GitHub user id, and your GitHub user token, sealed with AES-GCM. It expires after eight hours, matching the lifetime GitHub gives the token |
| Your agency | One row: a generated id, your GitHub organisation login, and a creation timestamp | The GitHub organisation is the tenant boundary, because it is the boundary GitHub already enforces and the one you can revoke yourself by uninstalling the app |
| Your app installation | One row: the GitHub installation id and your agency id | It records that you installed the Rocket Sites GitHub App. GitHub remains the authority; this row is removed when you uninstall |
| The site index | One row per site repository: the repository full name, the Cloudflare Pages project name, the site URL, a custom domain if there is one, the publishing mode, the template slug, the last deploy status word, and timestamps | The fleet view. It is built by crawling your own GitHub for a topic, so it is a cache and not the original. It carries repository names, and a repository name is usually a client's name. That is the honest cost of having a fleet list at all, and it is the one place where a client's identity, rather than their content, reaches us |
| Your Cloudflare API token, if you connected one | One row per Cloudflare account: your agency id, the account id, the token encrypted, the encrypted form of the key that encrypts it, and a timestamp | So that a client site we set up for you can be given a working deploy credential without asking you to paste one per site. The encryption is per row: each token gets its own key, and that key is stored only in a form wrapped by a control-plane secret that is not in the database and is separate from the one protecting sessions. No screen and no API of ours returns it, whole or in part. One function in the product can decrypt it, and all it does with the result is seal it into your repository. Added 18 August 2026; before that the token was thrown away inside the request that received it |
| The audit log | One append-only row per action: a timestamp, the GitHub login of the person who caused it, a verb from a fixed set such as sites.refresh or auth.signin, the repository or organisation it targeted, whether it succeeded, and a short status string |
So that "who changed what" has an answer. The status string is bounded to a few words such as pruned 3. It is never a request payload. You can read your own timeline in the console, under Audit log: a record we hold about you and will not show you would be a weaker position than holding none |
That is the whole list. There are no billing, seat, metering or subscription records, because there is no pricing. There is no analytics, no session recording, no advertising identifier, and no third-party tracker anywhere in the console: its content security policy forbids loading anything from another origin at all.
We do not sell or rent any of this, and we do not use it to train models.
What transits and is discarded
When you create or change a site from the console, the material passes through a request of ours on its way to your GitHub repository, and is discarded with that request. What survives is the commit in your repository, which you can read. This covers:
- Your clients' page content, HTML and assets.
- Your briefs, your prompts, and the copy an AI model wrote from them.
- Site titles, descriptions and every slot value in a site's configuration. The crawler that builds the fleet index reads these and throws them away, because they are the client's copy.
This is enforced rather than promised in prose: no column in our database may hold site content, and two automated tests reject a schema change or a request handler that would put one there. That is a stronger guarantee than a policy sentence, and it is still weaker than the claim this product used to make, which was that there was nowhere for content to land at all. We would rather say that plainly than let the new wording borrow the old one's confidence.
Your Cloudflare API token
Publishing a site needs one Cloudflare API token, scoped by you to Cloudflare Pages and Cloudflare Access. It ends up in your own GitHub repository's Actions secrets, where the publisher reads it while running inside your own GitHub Actions. There are two ways to get it there, and they differ in whether we ever see it.
If you set it yourself, on your repository's Actions secrets page, nothing of ours ever receives it. The console tells you which two secrets to set and links you to the page, and that is the whole of its involvement.
If you use Connect Cloudflare in the console, the token is sent to us once, over TLS. We check it is live, check it can reach Cloudflare Pages, check it can actually create a Cloudflare Access application rather than merely read one, encrypt it with your repository's own public key and hand the encrypted value to GitHub. We then keep one copy, encrypted, and that is the part of this page that changed on 18 August 2026.
Why we keep it. Rocket Sites can now set a client site up with nobody in the loop. That means creating a repository which did not exist a minute earlier and giving it a Cloudflare credential before its first deploy runs, and GitHub will not hand a secret back to anybody once it has been written, including to the app that wrote it. So a console that kept nothing could not set up your second site without asking you for the token again, and your third, and your fortieth. Keeping it is what makes one paste do for all of them. This paragraph used to say the opposite, in as many words, and it was true when it was written.
How it is kept. One row per Cloudflare account. The token is encrypted with a key generated for that row alone and used for nothing else; that key is stored only in a form wrapped by a separate control-plane secret which is not in the database, and which is not the key that protects console sessions, so replacing one of the two does not force the other. Two rows made from the same token share no bytes, so reading one of them tells an attacker nothing about the next. Nothing in the product returns the value: not a screen, not an API response, not a log line, not a masked or shortened version, and not the encrypted bytes either. Exactly one function can decrypt it, and the only thing it does with the result is verify it against Cloudflare and seal it into a repository of yours.
What it costs you, stated rather than left for you to work out. A Cloudflare API token scoped for publishing can deploy to, deface and delete every site in that Cloudflare account, and can take the Access gate off a site that has not launched. Holding one makes this console worth attacking in a way it was not before. That is the trade, and it is why the protections above are described here in enough detail to be argued with.
The honest shape of the difference: setting it yourself is a claim you can check without trusting us, and using the form is a claim about code we wrote. The code is tested for it, which is not the same as you being able to see it. If you would rather we held nothing, set the two values on your repository yourself and never use the form.
The token never reaches the extension by either route. You can rotate or delete it at any time without asking us, and we would not notice.
It goes on the repository, not the organisation. On GitHub Free an organisation secret is invisible to a private repository, so an org-level secret silently produces an empty value and a failed deploy on a repository whose settings look correct.
This marketing site
The page you are reading is handwritten HTML and CSS served as static files. It sets no cookies, runs no JavaScript, loads no font, script or stylesheet from any other host, and has no analytics or advertising beacon of any kind. Nothing here identifies you.
It is hosted on Cloudflare Pages, so Cloudflare processes the request as our hosting provider and keeps its own operational logs, in the way any web host does.
Who else your data reaches
We use a small number of providers to run the product. This is the complete list:
- GitHub. Where your repositories, your site content and your commits live, and who signs you in to the console. This is not us passing your data to a third party: it is your own GitHub organisation, under your own agreement with GitHub.
- Cloudflare. Hosts the console, its database and this marketing site, in Rocket Lab's own Cloudflare account. Separately, and under your own agreement with Cloudflare, your client sites are hosted in your Cloudflare account, which we hold no credential for at all.
- Your AI provider. Anthropic, OpenAI, or GitHub Models, chosen by you and billed to your own account. Prompts go to them directly from your browser.
There is no analytics vendor, no error-reporting vendor, no marketing or email platform holding a list, and no advertising network. If that changes, this page changes with it.
Retention and deletion
The site index is regenerable, so it can be deleted at any time and simply rebuilt by re-crawling GitHub. Sessions expire after eight hours. Agency and installation records last as long as your account does, and the installation record is removed when you uninstall the GitHub App.
To close a console account, email hello@rocketlab.com.au. We delete your agency record, the admins under it, and the site index. We keep the audit log for the rest of its retention period, because an append-only record that can be erased by the party it audits is not an audit log.
The audit log is kept for 400 days, and then deleted. Thirteen months: long enough that "what changed on this site around this time last year" is a question we can still answer for you, short enough that the log does not become a permanent register of which clients you have had. Set on 2026-08-13. This page previously said the period was undecided and that we would not invent one, which was the honest answer at the time.
It is enforced by the database rather than by a policy somebody has to remember. Rows older than the period are deleted, and rows younger than it cannot be deleted, by us or by anybody: the same rule that stops an audit row being edited is what stops it being removed early. That is the whole point of the record.
To have data removed, or to ask what we hold about you, email the address above. There is genuinely not much: your GitHub login, your organisation, your repository names, and your console actions. Everything else that matters is already in your own accounts, which is the point of the design.
What you can revoke without asking us
Most of the switches are yours, and none of them requires our cooperation:
- Uninstall the GitHub App in your organisation's settings. That ends our access to your repositories immediately, and every console session dies with it.
- Rotate or delete the Cloudflare API token in your own Cloudflare account, and remove it from your repository secrets. Sites already published stay published: the token deploys sites, it does not serve them.
- Remove your AI key from the extension, which clears it from
chrome.storage, and revoke it in your provider's console. - Delete or archive the repositories. They are yours, in your organisation.
Security
The session cookie is encrypted with AES-GCM and marked HttpOnly, Secure and SameSite=Lax, so the GitHub token inside it never reaches a database row and cannot be read by scripts in your browser. Every table in the database carries a tenant key from its first migration, and the queries are checked against it, because a missing tenant predicate is how one customer reads another's rows. The console loads no code from any other origin.
Adding a service also added the risks that come with one, and we would rather list them than let you discover them. There is now a database that can be breached, secrets at rest that can be stolen, a GitHub App private key that can act on every organisation that installed the app, and, since 18 August 2026, an encrypted copy of any Cloudflare API token connected through the console. That last one is the largest, which is why it has a section of its own above. None of it holds a client's page content, and "there is nothing to breach" was an answer we could once give and no longer can.
If you find a security problem, email hello@rocketlab.com.au. We would rather hear it early and awkwardly than late.
What this policy cannot yet tell you
The product is in development and some answers do not exist yet. Stating that is more useful than a confident sentence nobody has checked:
- No tested restore of the console database. Cloudflare D1 has a recovery mechanism with a real bounded window, and nobody here has written down what that window is or restored from it. Until somebody does, treat backups of the console as unproven. Nothing of yours depends on it: the site index rebuilds by re-crawling GitHub, and your sites and their history live in your own GitHub and your own Cloudflare.
- No claim of compliance with any particular regime. We are not asserting GDPR, CCPA, SOC 2, ISO 27001 or any certification, because none has been assessed. If you need a formal position for a procurement process, ask, and you will get a real answer or an honest "not yet" rather than a badge.
- No data protection officer and no EU or UK representative have been appointed.
- No named sub-processor list beyond the three above, and no data processing agreement template. Ask if you need one.
- Data location is wherever Cloudflare places it for our account. We have not pinned a region, and saying otherwise would be a claim nobody has verified.
Changes to this policy
When this page changes, the date at the top changes with it. The page lives in the product's own repository, so every edit to it has a commit and a diff behind it. If a change makes the product hold something it did not hold before, it will be described here in the same words the rest of this page uses rather than folded into a broader sentence.