Most sovereign clouds are sovereign. Fewer of them are clouds.
Data stays in the EU. No CLOUD Act. GDPR built in. European ownership. Everyone says it now, and for most it's true. It is no longer an argument that separates vendors. The question that decides whether you actually gain something is different: what can your developers do with the platform once it's in place? A cloud requires four things — self-service, a service catalog, elasticity, and API first. A great deal of what is sold as sovereign cloud is virtualization with a portal, placed in a European datacenter.
Four questions to ask every vendor on your list
Including us. The answers differ more than the sovereignty promises do.
Can a development team order a database without anyone opening a ticket?
If the answer is that they fill in a form that lands with operations, you've bought an ordering portal, not self-service.
Do they get a database, or a machine to install one on?
The difference between a service catalog and a VM catalog is who does the work after the button is pressed. Ask specifically about Postgres, queues, object storage, and secrets.
Can they scale up and down themselves, within the limits you've set?
Elasticity means capacity follows demand without someone making a decision every time. Without it you have statically allocated infrastructure with a nicer dashboard.
Can everything the portal does also be done in code?
An API that covers a subset of the portal means automation and infrastructure-as-code stop at that subset.
How we answer
Four requirements, four answers.
Self-service
A team goes from idea to running environment without anyone else opening a ticket. You keep control through policy and permissions instead of through a request queue.
Service catalog
Databases, object storage, cache, message queues, secrets, and functions as ready-made services. Images for all of them ship with the installation and live in your own registry.
Elasticity
Workloads scale within the limits you've defined, on the capacity you have. You set the ceiling, the platform handles the rest.
API first
Everything the platform does can be done in code. The portal is an interface to the API, not the other way around.
Sovereignty as architecture, not as a promise
Others say who they are. This is how it's built — and it can be verified.
You keep the keys
Clusters connect through an agent inside the cluster dialing out to the control plane with a one-time token. No inbound firewall opening, and we store no standing credentials to your API server. The agent can be blocked by you, immediately.
Your audit log shows a person, not a platform
When an operator does something in a cluster, the operator's own identity travels all the way through. Your own Kubernetes audit log shows who did what. Vendor access that only shows up as “the platform” is one of the most common findings in security reviews. That question is solved in the architecture instead of in a policy.
Your data never reaches us
The platform runs in your environment. Your applications and your production data never pass through us. That follows from how the system is built, not from how we promise to behave.
No telemetry in the license track
With a license period, nothing is reported. Month-to-month, the platform sends a technical customer number, a created/deleted event per managed resource and a daily inventory snapshot. No compute data, no IP addresses, no user identities.
Swedish company, European delivery
Swedish owners, no American parent-company structure. The customer portal is operated in Sweden and mail goes through our own mail server, not an American email service. Development and support within the EU.
Open standards
Kubernetes all the way down. What you build can be moved, and you don't have to take our word for it.
What sovereignty doesn't solve for you
- The hardware. The servers will likely come from a non-European manufacturer regardless of who you buy the platform from.
- Kubernetes. We don't deliver the cluster. You build it yourself or through a partner, and that choice has vendor questions of its own.
- Operations. We are a software layer, not a managed service. You operate your environment, and that responsibility comes with the sovereignty.
- Disconnected operation. Not fully today. Resource images and the control plane work without connectivity, but the delivery channel for platform upgrades without internet is on the roadmap.
Frequently Asked Questions
Sovereignty, jurisdiction, and responsibility in practice.
Compliance
Support for GDPR, NIS2, and ISO 27001 in sovereign deployments. All data processing happens locally, all access is logged, and policy as code enforces your security standards.
Ask us the four questions
Bring your requirements list and the vendors you're already looking at, and we'll go through what each one actually answers. If another fits better, we'll say so.
Book a walkthrough