If you followed KubeCon + CloudNativeCon Europe 2026 in Amsterdam, you heard the word “sovereignty” a lot. On day two it was the main thread of the keynotes, and several large European organizations walked through how they are building platforms they fully control, using CNCF projects instead of depending only on hyperscaler services.
This post sums up what was shared and what it means for platform teams, inside or outside Europe.
Why this came up now
The driver is mostly legal. European banks, railways, telcos and public bodies have to show they keep control over their data and operations, including where laws like the US CLOUD Act could give a foreign government access. Add the EU Cyber Resilience Act, and many regulated teams are asking the same question: if we had to, could we run this without any one provider?
Sovereign code vs sovereign deployment
Jan Melén, Vice Chair of the CNCF, gave the most useful frame of the day. He split the topic into two parts:
- Sovereign code: the source code itself. This should stay global and shared. If every country forks Kubernetes, everyone loses.
- Sovereign deployment: where and how that code runs, who operates it, and under which rules. This is where local control belongs.
In other words, keep one open codebase and make the operating layer local. That is a good fit for Kubernetes, since the same API runs on a public cloud, a local provider, or your own racks.
What SNCF shared
SNCF, France’s national railway, was represented by Thomas Comtet and Yann Rotilio. Their story was blunt: managed cloud offerings alone did not meet their resilience targets, so they rebuilt the foundation using open source layers.
According to Kubermatic’s recap, SNCF now runs more than 200 clusters across Azure, AWS and a private cloud on OpenStack. About 30% of their applications stay on premises, and the internal environment is built to feel like a public cloud to the teams using it. The key point is that developers get the same experience wherever their app lands.
What Swisscom shared
Swisscom published what Kubermatic described as the first sovereign Kubernetes reference architecture on the CNCF architecture site (architecture.cncf.io). They moved about 60% of their internal workloads onto it within nine months. A public reference architecture matters because it gives other regulated teams a starting point they can review, instead of a vendor pitch.
What Saxo Bank shared
Oskar Kristiansen from Saxo Bank talked about the developer side. Saxo uses a “Service Blueprint” model: developers pick a blueprint from a catalog and get everything they need, without touching Kubernetes details directly. Behind that catalog, Kubernetes operators and GitOps handle the work. Kubermatic’s recap puts their number of automated operations at around 1,800.
This is where sovereignty and platform engineering meet. If your developers are tied to one provider’s console and APIs, moving is hard. If they are tied to your own blueprints and your own Kubernetes APIs, the provider underneath can change.
What any platform team can take from this
You do not need to be a railway or a bank to use these ideas. A few habits make your platform portable, whatever your reasons:
- Stick to upstream Kubernetes APIs. Prefer Gateway API, CSI drivers and standard CRDs over provider-only features where you can.
- Run everything through GitOps. If your clusters are described in Git (with Argo CD or Flux), standing up the same setup somewhere else is a repeatable task, not a migration project.
- Abstract infrastructure with your own APIs. Tools like Crossplane, or a simple internal catalog like Saxo’s, let you change what is underneath without changing what developers see.
- Own your identity, secrets and observability. These are the hardest pieces to move later. Keep them on open standards like OIDC and OpenTelemetry.
- Practise moving. Run at least one non-critical service on a second provider or on premises. You learn more from one real move than from any diagram.
A quick way to see how portable you are today is to list your clusters and ask which ones you could rebuild elsewhere in a day:
kubectl config get-contexts
kubectl get crds -o custom-columns=NAME:.metadata.name | grep -v -E 'k8s.io|x-k8s.io'
The last command lists the custom resources that are not from upstream Kubernetes projects. Each one is a dependency you would need to bring with you.
Other news from the same day
- Solo.io donated its Agent Registry to the CNCF, a catalog for approved AI agents, tools and artifacts.
- VMware released vSphere Kubernetes Service 3.6 with Kubernetes 1.35 support.
- Planet Labs showed how it processes terabytes of satellite data a day on Kubernetes, data that has helped authorities issue billions of euros in fines for illegal deforestation.
Takeaways
- Sovereignty is now a mainstream platform requirement in Europe, not a niche topic.
- Keep the code global and shared. Make deployment and operations local.
- GitOps, upstream APIs and your own developer catalog are what make a platform portable.
- Swisscom’s reference architecture on architecture.cncf.io is a good place to start if you need to design one.
Sources: KubeCon EU 2026 Day 2 recap, Virtualization Review, KubeCon EU 2026 recap, Kubermatic, CNCF Architecture