Rocket Sites by Rocket Lab

Install

Installing it is a procedure, not a button.

Last updated 20 August 2026.

There is no Chrome Web Store listing yet, so there is no one-click install and no automatic update. What there is instead is a zip built by the release workflow, and four steps in chrome://extensions. It takes about a minute and it works today. The rest of this page is what it costs, because a build installed this way is frozen at the version you downloaded until you repeat the procedure.

Chrome will not install an extension from a website, and no amount of web design changes that. Downloading a .crx file and opening it does not install anything: Chrome discards it and, at best, opens the extensions page to tell you it will not. This has been true on every desktop platform for years and it is not a setting a visitor can flip. Any page anywhere offering you an "Install" button for a Chrome extension outside the store is either taking you to the store or wasting your time.

So this page does not have one. The two mechanisms that actually install an extension are the store, and Developer mode with an unpacked folder. The store route is not available yet. The second one is below.

Three things have to be true before the download works, and today none of them is

Written down here rather than left for you to discover as a 404. The procedure below is correct and will keep being correct; what is not ready is the file it starts from.

  1. A release has to be tagged. The release workflow fires on a tag of the form extension-v0.0.0 and has never run, because nobody has pushed one. Until then the releases page is empty.
  2. Somebody has to publish the draft. The workflow deliberately creates the release as a draft, and a draft's attachments are not downloadable. That is not an oversight: the draft is the gate in front of a store upload, and it stays.
  3. The repository has to be readable. It is private today, and release assets on a private repository are not public downloads. Whether that changes is a decision for the people who own the repository and not something this page can arrange.

If you are inside Rocket Lab and signed in to GitHub, the first two are the ones in your way. If you are not, all three are.

The procedure

  1. Download the zip from the releases page. Open the repository's releases, take the newest one, and download the rocket-sites-<version>.zip attached to it. That file is built by the release workflow rather than assembled by hand, which is what makes the next paragraph true.
  2. Unzip it somewhere you will not delete. This is the part people get wrong. Chrome does not copy an unpacked extension anywhere: it loads it from the folder you point at and keeps reading that folder. Move it or delete it and the extension breaks. Downloads is a bad choice; a folder you keep is a good one.
  3. Open chrome://extensions and turn on Developer mode. The toggle is at the top right. Chrome will warn you about developer extensions on some launches from now on, which is Chrome doing its job and not a sign anything is wrong.
  4. Click "Load unpacked" and choose the unzipped folder. Pick the folder that contains manifest.json directly, not the folder containing that folder. The panel appears in the side panel menu, and it will ask you to sign in to GitHub and to set an AI provider key before it can do anything.

This build does not update itself. Not slowly, not eventually: not at all. A store install updates in the background within a day or so of a release. A folder loaded in Developer mode is pinned to the bytes you downloaded, forever, until you download a new zip and repeat all four steps. Nothing prompts you. Nothing tells you a newer build exists.

That matters more here than it would in most products. A panel showing you stale behaviour looks exactly like a bug, and it is the single most common false alarm this product produces: somebody reports a problem that was fixed a fortnight ago, and the answer is that they are looking at an old build. Read the next section before you report anything, and expect to repeat the procedure whenever you are told a fix has landed.

How to tell which build you are looking at

The panel reports three things about itself, and between them they settle the question without anybody guessing. Two of them are the ones to trust.

  • Version. The number in manifest.json, and the same number in the release tag and in the zip's filename. The release workflow refuses to build unless the tag, extension/manifest.json and extension/package.json all say the same thing, so tag extension-v0.44.4 produces rocket-sites-0.44.4.zip and a panel that reports 0.44.4, and there is no arrangement in which those three disagree.
  • Build. The commit the bundle was compiled from, stamped in at build time, with a + if the tree was dirty when it was built. This is the field that actually settles an argument, because a version number is bumped by hand and a forgotten bump looks exactly like a stale panel.
  • Built at. When the bundle was compiled. Useful for the same reason and for spotting a folder Chrome is still reading after you thought you replaced it.

If the panel's version does not match the newest release, you are on an old build and the procedure above is the fix. If it matches and something still looks wrong, that is worth reporting.

What it asks for, and what it does not

Worth reading before you install rather than at the first permission prompt. The extension holds your GitHub authorisation and your AI provider key in the browser's own extension storage, in one browser profile, and sends each of them only to the service it authenticates to. It reads the page you point it at, and only after you confirm once that the page's address really is published from the repository the page names.

It makes no request to any Rocket Lab host at all. That is not a promise in a paragraph: it is a check that runs over the built bundle before a zip is written, and a build that so much as resolves one of our hostnames fails it and never gets packaged. The privacy policy is the longer version of all of this, and it is written from the manifest and the settings module rather than from the pitch.

When there is a store listing, this page becomes a link

The intended end state is an unlisted Chrome Web Store listing: it does not appear in search or in the category pages, anybody with the link installs in one click, and it updates itself. That removes every cost on this page at once, and it is the reason the procedure above is written as a stopgap rather than as the way this product is meant to be installed.

What it needs is a developer account, a registration fee and a review pass, and until those exist there is nothing to link to. When the listing does exist, the four steps above are replaced by a button here and this page stops being a procedure. The rest of it, the version and build stamps and what the extension asks for, is worth keeping either way.

Back to the main page