Change management and compliance for Bubble teams
GitHub for Bubble teams. Without the git.
Pull requests, required reviewers, branch rules and a history nobody can edit, for a team that works in the Bubble editor.
Nothing to learn, no git Approved by somebody else, always Evidence for SOC2 CC8.1
The idea
What a code team has on GitHub, for a team whose app is in Bubble.
| On GitHub | In Bubble | With BuildGate |
|---|---|---|
| Pull request | Press Deploy | A deploy request: issue, rollback plan, approver. |
| Required reviewers | Anyone with editor access | One to ten approvals. Never the requester. |
| The diff | Only inside a merge | Both versions compared, privacy-rule changes called out. |
| Checks | None | Issue checker, automated review, deploy windows. |
| Protected main | Anyone can merge | Merges into main need an approved request. |
| History | Who deployed, when | Who requested, approved and deployed. Append-only. |
| Insights | — | Ship rate, time to decide, who did what. |
How it works
From Deploy to a closed record, in eight steps.
- Deploy clicked Intercepted in the editor.
- Request opened Issue, approver, rollback plan.
- Branch held The editor shows what is waiting.
- Checks run Issue checker, review, diff.
- Somebody else approves Console, Slack, email or MCP.
- Deploy authorised Single-use token, fifteen minutes.
- Bubble deploys Its own dialog, request id pre-filled.
- Reconciled Every Bubble release matched to a request. No match, a finding.
Review
Review a deploy like a pull request.
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
- 10:52Approved by Priya N. · 1 of 2
- The whole changeVersions, issue, rollback plan, checks, timeline.
- The diff itselfPages, workflows, data types, API calls.
- Wherever the approver isConsole, Slack, email, the pull request, MCP.
Rulesets
Branch protection, for a Bubble app.
Which apps, which rules. Every change to a ruleset is on the record.
Production
Targets all apps, including ones added later
-
Required approvalsBefore a request counts as approved2
-
Review firstApprovers wait for the automated review
-
Clean issue checkBubble's issue checker must come back clean
-
Deploy windowMon–Thu 09:00–17:00 · freeze 20 Dec – 3 Jan
-
Gate merges into mainMerging into Development needs an approved request
-
Approve in GitA pull-request review counts as an approval
- One to ten approvalsNever the requester. No bypass for that one.
- Holds on a conditionReview first, a clean issue check, a deploy window.
- Gated mergesMerging into main needs an approved request too.
Why it holds
Bubble has no deploy API. The gate lives in the editor, and does not stop there.
The Deploy button is held
Until somebody other than the requester approves, under your rules.
Unreachable means closed
Break-glass works offline and records itself afterwards.
Unmanaged changes become findings
Bubble's own version history is checked against the record.
Compliance
The history is the evidence.
Every request, approval, deploy and role change on a SHA-256 chain, per organization. Built for SOC2 CC8.1. Evidence, not a certification.
The chain
Each event carries the hash of the one before it.
Insights
What Bubble says shipped, beside what was approved.
No DELETE grant. Triggers reject edits for every role.
Chain verified on demand. CSV and JSON by date.
Reads everything, writes nothing.
Apps and approved changes in your own tenant.
Your team
Roles, like a GitHub organization.
Everything.
Apps, members, rulesets. Approves.
Decides what others raised.
Raises requests.
Reads all, writes nothing.
Integrations
One issue tracker is required. The git part is optional.
Every request names an issue.
Or a task.
DMs the approver, then the requester.
A sanitized copy of each app, and the diff.
The same, as a merge request.
Review agent that reads the whole app.
Powers BuildGate's own reviewer.
Your compliance program.
A remote MCP server.
Getting started
An afternoon, not a quarter.
Set up in the console; the extension is only for the people who press Deploy. Start an app in observation mode and read a week of history before the button stops working.
- Open the consoleSign in with Google.
- Add a Bubble appPaste the editor URL.
- Invite an approverSomebody other than you.
- Connect Linear or ClickUpOAuth or an API key.
- Write a rulesetOr keep the default: one approval.
- Install the extensionChrome, for whoever deploys.
Straight answers
The four questions we get first.
Do we have to learn git?
No. Nobody commits, branches or merges anything. The work stays in the Bubble editor, and the request is a form that appears when somebody presses Deploy. Connect GitHub or GitLab and BuildGate keeps a copy of each app and opens the diff itself.
Can somebody just remove the extension?
From their own browser, yes. Chrome Enterprise policy can force-install it, and reconciliation reads Bubble's version history regardless, so a deploy that skipped approval becomes a dated finding.
Do approvers need to install anything?
No. They approve in the console, from Slack or email, from the pull request, or from their own MCP client.
What does an auditor get?
An append-only history per organization: a SHA-256 chain verified on demand, anchored heads, CSV and JSON exports, and a read-only role. Evidence, not a certification.
GitHub for Bubble teams. Without the git.
Add one app, watch it for a week, then turn approval on.