Most teams think picking an EU region solves data sovereignty. It doesn't. Learn what sovereign Kubernetes actually requires — and how to get there.
There's a misconception bouncing around platform engineering teams that refuses to die: "We deploy in an EU region. We're covered on sovereignty."
We hear it from prospects. We hear it at conferences. We heard it repeatedly at KubeCon Europe 2026 in Amsterdam, where sovereignty was arguably the dominant theme — yet hallway conversations revealed how many teams still conflate picking a region with solving the problem.
It's an understandable mistake. But it's still a mistake. And with enforcement deadlines approaching for the EU AI Act, the Cyber Resilience Act, and others, it's becoming an expensive one.
Let's unpack what data sovereignty actually requires for your Kubernetes infrastructure — and what it doesn't.
Data Residency and Data Sovereignty Are Not the Same Thing
This is the distinction that trips up most engineering and compliance teams. Data residency means your data lives on a server inside a specific geographic border. Data sovereignty means that data is subject only to the laws of that jurisdiction — and no other.
When you run Kubernetes on a hyperscaler's EU region, your pods are in Europe. Your etcd state is in Europe. Your persistent volumes sit on European disks. But the company that owns and operates that infrastructure may be headquartered in an entirely different country, subject to an entirely different legal framework.
Several major jurisdictions have enacted laws that allow their governments to compel domestic technology companies to hand over data — regardless of where that data is physically stored. The most well-known example is the U.S. CLOUD Act, but it's not the only one. China's National Intelligence Law, Russia's data localization requirements, and others create similar dynamics. In each case, the legal reach follows the corporate entity, not the data center address.
Your data can sit in Frankfurt, staffed by local engineers, encrypted end to end. All good for security. None of it changes the jurisdictional question if the company operating that infrastructure is subject to foreign legal compulsion.
Sovereignty isn't about where data sits. It's about whether an organization can maintain control over infrastructure decisions end to end — and whether any foreign government can legally override that control.
Why This Hits Kubernetes Harder Than You Think
Kubernetes doesn't live in a vacuum. It sits on top of compute, storage, networking, and identity layers. Every one of those is a jurisdiction surface.
Think about what a typical managed Kubernetes service on a hyperscaler actually touches: the control plane is managed by the provider, usually opaque. Node pools run on provider VMs. Persistent storage uses provider block storage with provider-controlled encryption keys. IAM is the provider's system, often federated globally. Logs and metrics flow through provider pipelines. Container images sit in a provider registry.
Every single one of those components is subject to the legal jurisdiction of whoever owns the underlying infrastructure. Picking a region doesn't change the corporate ownership chain. And if even one of those layers leaks metadata outside your jurisdiction — or is subject to foreign legal compulsion — your sovereignty posture has a hole.
"Sovereign Cloud" Labels Don't Fix This Either
To their credit, major cloud providers aren't ignoring the problem. Many have rolled out "sovereign cloud" and "sovereign region" offerings — local staffing, local key management, governance controls. Some of that work is genuinely useful.
But the structural issue doesn't go away. A company subject to extraterritorial data access laws remains subject to those laws, even behind a subsidiary or a special region. For your Kubernetes infrastructure, a "sovereign region" might check the data residency box, but it doesn't necessarily give you sovereignty over your control plane, your metadata, your audit logs, or your encryption keys.
If compute allocation, service availability, and platform economics are dictated by a provider under foreign jurisdiction, then sovereignty is constrained — even if workloads remain technically within your borders.
The growing consensus in the open-source infrastructure community — and this came through clearly at events like KubeCon Europe and Open Sovereign Cloud Day this year — is straightforward: digital sovereignty starts with open source, and portability is a sovereignty requirement. If you can't freely migrate between providers, you likely don't have full control over your data.
What Sovereign Kubernetes Actually Requires
It comes down to one question: who owns and operates the infrastructure my clusters run on, and which laws apply to them?
Real sovereign Kubernetes means an organization retains complete authority over the location, access, and governance of its Kubernetes environment — not just where workloads land, but who can reach them and under what legal framework.
That breaks down into five requirements:
- Jurisdictional clarity. The entity running your infrastructure operates under a legal framework you understand, trust, and have explicitly chosen — not one imposed on you by a provider's corporate headquarters.
- Full-stack transparency. You can audit every layer — from the hypervisor to the container runtime. Proprietary black boxes are sovereignty gaps.
- Control plane ownership. Your Kubernetes control plane, etcd state, and cluster lifecycle management stay under your governance.
- Complete data locality. Not just storage — metadata, backups, logs, and telemetry all need to stay in-region.
- No lock-in. Sovereignty is hollow if leaving your provider means rewriting your entire stack.
Most teams satisfy one or two of these and call it done. Genuine sovereignty requires all five.
How We Solve This: Atmosphere + Navos on Your Hardware
This is where we stop describing the problem and talk about what we actually build.
Atmosphere is our OpenStack private cloud platform — an advanced OpenStack distribution powered by open-source technologies, running on Kubernetes, which allows you to deliver virtual machines, Kubernetes, and bare metal on your on-premise hardware. Its unique architecture runs OpenStack on top of Kubernetes, enabling simple rollouts, upgrades, and health checks.
Navos is our enterprise Kubernetes platform. It gives you production Kubernetes on any cloud — with built-in monitoring, security scanning, and expert support. 100% upstream. No fork. No lock-in.
Together, they give you the full sovereign stack: open-source private cloud underneath, production-grade Kubernetes on top, on your hardware, in your data center.
Here's why this combination matters for sovereignty:
You own the stack, top to bottom
Navos is built on unmodified upstream Kubernetes and Cluster API — the same project that powers every major cloud. Your workloads are portable by design. No proprietary API layers. Underneath it, Atmosphere runs on upstream OpenStack and Ceph. There is no proprietary layer anywhere in the stack.
Leave any time. Your manifests, your Helm charts, your clusters — they're yours.
You pick the jurisdiction
Navos's "Managed — Your Data Center" tier gives you the same SLA on your hardware, with data sovereignty and on-premise operations. We manage the clusters remotely. You keep the hardware and the legal jurisdiction. You can also deploy fully hosted in our data centers, or self-managed with our guidance — whatever fits your compliance requirements.
Atmosphere supports air-gapped deployments for maximum isolation, meaning OpenStack can run without internet connectivity. Updates can be downloaded and applied offline so sensitive environments stay current without exposure.
Production-ready, not assembly-required
Navos handles cluster provisioning, zero-downtime upgrades, patch management, and etcd backups — handled by engineers who contribute to Cluster API upstream. Deploy on AWS, Azure, GCP, OpenStack, or bare metal with a single API.
Monitoring and security ship built in: Prometheus monitoring, Grafana dashboards, log aggregation, vulnerability scanning, and operational assistants for root-cause analysis and right-sizing — all included from the free tier. Higher tiers add intelligent alert correlation, automated remediation, and compliance reporting for SOC 2 and regulatory frameworks.
Most platforms charge extra for this. We don't.
Jurisdictional advantage, by design
VEXXHOST is a Canadian-operated company serving customers across the globe. Canada holds an EU adequacy determination — one of a handful of countries recognized by the European Commission as providing an adequate level of data protection. That means we can service European customers without the jurisdictional friction that providers headquartered elsewhere face.
This isn't an accident. It's a structural advantage — and it's one of the reasons we're built the way we are.
We've been doing this a while
VEXXHOST has been building open-source cloud infrastructure since 2006. We adopted OpenStack in 2011 with its second-ever release, Bexar, and we've been active upstream contributors since. We're a CNCF Silver Member, Cluster API contributors, SOC 2 Type II compliant, and an OpenStack SuperUser Award winner. When you hit a bug, we don't file a ticket upstream. We are upstream.
What Sovereignty Doesn't Mean
Sovereignty doesn't mean you have to build everything yourself. That's the whole point of the Navos "Managed — Your Data Center" model — same SLA, your hardware, data sovereignty, on-premise operations. We handle the operational burden. You retain ownership and jurisdiction.
It doesn't mean giving up cloud-native workflows. Atmosphere integrates natively with CSI block storage and leverages Cluster API on the backend, supporting auto-healing, auto-scaling, and rolling upgrades. Terraform, Ansible, API-driven automation — it all works. This is a real cloud. It just happens to be one you control.
And it doesn't mean isolation. Navos deploys anywhere — AWS, Azure, GCP, OpenStack, and bare metal — so you're not walled off from the ecosystem. You're choosing where to run, not limiting what you can run.
The Regulatory Clock Is Ticking
The EU AI Act takes effect August 2026. The Cyber Resilience Act mandates software transparency and vulnerability reporting by September 2026. DORA, NIS2 — the list grows every quarter.
If your Kubernetes infrastructure runs on a platform where you can't fully answer the question "who has legal authority over this data?" — you have a gap that no region selector will close.
Ask the Right Question
Stop asking "Which region should I deploy in?"
Start asking "Who owns and operates the infrastructure my Kubernetes clusters run on, and which laws apply to them?"
If the answer involves a provider headquartered in a jurisdiction whose laws conflict with your own, your sovereignty posture has a structural hole — regardless of where the racks physically sit.
We built Navos and Atmosphere to give you a different answer: production Kubernetes on a fully open-source private cloud, deployed on your hardware, in your data center, operated by a team that doesn't just run these projects — we help build them. No fork. No lock-in. No jurisdictional surprises.
Data centers in Montreal, Canada · Santa Clara, USA · Amsterdam, NL · or your premises.
Team and Enterprise — talk to us about custom pricing.
