Why I'm building an EU-sovereign managed SaaS platform

In June 2025, Anton Carniaux — Microsoft France's director of public and legal affairs — sat before a French Senate commission of inquiry and was asked a simple question, under oath: could he guarantee that data belonging to French citizens, held by his company, would never be handed to a foreign government without the consent of the French authorities? On the record, he answered: "Non, je ne peux pas le garantir" — no, I cannot guarantee it.

Let that sit for a second. The servers were in France. The contract was with a French subsidiary. The invoices were in euros. And it still wasn't enough — because the parent company answers to a jurisdiction that can compel it, wherever the bytes happen to live.

That gap, between where your data physically sits and who can legally be forced to reach into it, is the entire reason I'm building what I'm building.

This is the first post in a series where I build a managed, EU-sovereign SaaS platform in public: every component, every decision, every dead end. There's no code in this one. This is the why. The build starts in the next post.

What you'll get from this post

A clear picture of what I'm building and who it's for, the single technical bet the whole thing rests on, and why I think now is the moment for it. If you run an EU company and you've ever felt uneasy clicking "I agree" on a US cloud, this is for you.

Residency is a checkbox. Sovereignty is a jurisdiction.

Every hyperscaler will sell you an "EU region." Some now sell you an "EU sovereign cloud" with European-sounding names and local staff. It is necessary, and it is not sufficient. A US-headquartered company is reachable under the US CLOUD Act regardless of where it stores your data. The data centre map is marketing; the org chart is the risk.

Real sovereignty isn't a flag on a region selector. It's the answer to one question: who can be compelled to betray you, and under whose law? If the honest answer involves a court on another continent, you don't have sovereignty. You have residency with extra steps.

The two bad options EU teams have today

If you're a European team that wants to ship a SaaS product right now, you mostly choose between two unhappy paths.

The first is the slick PaaS — push your code, it's live in minutes, beautiful developer experience. The catch is that it's almost always US-owned, and the convenience is built out of proprietary primitives: their database client, their blob store, their edge runtime, their analytics. Each one is a small handcuff. By the time you've shipped, leaving means a rewrite, and your data residency is whatever their terms of service say it is this quarter.

The second is to do it properly yourself: real Kubernetes, in an EU provider you trust, with control over every byte. This genuinely works — and it requires a platform engineer you probably can't afford, or three of them, plus the ongoing tax of operating clusters, upgrades, backups, and an on-call rotation. You wanted to build a product. Instead you're running infrastructure.

So the choice is convenience-with-lock-in or sovereignty-with-a-second-full-time-job. Most teams pick the handcuffs because the alternative is too expensive. That's the gap.

What I'm actually building

A managed platform that fills the missing middle: it runs and operates your containerised SaaS for you, in the EU, so you ship business logic and never touch infrastructure — without buying into a single proprietary primitive.

You hand over a container. I run it: deployed from a git commit, observed, secured, backed up with restores that are actually tested, upgraded on a schedule, and kept inside EU jurisdiction. You get the "push and it's live" feeling of a PaaS and the control of running your own Kubernetes, without the lock-in of the first or the headcount of the second.

The whole thing rests on one deliberately small contract. The platform runs anything that is a container listening on $PORT, speaking Postgres, exposing liveness and readiness checks, and reading its config from environment variables. That's it. Meet that boundary and you're a first-class citizen, whether you brought a Next.js app, a Go service, or a Django monolith. I'm opinionated below that line — Kubernetes-shaped, GitOps, observability on, EU regions — and I get out of your way above it.

Portability is the product, not a feature

Because the contract is that small, your app doesn't care what it runs on. It starts life on a single cheap box in Germany. When you grow, it moves to a high-availability cluster. When compliance demands it, it moves to managed Kubernetes or even your own cloud. Same container, same config — only the substrate underneath changes, and that's my problem, not yours. No rewrite at any rung of that ladder.

That portability is also the honest version of sovereignty. Lock-in and sovereignty are the same problem wearing two hats: both come down to who controls the exit. A platform you can walk away from cleanly is one that has to keep earning your trust. So "you can always leave" isn't a disclaimer here — it's the pitch.

And the moat underneath all of it is jurisdictional, not geographic. Anyone can rent a rack in Frankfurt. Far fewer can say: EU legal entity, EU staff, EU data, no foreign court with a key to the back door. That's the part that's hard to copy, and it's the part that actually protects you.

The honest part

The obvious objection is fair: isn't this just reselling cheap EU compute with extra steps? The steps are the product — the operating, the upgrades, the tested restores, the guardrails — but I'd rather you ask the sharp question than the flattering one.

The harder truth is that the difficult part isn't the technology. Boring, well-documented infrastructure is a solved problem; I'm choosing it on purpose. The difficult part is trust, and trust is earned by being the one holding the pager and showing the work — which is exactly why I'm building this in the open instead of behind a "request a demo" wall.

I also have to hold myself to the standard I'm selling. "Sovereign" EU providers sometimes turn out to have US parents or US-hosted control planes. If I'm going to make this claim, I have to be able to defend the whole corporate stack, not just point at a data-centre on a map. I'll show that work too, including the uncomfortable bits.

There's a sharper version of that objection aimed straight at me: I'm building an anti-US-lock-in platform on GitHub, pushing images to GitHub's registry, with an AI assistant from a US company helping me write the code. Fair. But where a dependency sits is the whole point. None of those touch your data or your running app — they're in how I build the platform, not in the path your customers' bytes travel. That data path is the line I won't cross: no foreign entity that can be compelled to reach into your data, full stop.

The build-time supply chain is a softer problem — lock-in, not sovereignty — and I hold it to the exact rule I'm selling you: nothing I can't walk away from. Git is portable by design. GHCR has a self-hosted successor, Harbor, already on the roadmap. An AI tool is just a tool with no claim on me. So as the dependencies that matter show up in this series, I'll name them, say plainly whether each is data-path or build-path, and either defend it or replace it — out loud.

Where this leaves us

The bet is simple: there's a real and growing number of EU teams who want to ship product, not operate infrastructure, and who can no longer accept "trust us" from a company that has testified, under oath, that it can't make the promise. Regulation is moving the same way — the EU Data Act is even killing cloud switching fees — and the appetite for a credible European alternative has never been higher.

So I'm going to build one, component by component, and write down every step. To keep myself honest, this blog is the first thing running on the platform — customer zero. Next post, I get concrete: the architecture, and the exact contract that keeps everything portable. After that, the first real build — a reproducible cluster on a cheap German box, created entirely from code, with nothing clicked in a console.

---

I'm building this in the open, and I'll run it for EU teams who'd rather ship product than hire a platform engineer. If that's you, follow along via RSS — every build post lands there first — or start with what this project is about.