Setting up your organization

Create an organization, add a Bubble app, invite the people who deploy it, connect Linear and install the extension. About fifteen minutes, and you can run it in observation mode first.

The setup, in order

All of this happens in the console at buildgate.dev/console. Nothing needs to be installed to set anything up — the extension comes last, and only for the people who actually deploy.

Sign in with Google and create an organization.
Everything in BuildGate is scoped to an organization: its apps, its people, its integrations and its own audit chain. If a colleague has already created one, take their invitation instead of creating a second.
Add your Bubble app.
Paste the app's editor URL on the Apps screen. A Bubble app belongs to exactly one organization, and a deploy of an app nobody has added is refused with a prompt to add it rather than quietly allowed.

While you are there, set the pair of Bubble versions releases move between — main → live on a plan with named branches, test → live on Bubble's default. This is not decoration: the pair is copied onto each request when it is raised, and it is what the automated review compares. An app pointed at the wrong two branches gets reviews of a change nobody made.
Invite the team, and give somebody an approving role.
Invite by email address; only the Google account matching that address can accept, so a forwarded link transfers nothing. Give at least one person other than yourself approver, admin or owner — see roles.
Connect Linear.
Settings → Integrations, by OAuth or a pasted API key. Every deploy request names an issue and is commented back onto it, so this is the one integration the gate will not run without.
Turn on notifications.
Settings → Notifications. Slack and email are not alternatives — turn on both if you can. The failure this product is worst at is an approval nobody sees, and a Slack DM never reaches an approver whose Slack address differs from their Google one.
Install the extension on the machines that deploy.
Chrome, one install per person. For a fleet, force-install it with Chrome Enterprise policy — that also stops people disabling it, and supplies the backend URL through managed storage so nobody can repoint the extension at a service of their own.

Run a pilot before you turn the gate on

Gating is per app, and every app starts gated and fail-closed. The Apps screen switches one to observation only, which is the setting to use for a pilot: deploys are watched and recorded, and nothing is blocked.

Leave a real app in observation for a week and read what it recorded before you switch the gate on. You will find out what your team's deploy rhythm actually is, and whoever has to approve the change will find out what they are agreeing to — both of which are cheaper to learn before the button stops working.

Observation is not a control. An app in observation mode blocks nothing, so a deploy that nobody approved is recorded and allowed. It is a pilot setting and a migration setting, not somewhere to leave an app you are claiming is governed.

How people join afterwards

Two ways in, and both are decisions the organization made:

An invitation to a named email address. The console shows the link once, and a Slack DM and an email are attempted as a convenience on whatever channels you have configured. The link the console shows you is the delivery this platform promises — if the DM does not arrive, send the link yourself.
A verified Workspace domain. An organization created from a Google Workspace account can claim its domain and opt into auto-join, and colleagues on that domain then join as deployer the first time they sign in. Approver rights are never granted this way, and somebody who was removed does not walk back in.