For administrators
Integrations and notifications
Linear is the only one the gate depends on. The rest add to the record: Slack and email for notifications, GitHub or GitLab for backups and diffs, a review agent, webhooks, Vanta.
What can be connected
All of it is per organization, from Settings → Integrations, with credentials encrypted at rest.
| Provider | What it does | How it connects |
|---|---|---|
| Linear | Every deploy request names an issue, and the request is commented back onto it | OAuth, or a pasted API key |
| Slack | DMs the approver that a decision is waiting, and the requester once it lands. Optionally announces the same notices in channels you pick | OAuth, or a pasted bot token |
| GitHub | A sanitized backup of each app, comparison pull requests, and optionally approving the deploy by approving that pull request | GitHub App install, or a personal access token |
| GitLab | The same on GitLab: the mirror is a project, the comparison a merge request | An access token with the api scope |
| BuildPrint | One of the two review agents. Signs into Bubble, diffs the two versions itself, and reviews the change | API key |
| OpenRouter | Holds the key the AI features call a model with, including BuildGate's own review agent. Billed to your own OpenRouter account | API key |
| Vanta | Pushes your apps and their approved deploys into your own Vanta tenant, hourly, as resources your existing change-management tests can run against | A client id and secret from a private integration in your Vanta console |
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.
Notifications
Two channels, and every notification goes out on each one you have turned on. Slack and email are not alternatives: they fail differently, and the failure this product is worst at is an approval nobody sees. A Slack DM never reaches an approver who is not in the workspace, or whose Slack account carries a different address from their Google one — which is exactly the case where a deploy sits waiting and everybody assumes the approver was told.
What goes out, on both:
- a deploy request waiting on its approver, with the issue, the change, the rollback plan and a link;
- the decision, back to whoever raised it — including, in as many words, when nobody decided it and an automated review did;
- an invitation to join the organization;
- exceptions that mean the control has stopped working, and the daily digest of whatever is still open.
Three things have to agree before anything is sent — the deployment allows the channel, you have asked for it, and there is something behind it. Settings → Notifications names whichever one is missing rather than showing a switch that is on and sending nothing.
Announcing in Slack channels
The same screen takes up to ten channels for those notices to be announced in as well as direct-messaged. It is additive — a DM is how one person finds out they are being waited on, a channel is where the team watches the gate work — and it is empty by default for every organization, because a deploy request names a change that has not shipped and everybody in a channel can read it.
An invitation is never announced: it carries a link that grants membership to whoever opens it first, so it is delivered to an address or not at all. A rejection note is never announced either — it is feedback written for one person. A private channel needs BuildGate invited to it; there is no scope that substitutes for membership, which is what keeps a private channel private.
Backups, diffs, and approving from a pull request
Bubble keeps the only copy of your application: no export API, no git history, and below the top plans no backup product. Connect GitHub or GitLab and a sanitized copy of each app is committed to a private repository you own — on a schedule, after every deploy, and on every savepoint.
Showing approvers what changed
Bubble publishes no diff. Switch on Show approvers what a deploy changes under Settings → Git and both branches are exported, sanitized and compared, which produces a pull request holding the full diff and a readable summary on the approval screen.
It is off by default and it is the one setting that spends somebody's editor session on demand — two application exports per deploy request. Neither the diff nor the summary can block, delay or fail a deploy: a missing comparison shows as absent rather than as "nothing changed", which is a different claim.
Approving in Git
With Approve in Git switched on for an app, approving its comparison pull request approves the deploy. This is the only place where something outside BuildGate decides a deploy, so know what it means: for that app, review access to the backup repository becomes part of the approval surface.
It is not a weaker door. You link your own GitHub or GitLab account yourself, signed in to both — nobody can link one for you, and it is keyed on the host's numeric user id rather than a handle that can be renamed. The approval is recorded against the BuildGate user it points at and runs through the same code the console does: same role check, same expiry, same rule that you cannot approve your own. Requesting changes is not a rejection, because rejecting cannot be undone and is left to a person to do deliberately.
The two review agents
An app is set to one of them. They differ in the only way that matters for a review: what they can see.
| BuildPrint | BuildGate | |
|---|---|---|
| What it reads | The application. It signs into Bubble and diffs the two versions itself | The structural comparison BuildGate already produces — which pages, workflows, data types and API calls differ, and how many |
| What it can find | Defects, in the change | Scope. Whether the areas that changed match what the change is said to do |
| What it cannot | — | See a single value, expression, workflow step, condition or privacy rule. It cannot find a bug |
| What it costs | BuildPrint credits | Inference on your own OpenRouter key |
BuildGate's reviewer is the honest option, not the better one. A change described as "fix the label on the checkout button" that touches fourteen pages, two data types and an API Connector call is worth saying out loud, and that is a scope check — not a defect review. The product is built so the two cannot be confused: every review records what it could see, and one that could not see the whole change is never drawn as clean.
Practical consequence: an app set to BuildGate with automated approval on and no comparison configured will never auto-approve anything. That is the safe direction, and the Apps screen names the switch that is off rather than letting you find out by waiting.
Approving from your own tooling
Approvers are not always in a browser. BuildGate is also a remote MCP server, so an assistant or a terminal can list what is waiting on you, read the change and decide it. Add the server by URL, sign in with Google, pick the organization, see the scopes and allow — there is no key to paste and no client to pre-register.
The console carries the URL to copy, the protocol revision it serves and the scopes a client can ask for, on a card at the bottom of Integrations.
Why this is not the Slack button this product refuses to build. A Slack button press authenticates as whoever controls a Slack account. This token exists only because you completed the same Google sign-in the console uses, and it is checked against your live membership on every call — so removing somebody's approver rights stops their agent on the next request, not at the next expiry. Scope is a ceiling and never a grant: holding the decide scope does not make anyone an approver.
Everything else is unchanged. You cannot approve a deploy you raised, there is no tool that raises a deploy or releases a deploy token, and resolving an exception deletes nothing. What the record gains is a distinction it keeps: a decision made this way is marked as having come through an agent, with the client's name beside it, because a person deciding through an agent and a person deciding at a keyboard are not the same act.
Webhooks
Notifications tell a person that something needs them; webhooks tell a system that something happened. An organization can register endpoints of its own and receive its events — signed, retried, and never sent to an address on your internal network.
Every delivery is signed, so a receiver can check that it came from BuildGate. Deliveries retry and can arrive out of order, so a receiver has to tolerate seeing the same event twice and an older one after a newer one.