Privacy Policy
BuildGate sits between your team and a production deploy, so it necessarily knows who did what. This page says exactly what that means: what the extension can see, what the service stores, who else receives it, how long it lasts, and the one thing we deliberately cannot delete.
1. Who we are
BuildGate is operated by Inova Studio LLC ("Inova Studio", "we", "us"), a limited liability company organised in the State of Oregon, United States. Our company website is inova.us and you can reach us at [email protected].
This policy covers the buildgate.dev website, the BuildGate Chrome extension, and the BuildGate service the extension talks to (together, the "Service").
We handle personal data in two different roles, and the difference matters:
- As a controller, for the data that makes an account work — your name, your email address, which organizations you belong to and with what role. We decide what is needed for that and this policy is our account of it.
- As a processor, for the records an organization creates while using BuildGate — deploy requests, approvals, exceptions, backups. Your employer (the "Customer") decides what goes in them and why; we process them on the Customer's instructions under our Terms of Use.
If you use BuildGate because your employer installed it and you want a record corrected or removed, start with an owner or admin of your organization. For most of what BuildGate holds we can only act on the Customer's instruction — and, as section 8 explains, some of it is deliberately not editable by anyone.
2. What the browser extension can see
The extension is the part of BuildGate that runs on your machine, so it is worth being exact about what it touches.
- It runs on the Bubble editor. Its content script is limited to Bubble editor pages. It reads that page to find the Deploy button, identify which application you are in, and read the version history Bubble already displays. It does not read your other tabs, your browsing history, or any page outside the Bubble editor.
- It blocks one network request. Bubble's deploy call is held in the browser's network stack until an approval token exists for it. Nothing else is intercepted.
- Backups use your own Bubble session. When your organization turns backups on, the extension asks Bubble's own editor export endpoint for a copy of the application, using the session cookie already in your browser. It reads exactly what you could read by clicking through the editor yourself. BuildGate has no Bubble account, no Bubble API key, and no way to reach your apps when you are not signed in to Bubble.
-
Sign-in is Google, with the narrowest scopes. The extension uses
Chrome's identity flow to request
openid email profileand nothing else. Your Google password is never seen by the extension or by us, and we do not request access to Gmail, Drive, Calendar, or your contacts. -
Your session stays in memory. The sign-in token is kept in
chrome.storage.session, which is memory-backed and cleared when the browser closes. It is a short-lived signed token; we do not store a copy of it on our servers.
We do not sell the data the extension handles, do not transfer it to third parties except as described in section 6, do not use it for advertising or to build a profile of you, and do not use it to train machine-learning models.
3. What we collect
| Category | What it contains | Where it comes from |
|---|---|---|
| Account | Email address, display name, your Google account identifier, the Google Workspace domain your account belongs to (if any), when the account was created, and when it was last seen. Your Slack user id, if your organization connects Slack and matches you to it. | Google Sign-In; Slack, if connected |
| Organization | Organization name and identifier, who belongs to it, each member's role, who invited whom, and the email addresses invitations were sent to. | Entered by your organization's admins |
| Deploy records | Who requested a deploy, which Bubble application and versions it moves between, the linked Linear issue, the description and rollback plan, who approved or rejected it, any note they wrote, the timestamps, and the outcome. Break-glass bypasses and the reason given for one are recorded the same way. | Entered by your team in the extension |
| Observed deploys | Version numbers, deploy descriptions and timestamps read from Bubble's own version history, and the Bubble account each release is attributed to. This is how a deploy that skipped the gate is detected. | Read from Bubble by the extension |
| Compliance exceptions | Findings raised when the control did not hold, who they were assigned to, and the note written when one is closed. | Generated by the Service; closed by your team |
| Application backups | A copy of the Bubble application's definition — pages, workflows, data types, option sets, plugin configuration, API Connector calls — with credential-shaped values stripped out before it leaves your browser and again on our side. The copy is committed to a Git repository your organization owns. We keep only a hash of it, its size, how many values were redacted, and the commit it landed in. | Exported from Bubble by the extension, when backups are enabled |
| Integration credentials | Access tokens for the services your organization connects (Linear, Slack, GitHub, BuildPrint), plus the account or workspace name they belong to. Tokens are encrypted at rest with AES-256-GCM and are never shown back to you or to us after they are stored. | Granted by an admin of your organization |
| Website and server logs | Ordinary request metadata — IP address, user agent, path, timestamp — kept by our hosting provider for security, abuse prevention and debugging. BuildGate's own database does not store IP addresses. | Automatically, when you use the Service |
| Aggregate usage counts |
Which page was viewed, and which of a short list of actions happened on it —
a deploy request decided, an integration connected, an evidence export
downloaded. Counts only: no cookie, no identifier for you or your device,
nothing that can be traced back to a person or a session, and never the
content of a deploy request, an exception or an app. Record ids are stripped
before the page is reported, so a screen reads as
/console/approvals/:id rather than naming one.
|
Automatically, on buildgate.dev and in the console |
The buildgate.dev pages you are reading, and the console, carry one measurement script: Plausible, which counts pages and the handful of actions listed above. It sets no cookie, stores no identifier for you or your device, builds no profile, follows you to no other site, and retains no personal data — so there is nothing here to consent to and nothing to opt out of. It is hosted in the European Union. There are no tracking pixels, no advertising tags and no other third-party scripts.
Two things deliberately carry no measurement at all. The first is the Chrome extension: nothing it does inside the Bubble editor is counted, reported or sent anywhere but to this service. The second is the pages reached by a link from an email or a Slack message — an approval, an invitation, an authorization consent screen. Their address is a single-use credential, and a script that reports the address it is on would be handing that credential to somebody else.
4. What we do not collect
- Your application's own data. BuildGate never connects to your Bubble app's live database. It captures the application's definition — how it is built — not the records your users have created in it. Anything your team typed into the app's design, such as static content or option-set values, is part of that definition and will be in a backup.
- Bubble credentials. We never ask for, receive or store your Bubble username, password, or API keys.
- Payment details. Where a plan is paid for, card details go to a payment processor and are never held by us.
- Special-category data. BuildGate has no field that asks for health, biometric, racial, religious, political or similar data, and no feature that would use it.
- Cross-site tracking. No advertising identifiers, no data brokers, and no sale or sharing of personal information as those terms are defined under California law. The analytics described above are cookieless and per-visit: they cannot follow you here from another site, or from here to one.
5. Why we use it, and on what legal basis
| Purpose | Legal basis (UK/EU GDPR) |
|---|---|
| Authenticating you and deciding what you are allowed to do | Performance of a contract |
| Running the approval control: recording who requested and who decided, and refusing self-approval | Performance of a contract; the Customer's legitimate interest in a working change-management control |
| Keeping an append-only audit record and reconciling it against Bubble's version history | Legitimate interests (evidence of internal control, fraud and misuse detection); for some Customers, a legal or regulatory obligation |
| Notifying approvers and requesters over Slack, or commenting on a Linear issue | Performance of a contract; consent given by connecting the integration |
| Backing an application up to a repository your organization owns | Consent given by enabling backups; the Customer's legitimate interests |
| Security, abuse prevention, and keeping the Service up | Legitimate interests |
| Replying to you when you contact support | Legitimate interests; performance of a contract |
We do not make decisions about you by automated means that produce legal or similarly significant effects. An automated code review, where enabled, is advisory: it cannot approve or fail a deploy on its own.
7. Where your data is processed
BuildGate is operated from the United States and your data is processed there. If you are in the United Kingdom, the European Economic Area or Switzerland, this means your personal data is transferred outside your home jurisdiction. Where such a transfer needs a safeguard, we rely on the European Commission's Standard Contractual Clauses (and the UK Addendum, where applicable). Write to [email protected] if you would like a copy of the terms we use.
8. How long we keep it — and what we cannot delete
BuildGate's audit record is append-only by construction. Events are
chained with SHA-256, the application's database role holds no DELETE
permission anywhere in the schema, and database triggers reject
UPDATE, DELETE and TRUNCATE for every role,
the table owner included. That is the entire point of the product: a record that
could be quietly amended afterwards is not evidence of anything.
The honest consequence is that individual entries in that record cannot be edited or erased — not by your admins, and not by us. Corrections are made by appending, so the original and the correction are both visible. What we can do is delete an organization's data in full, which we do at the infrastructure level.
| Data | Kept for |
|---|---|
| Audit chain: deploy requests, decisions, role and policy changes, exceptions | The life of the organization's account, then 30 days after it closes, unless a longer period is required by law or agreed with the Customer |
| Account and membership records | While the account exists; a membership that ends is marked as ended rather than deleted, because "who could approve, and when" is part of the evidence |
| Backup metadata (hash, size, commit reference) | With the audit chain. The backup contents live in your own repository and are yours to delete |
| Integration tokens | Until the integration is disconnected or the account closes, then deleted |
| Sign-in sessions and deploy tokens | Sessions expire within hours; a deploy token is single-use and expires 15 minutes after it is issued |
| Hosting and request logs | As kept by our hosting provider, typically weeks rather than months |
When a Customer closes its account, the organization's records — including its audit chain — are deleted after the 30-day window, along with any encrypted credentials. Ask us at [email protected] if you need that done sooner, or need it confirmed in writing once it is done.
9. How it is protected
- Everything is served over TLS; the extension refuses a backend that is not HTTPS.
- Integration credentials are encrypted at rest with AES-256-GCM.
- Invitation tokens and deploy tokens are stored as SHA-256 hashes. The original value exists only in the link or in the browser that received it, so a copy of the database does not yield a usable token.
-
The application's database role is least-privilege:
INSERTandSELECT, noDELETE. - Each organization is a separate tenant with its own audit chain starting at sequence 1, so one customer's evidence neither contains nor depends on another's.
- Chain heads are anchored on a schedule, so a record with its tail cut off is detectable rather than merely unlikely.
- Fleet deployments can force-install the extension and pin its backend through Chrome Enterprise managed storage, so it cannot be repointed at somebody else's server.
No system is perfectly secure. If you believe you have found a vulnerability, please write to [email protected] before disclosing it publicly; we will acknowledge you and work the issue with you. If a breach affects your personal data we will notify the Customer without undue delay, and affected individuals and regulators where the law requires it.
10. Your rights
Depending on where you live, you may have the right to access the personal data we hold about you, to have it corrected, to have it deleted, to receive a portable copy, to object to or restrict certain processing, and to withdraw consent you previously gave. Exercising these rights will never get you worse service.
To make a request, write to [email protected]. We will respond within 30 days, or tell you why we need longer. We may need to verify your identity first, and where we act as a processor we will pass the request to the Customer and help them answer it. Section 8 explains the one limit we cannot engineer around: entries in the audit chain cannot be selectively erased, and where we must keep them we rely on our and the Customer's legitimate interest in a trustworthy record, or on a legal obligation.
United Kingdom, European Economic Area and Switzerland
You may lodge a complaint with your local supervisory authority. We would rather hear from you first, but this right is yours regardless.
California
We do not sell personal information and do not share it for cross-context behavioural advertising — under any definition, and we have never done so. You may request disclosure of the categories and specific pieces of personal information we hold, request deletion, and request correction. We do not discriminate against anyone for exercising these rights. The categories we collect, why, and who receives them are set out in sections 3, 5 and 6.
11. Children
BuildGate is a tool for software teams and is not directed at children. We do not knowingly collect personal data from anyone under 16. If you believe a child has given us personal data, write to [email protected] and we will delete it.
12. Changes to this policy
We will update this page when the Service changes what it collects or how it is used, and the date at the top will change with it. For a change that materially reduces your rights or expands what we collect, we will give notice to account owners — by email or in the console — at least 14 days before it takes effect, so that a Customer who disagrees has time to leave.
13. Contact us
Inova Studio LLC
Oregon, United States
inova.us
[email protected]
Privacy questions, data-subject requests and security reports all reach us at that address, and a person reads it.