Digital Sovereignty – Where Should I Put My Kubernetes?

Yesterday, I spoke at the International PHP Conference in Berlin about digital sovereignty – and about why and how we’re migrating Flownative Beach from Google to Hetzner step by step. Here’s a summary for anyone who couldn’t make it.

The dreaded late-night call

You really don’t want to mention something like this in a talk: the pager app goes off in the middle of the night. A third of the projects in a cluster weren’t working properly, bookings were failing – and the frustrating part was that we’d actually done everything right (more on that in a moment).

I started my talk with this story from the early days of our migration to Hetzner because it illustrates what you’re suddenly responsible for when you’re fully in charge of the infrastructure. We’re a team of three people and, with Beach, we operate a PaaS for Neos and other PHP applications, all based on Kubernetes. In recent years, we’ve moved Beach from Google Cloud via the Open Telekom Cloud to Hetzner—first to the cloud, and now to bare metal. Why put yourself through that?

Sovereignty isn’t an add-on

You can’t just add digital sovereignty as an option. There’s no checkbox in the cloud portal you can tick to suddenly become sovereign. It’s the result of a series of very concrete decisions, and it’s a spectrum, not a switch. The question isn’t “sovereign or not,” but: Where on this scale do you want to stand before someone else makes the decision for you?

When people think of sovereignty, they often think first of data location. But even an “EU region” from a U.S. provider doesn’t make you independent: A U.S. company is subject to U.S. jurisdiction. Just how concrete this is is illustrated by a case from last year:

Following U.S. sanctions against the International Criminal Court, Microsoft blocked the email account of the chief prosecutor at the International Court of Justice. Imagine if that happened to companies and public administration in your country …

When a customer handling the personal data of millions of people needed true GDPR compliance, we looked for a European hyperscaler—and couldn’t find one. Scaleway, IONOS, OVH, and STACKIT exist, but none of them come close to the breadth of services offered by AWS, Azure, or Google. Hetzner sells infrastructure, not services. What a hyperscaler handles for you behind the scenes thus becomes your responsibility: network, storage, load balancers, control plane, node images, updates. You no longer use a platform but become the platform yourself. This only works if you consistently automate and embrace infrastructure as code.

Murphy’s Law

Back to that night: When scaling up, we had inherited an IP address that had previously been used by a spammer. Google blocked it, and suddenly customer apps could no longer access critical services. All requests from our clusters to the Google network went nowhere, and the only way to get off the abuse list was to wait. The bitter irony: We hadn’t yet migrated our Beach control panel—it was still running on Google. So, at times, the Hetzner clusters couldn’t even access their own control panel.

Ultimately, we were able to resolve this by developing our own operator that routes outbound traffic via floating IPs. But this was not an off-the-shelf solution, nor was it a problem we had anticipated.

Servers are in short supply

That was just the first surprise. Capacity is suddenly in short supply, and not just at Hetzner. Even with Azure or Telekom, you sometimes can’t launch new servers because there aren’t enough available. The exodus to the EU and the AI boom are exacerbating this. And details that a hyperscaler usually handles for you are sometimes learned the hard way. An exotic example: If you use standard memory instead of ECC RAM, you have to expect that cosmic radiation will statistically reliably flip bits and mess up your data.

Should you do this yourself?

Of course, my favorite answer: It depends. Three options are available—US hyperscalers, managed Kubernetes from the EU, or running it yourself. Strictly speaking, US hyperscalers are out of the question for personal data anyway. Running it yourself is cheaper: In a cluster, we paid around €1,500 per month for traffic with Google, and €33 with Hetzner. But cheap infrastructure doesn’t mean free operation. You need far more resources to run monitoring and other background systems, and you also need backup servers that can step in immediately in case of hardware failures.

And three people is definitely the minimum—not just because of the workload, but because of the on-call rotation. We’ve gained a lot of experience with this over the years, not least because each of us has been administering servers ourselves for at least 25 years.

Whatever you decide to do: make sure to keep several backup options available. Use standards; use components that are interchangeable whenever possible. Because the alternative—not caring about digital sovereignty—is not a real option. You want to stay ahead of the curve, as they say in the fire department. Or, to stick with the Flownative Beach analogy, ride the wave and not get caught off guard by it.

You can find the slides from the talk here.