Integrations and notifications

What can be connected

All of it is per organization, from Settings → Integrations, with credentials encrypted at rest.

A tracker — Linear or ClickUp — 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.

Alerts

Settings → Alerts is where an administrator chooses what else the organization is told about. An alert is a rule with three parts: which events — any event in the audit chain, such as an auto-approved deploy, a rejected request or a break-glass code; which apps, or every app including ones added later; and who hears — everyone with a role, named people, and Slack channels of the rule's own.

Alerts go out on the channels switched on under Notifications, usually within a minute. Several matching events arrive as one message rather than one each, and each line says what happened, on which app, with a link that asks the reader to sign in. A comment's text, a rejection note and an exception's detail are never included. Send test sends the message once to everybody the rule reaches and says why if nothing went out.

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.

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.

With Bubble connected, BuildGate's reviewer reads the app as well. It is given a short list of Bubble's MCP tools that can only read — never one that changes an app, reads its data or mints access — and opens what the change touches, in the version being deployed and the live one. Every call is pinned to the request's app and those two versions. A review is limited in turns and in how much it may read; one that reaches a limit is recorded as cut short and is never clean, and neither is one that opened nothing. Connect it under Integrations with an account kept for reviews, added to your apps with the narrowest permissions Bubble allows: every review reads as that account.

The same connection reads your plugins. About once a day, BuildGate asks Bubble which plugins each app has installed, in live and in the branch deploys are cut from, and which version of each the marketplace has now. An app's Plugins screen lists them, with what is behind first and whether the step is a major, minor or patch update. It only reads: an upgrade is made in the editor's Plugins tab on a branch, and reaches live through a deploy like any other change. Built-in plugins have no version to be behind, and plugin code is not read, so a version is judged by its number alone. A reading that fails says why on the same screen, and keeps the list from the last one that worked.

Advisories. Bubble publishes nothing about unsafe plugin versions, so an owner or administrator can record one from the Plugins screen: the plugin, how severe, what is wrong, where you found out and, if there is one, the version that fixed it. It flags the plugin in every app that has a version below the fix — every version, if there is no fix — and an installed version that cannot be compared is flagged as one that may be affected, never passed over. A wrong advisory is withdrawn with a note rather than edited, and recording and withdrawing one are both in the audit log, so an alert rule or a webhook can follow them.

Dependencies. Where an editor running the extension can see a plugin's code — an open-source plugin, or your own — the extension reads what its server-side actions depend on and shows it under the plugin's name: the packages, the Node version they run on, and two warnings, a Node version past its end of life and packages pinned to latest or another source that is not a version. Only the package list leaves your browser, never the code. A plugin whose code is hidden says so, rather than reading as having no dependencies.

Known vulnerabilities. Each of those packages is checked once a day against OSV, the public database of security advisories for npm packages. A vulnerability badge means the version npm would install for the plugin's range today is affected, so the plugin's author has to change the range; hover it for the advisory and the version that fixes it. A possible badge means the range also allows an affected older version, so it depends on when Bubble built the plugin. A package that has not been checked yet, or could not be (a git source, say), is never shown as clean.

Being told. When a plugin newly has an open advisory, or a dependency newly has a vulnerability in the version that would be installed today, BuildGate records it as plugin_advisory_applies or plugin_vulnerability_found, once per app. To hear about it, add an alert under Settings → Alerts with either event; the message links to the app's Plugins screen. A possible vulnerability is shown but not announced.

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.

Working from your own tooling

BuildGate is also a remote MCP server, so an approver's own tooling — an assistant, a terminal — can list what is waiting on them, read the change and decide it, and a deployer's can raise a request and follow it to a decision. The same surface carries the exception queue, so the review this product asks for on a cadence can happen where the reviewer already is.

It sits with the integrations without being one: nothing is connected per organization, and everybody authorizes their own client with the Google sign-in they already use. The card at the bottom of Settings → Integrations carries this deployment's server URL, the protocol revision it serves and the scopes a client can ask for.

Working from an MCP client is the page for it: connecting one, what each scope allows, every tool, and what none of them can do.

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.

Datadog

A webhook can send its events to Datadog as Datadog events, so an unapproved deploy shows up in the same event stream as everything else you monitor, and a monitor can page somebody about it. Under Settings → Webhooks, add a webhook, choose Datadog events, pick your Datadog site and paste a Datadog API key. Then press Send a test: a test event appears in Datadog's Event Explorer if the site and key are right.

By default it sends compliance exceptions — when one is raised, when it happens again, and when somebody resolves it. A break-glass bypass is already an exception, so there is no need to tick bypass_used as well; that would send each bypass twice.

Each event carries:

• A severity. The findings BuildGate itself treats as urgent — an unlogged or unapproved deploy, a bypass, the gate not enforcing, a shipped change that differs from what was approved — arrive as error; other findings as warning; a resolution as success.
• Tags you can search and alert on: buildgate_app (the app's Bubble id), buildgate_exception (the kind of finding, such as buildgate_exception:unlogged_deploy), buildgate_event (the event type) and buildgate_organization (your organization's slug).
• A link back to the finding in BuildGate, and the audit chain event number it describes.

For example, an event monitor on tags:buildgate_exception:(unlogged_deploy OR unapproved_deploy OR bypass_used OR gate_not_enforcing) pages for every deploy that went around the gate.