Change and deployment management for Bubble
Every Bubble deploy, managed as a change.
BuildGate turns pressing Deploy into a change request: a Linear issue, a rollback plan and an approval from somebody other than the requester. The approver sees what is actually changing, and what ships is written to a deployment record nobody can edit.
Change approval with segregation of duties, enforced three ways A complete change history for SOC2 CC8.1 Nothing to install until somebody deploys
Why three layers
Bubble has no deploy API. So change control lives in the editor — and does not stop there.
A browser extension is, by nature, bypassable. The process is built so that a change made around it is caught and recorded rather than pretended away.
The Deploy button is held
Until the change request names a Linear issue or ClickUp task and somebody other than the requester has approved it.
Unreachable means closed
If the service is down the gate fails closed. Emergency changes go through break-glass, which works offline and records itself after.
Unmanaged changes become findings
Bubble's own version history is checked against the change record. A deploy that skipped the process becomes a dated exception.
The change lifecycle
Eight steps from Deploy to a closed change record. The last one is the point.
The first seven manage the change. The eighth checks every release Bubble recorded against every change BuildGate approved, and hands the difference to somebody by name.
- Deploy clicked Intercepted in the editor, before Bubble acts on it.
- Change request raised Linear issue, approver, rollback plan, the two versions.
- Branch held Everyone opening it in the editor sees what is waiting.
- Somebody else approves Console, Slack, email, pull request or MCP. Never the requester.
- A review arrives A second opinion on the same change. It cannot fail a deploy.
- Deployment authorised A single-use token. Fifteen minutes, this change, this app.
- Bubble deploys Its own dialog, the change request id pre-filled.
- Reconciled later Every release Bubble recorded is matched to an approved change. No match, no silence.
Change approval
Ask somebody to authorise the change, and show them the change.
Deploy acme-orders · Development → Live
Raised by Sam K. · rollback: redeploy v41 · window closes in 19h
- 10:41Raised by Sam K.
- 10:41Branch Development held
- 10:46Review completed
- Laid out like a pull requestThe two versions, the issue, the rollback plan, a timeline, the review, and a place to decide with a note for the record.
- The diff itself, not a sentence about itWith Git connected, both versions are exported and compared. Pages, workflows, data types and API calls, with privacy-rule changes called out.
- Wherever the approver already isConsole, Slack, email, the pull request, the held branch in the editor, or their own MCP client. The requester sees why they cannot approve their own change.
Automated review
Two review agents. They differ in what they can see.
Either way the review is a second opinion on the change. It cannot fail a deployment, and by default it cannot approve one either.
BuildPrint
Signs into Bubble, diffs the two versions itself and reviews the change for defects.
BuildGate's own reviewer
Reads only the structural comparison and says whether the scope matches the story. It cannot see an expression, so it cannot find a bug — and the console never draws a green badge on a review that could not see the whole change.
The change history
Append-only at the database, not by convention.
Every change request, approval, deployment, comment, exception and role change is appended to a SHA-256 chain, and the chain head is anchored on a schedule — because a chain alone cannot notice its own tail being cut off.
The chain
Each event carries the hash of the one before it.
Insights
What Bubble says shipped, beside what went through change approval.
No DELETE grant anywhere. Triggers reject edits for every role, the owner included.
Chain re-verified on demand. Date-ranged CSV and JSON of the change history, one chain per organization.
Each Bubble app mirrored to GitHub or GitLab, sanitized in the browser. The diff is what changed.
Unmanaged changes are DM’d as they are found, with a daily digest of what is still open.
Apps and approved changes pushed into your own tenant as resources its tests already run against.
Every event signed and numbered. A receiver that sees 41 then 43 knows it missed one.
Integrations
An issue tracker is the only one the process depends on.
Connected per organization, credentials encrypted at rest. A change is never held up by somebody else's service failing.
Every change request names an issue and is commented back onto it.
The same with tasks, for a team that tracks its work in ClickUp — in place of Linear, or beside it.
DMs the approver, then the requester. Channels if you want them.
The sanitized mirror, and the comparison pull request.
The same, as a project and a merge request.
Review agent that signs into Bubble and reads the whole app.
The key BuildGate's own reviewer calls a model with.
Your apps and approved changes in your compliance program.
A remote MCP server. Add it by URL, sign in with Google.
Getting started
An afternoon, not a quarter.
The whole process is set up in the hosted console. The extension comes last, and only for the people who press Deploy.
- Open the consoleSign in with Google. Create an organization, or accept an invitation.
- Add a Bubble appPaste the editor URL. Apps start under change control; switch one to observation for a pilot.
- Invite the teamGive somebody other than yourself the role that approves changes.
- Connect Linear or ClickUpOAuth or an API key. The one integration a change request cannot be raised without.
- Turn on notificationsSlack and email. A change request nobody sees is the failure to fear.
- Install the extensionChrome, for the people who press Deploy. Approvers need nothing.
For a team
Install from the Chrome Web Store. Start an app in observation mode, where every deployment is recorded and nothing is blocked, and read a week of change history before the button stops working.
For a fleet
Force-install with Chrome Enterprise policy, which also stops users disabling it, and pin the backend URL through managed storage.
Straight answers
What an auditor and a security reviewer ask first.
Can somebody just remove the extension?
From their own browser, yes — that is true of every extension, and saying otherwise would be the dishonest part. Chrome Enterprise policy can force-install it. And reconciliation reads Bubble's version history regardless of what any browser is running, so a deploy that skipped change approval lands 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 is the only place a deploy can be intercepted or observed, and everything about this product's shape follows from that.
Do approvers need to install anything?
No. Approving happens in the hosted console, from a Slack DM or email, from the comparison pull request, or from the approver's own MCP client. The extension is for the people who press Deploy.
Does an AI review replace the second approver?
Not unless you switch that on for an app, deliberately. It is off by default and it is the one setting here that removes the second person from change approval. With it on, a run counts as clean only if it completed, saw the whole change, and left nothing open above a low-priority comment. Could not look never reads as looked, and it was fine.
Does this replace our change process, or feed it?
Feeds it. Every deploy request is a change record with the fields a change process asks for — the ticket, the requester, the approver, the rollback plan, the two versions and the outcome — and every event on it is commented back onto the Linear issue and delivered by signed webhook, so the tracker you already run receives the change rather than a summary of it.
What does an auditor actually get?
Per-organization, append-only change history: 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 are on the same chain as deployments. None of it is a certification; it is evidence that a change management control existed and operated.
Every Bubble deploy, managed as a change.
Create an organization, add one app, leave it in observation mode for a week, and read the change history it recorded before you turn approval on.