BuildGate documentation

What BuildGate does

Two things, and they are worth keeping apart in your head because they fail differently.

It gates. Inside the Bubble editor, the Deploy button stops working until the change has been written down and somebody else has said yes to it. The person who raised the deploy can never be the person who approves it — not as a convention, but as a rule enforced in the service, at every route that could decide a request, and by a constraint in the database.

It records. Every deploy, approval, rejection, comment, exception and administrative change is appended to a hash chain that nobody — including us — can edit or delete. That is what you export when an auditor asks how production changes are controlled.

Why a browser extension, and what that costs

Bubble has no deploy API and no deploy webhook. The editor is the only place a deploy can be intercepted or even observed, so the gate has to run in the browser — and a browser extension can be disabled by whoever installed it.

Rather than pretend otherwise, the control is built in three layers:

• Preventive. The Deploy button is intercepted before Bubble's own handler, and the deploy endpoint is blocked in the browser's network stack where page JavaScript cannot undo it. It opens for an approved request and nothing else.
• Corrective. If BuildGate cannot be reached, the gate fails closed. Break-glass is a code that works offline and files its own report afterwards — an endpoint you must reach in order to authorise a bypass is useless in the outage that needs one.
• Detective. Bubble's own version history is reconciled against BuildGate's records on a schedule. A deploy that skipped the gate becomes a dated finding with a name, sitting in a queue somebody has to close.

The third layer is the one that makes this defensible. Prevention that can be turned off is worth something; prevention that reports being turned off is worth considerably more. It is also why the honest answer to "can somebody go around it" is yes, and why the next sentence is "and you will have a dated record saying who."

Find your way

• Setting BuildGate up for your team. Start at Setting up your organization — an organization, an app, the people, Linear, and the extension.
• You deploy, and the button has stopped working. Requesting a deploy covers what the form is asking for and what happens after you fill it in.
• Somebody is waiting on you. Approving a deploy covers where requests reach you, what to look at, and why you cannot approve your own.
• You own the evidence. The exception queue and Evidence and audit are the two screens that make the record worth having.

What you need before you start

• A Google account for everyone who will use BuildGate. Sign-in is Google only. A Google Workspace account carries more weight than a personal one — an approval is a claim about who a person is, and a Workspace account is a claim their employer stands behind.
• Chrome, for anyone who deploys. The gate is a Chrome extension. Approving needs no install at all — a browser and the link is enough.
• Linear. Every deploy request names an issue, so this is the one integration the gate depends on. Everything else is optional.
• At least two people. One person cannot operate this control. The rule that a requester may not approve their own deploy has no override, and an organization of one is an organization where nothing can ever be approved.