Subprocessors
Every third party that touches your data, what they do with it, and where they are.
Effective · Enyon Software Limited
To run BulbQA we use a small number of third parties. Each is bound by contract to process data only on our instructions, with protections no weaker than the ones we give you. This is the complete list.
| Subprocessor | Purpose | Data | Location |
|---|---|---|---|
| Amazon Web Services | Hosting, file storage and content delivery | All service data | Ireland (eu-west-1) |
| Supabase | The managed Postgres database | All service data | Ireland (hosted on AWS eu-west-1) |
| Google LLC | Sign-in, and Workspace directory where an organization connects it | Name, email address, profile image | United States, EU |
| Stripe | Subscription billing and payment processing | Billing contact, company name, payment details | United States, Ireland |
| Resend | Transactional email — invitations and account notices | Name, email address | United States |
| Better Stack | Crash reports from the desktop Runner and error reports from our own servers | Redacted stack traces, the app or service version, and — from our servers only — the error message. No account, no request content | European Union (vendor incorporated in the United States) |
All service data rests in AWS eu-west-1 (Ireland). Where a subprocessor operates outside the UK and EEA, transfers rely on the UK International Data Transfer Addendum and the EU Standard Contractual Clauses.
What our error reports contain
Better Stack receives error reports from two places: our own servers, and the Runner on your machine. The second is the one worth being precise about, because a crash report from a QA's machine is exactly the kind of thing that could carry repository paths or script output. It does not, because the report is not scrubbed — it is rebuilt.
- An error event is reconstructed from a fixed allowlist of fields rather than filtered for known-bad ones. Anything not on that list is dropped, including anything a future SDK version might add.
- File paths never leave the machine. Each frame's path is replaced by an opaque build identifier that only matches our own source maps. A checkout directory, a branch name or a customer's folder structure cannot survive that substitution.
- The error message is discarded before sending and replaced with a fixed string, because a message can be raised by your repository's own code and quote its data. Source lines, local variables, function and module names go the same way.
- What remains is the shape of the failure: line and column numbers against our build, the app version, and whether it was fatal. No account, no organization, no test data, no script output, no breadcrumbs, no session replay, no performance tracing, and no native crash dumps.
- Only crashes are sent. There are no analytics events, no usage metrics and no logs — the transport drops anything that is not an error report, so nothing else can be added by accident.
Reports from our own servers are treated differently, and deliberately so. That is our code on our infrastructure, so the error message and the stack are kept — without them a report says only that something failed on a line number. What is never attached is the request that caused it: no body, no headers, no query string, no cookies, and no user or organization identifier. Messages are additionally scrubbed for credentials, email addresses and the row values a database quotes back in a constraint error, so the common ways customer data ends up inside a message are closed.
We list Better Stack rather than reasoning that a redacted report is not really personal data. A page that decides on your behalf which vendors are worth mentioning is not a list you can rely on.
Who is deliberately not on this list
No model provider is a subprocessor of ours, and this is by design. BulbQA's AI features — reviewing a regression plan, drafting a bug report — do not call a model from our servers. They invoke a coding agent CLI that is already installed on the user's own machine, signed in to that user's own account. The request travels from that machine to that provider without passing through our infrastructure.
The practical consequence for your security review: adding an AI provider to your own approved list is between you and that provider. We are not in the path, so we cannot be the weak link in it.
The same principle covers your repository. The Runner executes your code locally, so no build infrastructure, sandbox provider or CI vendor of ours ever sees it — because we do not have one.
Changes to this list
We will update this page before a new subprocessor starts processing customer data, and email organization owners at the same time. If you object to a new subprocessor on reasonable data protection grounds, tell us within 30 days and we will work with you on it; if we cannot resolve it, you may terminate the affected part of the service and we will refund any unused prepaid fees.
Contact
Questions about any entry here: privacy@enyon.dev.