Hi,
In Bubble, anyone who can open the editor can push to live. There is no review step, and afterwards the version history tells you a version shipped — not who agreed it should.
So we built BuildGate. An app cannot go to live until that deploy has a linked issue and an approval from someone other than the person deploying, and every production change lands in an evident log you can hand an auditor.
-
You press Deploy and get asked what this is.
Linear issue, approver, what is changing, how it gets undone.
-
The branch is held while a deploy of it is undecided.
Otherwise what ships need not be what was reviewed. Anyone opening that branch
sees the queue and can decide in place. You can dismiss it and keep working —
dismissing approves nothing.
-
The console holds the record.
Everything waiting, every decision ever made, exportable to CSV. Note the second
row: “You raised this, so you cannot decide it.” No exceptions, whatever your
role — but any other approver can clear it, so the queue never stalls on one
absent person.
-
Each request opens as a page, laid out like a pull request.
Its own URL, and the timeline on it is the audit chain filtered to one request:
what you read and what an auditor exports are the same uneditable events.
An agent reviews it too. Add your BuildPrint agent so it can review changes and provide feedback. BuildGate’s own reviewer sees only a structural comparison — which pages, workflows and data types changed — and checks it against what the change claims to do; it can never find a bug and never claims to. Neither can reject a deploy, and anything auto-approved is badged Automated permanently.
Git sync. Connect GitHub or GitLab and each app is mirrored as a sanitized
snapshot.
Linear is the only integration the gate depends on; Slack, email, Vanta and MCP
approvals are extras the control works without.
Being beta so bug reports very welcome.
Announcing BuildGate MCP: A New Way to Work
We’ve added a new way to interact with your deploy queues. BuildGate is now also a remote Model Context Protocol (MCP) server. The console isn’t going anywhere—MCP is just another interface that lets you connect your favorite AI assistants or custom terminal workflows directly to BuildGate.
Key Capabilities:
-
A Second Interface: Do everything you normally would in the console—like read pending approvals, draft requests, decide deploys, and resolve exceptions—straight from your IDE or chat interface.
-
Direct Connection: Just point your MCP-compliant client to your deployment’s endpoint (/mcp).
-
Secure Auth: Agents authenticate via the same Google Sign-In you use for the console. Every action is verified against your active role in real time.
-
Granular Control: Five strict, dedicated scopes ensure your agents only have the exact access they need to read or modify your queue.
Check out the BuildGate MCP Documentation to grab your server URL and get started.
You can now make a Bubble app’s deploy history public in BuildGate. The app gets a read-only page anyone can open without signing in, laid out like a public GitHub repo:
- Overview: branches (main → live), recent deploys, contributors, and a “How this app ships” summary generated from your real gate settings.
- Deploys: every release to live, by day, with who raised it and who approved it.
- Approvals: open and closed deploy requests.
Handy for sending a client one link that shows every release to their app, or showing an auditor how changes reach production.
What stays private: every app starts private, and a public page shows only summaries, issue keys, dates and names. Change descriptions, rollback plans, notes, reviews, diffs and email addresses are never published. Switch the app back to private and the page goes down immediately.
To turn it on: open the app in Settings → Apps, click Make public, and type the app id to confirm.
Feedback welcome, especially on what should or shouldn’t be on a page like this.
