Why we won't run on AWS, Azure, or Google.

The context

When an EU organisation pushes data to a SaaS that's ultimately owned by a US company or hosted on US-owned cloud, that data becomes — under US law — reachable by US authorities. The CLOUD Act gives them that reach even when the servers physically sit in Europe. EU rulings (most prominently Schrems II) have repeatedly held that this is a real legal problem for personal data of EU residents.

For a marketing team automating a Trello board this is mostly theoretical. For a hospital, a bank, a court, a school, a government body — it's a procurement-blocker. Some of these organisations literally cannot use a US-cloud automation tool. Others can, but only with extra contractual layers and a permanent open question. We think there's room for an alternative that closes that question by construction.

What this looks like in regulation

We don't claim Bridgekit makes you compliant with any of these frameworks — compliance depends on how YOU use the tool, not just the tool itself. What Bridgekit does is take the data-residency and US-cloud-exposure questions off your plate.

GDPR (Reg. 2016/679)

EU's general data protection regulation. Applies to anyone processing personal data of EU residents. Bridgekit's hosting and data-processing arrangements stay within the EU, which simplifies your DPIA significantly.

Schrems II (CJEU 2020 ruling)

Invalidated the EU-US Privacy Shield. Established that transfers of personal data from the EU to the US generally require additional safeguards. By keeping data in EU jurisdiction with no CLOUD-Act-exposed providers in the path, the transfer question doesn't arise.

EU AI Act (Reg. 2024/1689)

Sets requirements for AI systems used in the EU, including source-of-data and traceability obligations. If your workflow uses AI, where the AI runs and where its training data sits matters. Bridgekit's planned LLM integrations are EU-sovereign (Mistral, Scaleway Generative APIs).

NIS2 Directive (2022/2555)

Cybersecurity obligations for organisations in 'important' and 'essential' sectors. Brings supply-chain risk firmly into scope — and a US-cloud SaaS in your pipeline is a supply-chain dependency a NIS2-regulated organisation has to assess.

Legal frameworks evolve. Talk to your DPO or counsel before relying on any automation product — including ours — for compliance. We try to make it easier; we can't make it your decision.

What we do, concretely

• · Compute on Hetzner Cloud (Falkenstein, Nürnberg). Hetzner is a German company; Hetzner data-centres are physically and legally inside the EU.
• · Postgres self-hosted on Hetzner. No managed database service from a US-owned provider.
• · Backups go to Scaleway Object Storage in Paris — a French company, EU jurisdiction, geographically separate from primary.
• · External services (payments, email, AI, CDN) are EU-based: Mollie (NL), Mailjet (FR), Mistral (FR), BunnyCDN (SI). We list all of them on the Trust page.

Honest about the limits

Sovereignty isn't free, and isn't absolute. Some things we accept:

• Code hosting on GitHub. We mirror to a self-hosted Git later, but for the bootstrap phase GitHub's ecosystem is too useful to give up. No customer data ever lives in our GitHub.
• NuGet, npm, Docker Hub for build-time dependencies. We plan a self-hosted proxy/cache. Same principle: no customer data passes through these.
• Stack Overflow, search engines, AI coding assistants for development. These are knowledge-infrastructure, not data-path. We treat them like a shared engineering library.

Where we make a pragmatic exception, we say so on the Trust page and explain the mitigation. The customer-data path stays clean — that's the line we hold.