Chrome extension for Bubble teams
Nobody ships to live on their own.
BuildGate holds Bubble's Deploy button until the change has a linked Linear issue and an approval from somebody else — then writes what happened into an append-only record your auditor can verify.
Segregation of duties, enforced three ways Evidence for SOC2 CC8.1 Runs inside the Bubble editor
The problem
Bubble has no deploy API and no deploy webhook.
The editor is the only place a deploy can be stopped or seen. That is why BuildGate is a browser extension — and why it does not stop there. A browser extension is, by nature, bypassable, so the control is built in three layers instead of one.
The Deploy button does not work yet
Clicks are 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 only for a request that names a Linear issue and carries an approval
from somebody else — enforced in the service, at the route, and as a database
CHECK constraint.
Unreachable means closed, not open
If the service cannot be reached, the gate fails closed. Break-glass is a code that works offline and records itself afterwards — an endpoint you must reach to authorise a bypass is useless in the outage that needs one.
Bypasses become findings, not silence
Bubble's own version history is reconciled against our records on a schedule.
A deploy that skipped the gate turns into a dated exception with a name —
unlogged_deploy, unapproved_deploy,
gate_not_enforcing — that somebody has to close.
How a deploy goes
Six steps, and the last one is the point.
The first five are the gate. The sixth is what makes it defensible: every release Bubble recorded is checked against every release BuildGate approved, and the difference is somebody's problem by name.
- Deploy clickedIntercepted in the editor, before Bubble acts on it.
- Request raisedLinear issue, approver, rollback plan, and the branch pair the release moves between.
- Someone else decidesA different person, signing in with Google. Self-approval is refused at three levels.
- Single-use tokenValid for 15 minutes, for that deploy of that app.
- Bubble deploysIts own dialog, description pre-filled with the request id.
- Reconciled laterMatched against Bubble's version history. No match, no silence.
Evidence
Append-only at the database level, not by convention.
The record cannot be quietly edited
The application role holds INSERT and SELECT and no
DELETE anywhere in the schema. Triggers reject UPDATE,
DELETE and TRUNCATE for every role, the table owner
included. Events are chained with SHA-256, and chain heads are anchored on a
schedule — because a hash chain alone cannot notice its own tail being cut off.
And you can hand it over
The console's Evidence screen re-verifies the chain on demand, reports when the head was last anchored, and downloads date-ranged CSV and JSON exports. Each organization has its own chain starting at seq 1, so one customer's evidence neither contains nor depends on another's.
Backups, sanitized before they leave
Each Bubble app is exported and committed to a GitHub repository you own — on a schedule and after every deploy. Secrets are stripped first, and a snapshot with a credential still in it is refused rather than uploaded.
Exceptions have owners
Findings that mean the control has stopped working are DM'd to owners and admins as they are raised, with a daily digest of whatever is still open. Closing one appends the note and the closer to the chain rather than clearing a row.
Integrations
Connected per organization. Credentials encrypted at rest.
Linear is the only one the gate depends on. With none of the others connected the control still works and the audit chain is still complete — a decision is never held up by an outbound call to somebody else's service failing.
Every deploy request names an issue, and the request is commented back onto it.
DMs the approver that a decision is waiting, and the requester once it lands.
Runs an automated code review of the same change a human just decided on.
Commits a sanitized backup of each Bubble app on a schedule and after every deploy.
Getting started
Set up in an afternoon, not a quarter.
The console is the extension's own page — there is no separate web app to sign into, because the people who need it already have the extension installed.
- Install the extensionThe console opens on first run. There is no separate web app to sign into.
- Sign in with GoogleWorkspace accounts carry more weight behind an approval; personal accounts can be refused deployment-wide.
- Create an organizationOr accept an invitation to one. Apps, roles, integrations and the audit chain are all scoped to it.
- Add a Bubble appPaste the editor URL. Apps start gated and fail-closed.
- Invite the teamGive somebody the approver role. Whoever raises a deploy can never approve it.
- Connect LinearSlack, BuildPrint and GitHub are optional — the control works without them.
For a team
Install from the Chrome Web Store and open the console from the toolbar. Anyone can start a pilot with a single app in observation mode, where deploys are recorded but nothing is blocked.
For a fleet
Force-install with Chrome Enterprise policy, which also stops users disabling it, and supply the backend URL through managed storage so nobody can repoint the extension at a service of their own.
Straight answers
The questions a security reviewer asks first.
- Can somebody just remove the extension?
- From their own browser, yes — that is true of every browser extension, and pretending otherwise would be the dishonest part. Two things answer it. Chrome Enterprise policy force-installs BuildGate and prevents users disabling it. And reconciliation reads Bubble's version history regardless of what any browser is running, so a deploy that dodged the gate arrives in the exceptions queue with a date on it.
- Why an extension and not an API integration?
- Bubble has no deploy API and no deploy webhook. The editor UI is the only place a deploy can be intercepted or observed. Everything about this product's shape follows from that one fact.
- Does an AI review replace the second person?
- Not unless you switch that on for an app, deliberately, and it is off by default. BuildPrint's review is a second opinion that arrives out of band; it cannot fail a deploy, and a review that errored is never treated as a review that passed.
- What does an auditor actually get?
- Per-organization, append-only evidence: a SHA-256 chain the console re-verifies on demand, chain heads anchored so a truncated tail is detectable, and date-ranged CSV and JSON exports. Role changes and app policy changes are appended to the same chain as the deploys, so "who made this person an approver" is evidence of the same quality as "who approved this deploy".
Put a second pair of eyes on every Bubble deploy.
Install it on one app, leave it in observation mode for a week, and look at what it recorded before you turn the gate on.