Ship to the Chrome Web Store

Shipping moves a tool from Test to Live and puts the Live build of your extension on the Chrome Web Store. Buyers then pay with real cards, on your own Stripe account.

This guide covers the first release and every update after it. It starts where the Quickstart ends: a tool on Test, an extension wired to it, a test purchase made.

Before you begin

The tool works on Test: its Free plan, plans and features are set under Pricing, and a test purchase unlocked the extension.
Your code gates what you sell with gate(), and answers a refusal with showPaywall(). See Gate your extension.
A Chrome Web Store developer account. Registering costs a one-time fee, paid to Google.
Your own Stripe account, activated for live payments.
The command line signed in on Live: npx -y toolaby@latest login --live.

1. Connect Stripe on Live

Open the dashboard at toolaby.app/dev. Under Configure → Payments, select Connect and complete Stripe's onboarding with your own account.

When it worked, the Payments page shows your account as able to take payments. Until then, Copy to Live creates the tool but not its plans.

2. Copy the tool to Live

On Test, open the tool's Keys page and select Copy to Live.

The Wall creates the tool on Live with the same tool id, its Free plan, its features and its plans, each plan as a Price on your live Stripe account. Nothing else is copied: buyers, customers, members, API keys and webhook endpoints are per side.

Live copies for the account you signed in to Test with, and only into a workspace where you are an owner or an admin. More than an hour after that sign-in, the Keys page asks you to confirm: select Confirm with Live, then Copy to Live again.

Copy again whenever Test has something new. Live is never copied back to Test.

3. Wire the store build

In your extension's folder:

npx -y toolaby@latest wire <tool-id> --live --force

The command writes the Live tool key (tk_live_…) into toolaby.config.js and replaces the Test addresses in the manifest with your workspace's Live address, in host_permissions and externally_connectable. Your own code is not touched.

A framework project takes the address from the key at build time; there is nothing to change in its config. See Frameworks.

4. Build and pack

Build as you always do: npm run build, or nothing for an extension without a build step. Then:

npx -y toolaby@latest pack

pack finds the built extension — this folder, .output/chrome-mv3, dist or build/chrome-mv3-prod — and writes <name>-<version>.zip. It leaves the manifest's key out of the zip, and it stops with the reason when the build:

Stops on	Why
a `tk_test_` or `tk_dev_` key inside	The extension would sell on Test, with test cards. Run step 3, build again.
`localhost` in the manifest	A store build must not reach a server on the buyer's machine.
the Wall's address missing from `host_permissions` or `externally_connectable`	Sign-in and the purchase could not reach the extension. Run step 3.
a file the manifest names that would be left out as private	Chrome would not load the zip. Take the private part out of that file, or pack with `--allow-private` if it is meant to ship.
a public folder that is a link into `.git`, or a build whose top is a git repository	The zip would carry the repository's history, index and logs. Point the build at its output folder.

See pack for the options.

5. Upload

In the Chrome Web Store Developer Dashboard:

A new item: select New item and upload the zip. Fill in the store listing. On the Privacy tab, declare what your extension collects; for the Wall's part, a signed-in buyer's email address (Personally identifiable information) and the sign-in credential kept on the device (Authentication information). Card details never reach the extension: payment happens on Stripe's page.
An update: open the item, then Package → Upload new package.

Submit for review. Review takes from a few hours to several days. While an item is in review, it takes no other package.

The store refuses a manifest key in a new item's first package, and in an update any key but the item's own. pack leaves it out for that reason. The store keeps the id it gave the item.

6. Tell the Wall where the store copy is

After the first upload the item has an id, and its listing has an address even before it is public. On Live, open the tool's Settings and paste the listing's address under Store → Chrome Web Store listing.

The Wall now accepts your tool key from the store copy. Your unpacked copy, loaded from your folder, keeps the key the wiring gave it and its own id; the Wall accepts that one too. From then on it refuses any other extension. See Test and Live.

To give every copy the store's id instead, copy the item's public key (Package → View public key, the text between the BEGIN and END lines, on one line) into your manifest's key, then run npx -y toolaby@latest wire <tool-id> --force on each side. The Wall adopts it as the extension's identity.

7. Check the store copy

When the item is published, install it from its listing.

Open the extension. Its tool's Keys page on Live shows it checked in.
Make a purchase with a real card. The extension unlocks, and the buyer appears on the tool's Customers page.
Refund it in your Stripe Dashboard. The licence is revoked, and the extension locks at its next check.

8. Ship an update

Raise version in the manifest. The store refuses a package whose version is not higher than the published one.
Build, and run npx -y toolaby@latest pack.
Upload it as a new package (step 5).

Your Test tool key stays in your working copy only while you develop: before you pack, the key must be Live (step 3). To go back to Test afterwards, run npx -y toolaby@latest wire <tool-id> --force.

To stop copies older than a version from running, set a minimum under the tool's Versions. See Versions.