01 Solution · Sovereign cloud

Sovereign cloud from a European cloud provider that also runs it

A server in Frankfurt is not sovereignty yet. What decides the question is who can gain access under which law, who operates the platform and whether you could change your architecture without anyone else agreeing. We establish where you actually stand, rebuild your sovereign cloud on open standards step by step and then run it around the clock.

Book a call Or read the whitepaper first

Service model: Consulting, transition and operations from one source: one contract, one team, one responsibility.
Data centres: German data centres, ISO 27001 certified. Or your own: we bring the stack.
Platform: Proxmox, KVM or Kubernetes on Debian. All open source, nothing proprietary.
Exit commitment: Your configurations stay with you as Git repositories. No lock-in, not even to us.

02 Starting point

The server sits in Europe. The evidence is still missing.

Three sentences that come up almost word for word in first conversations.

“Our data is in the EU, after all.”

That answers the question about the storage location, not the one about legal authority. Under certain conditions the US CLOUD Act reaches data held by US companies, no matter whether the server stands in Frankfurt, Dublin or Virginia.

“We are tied to one provider.”

Proprietary services and provider-specific interfaces: the deeper the integration, the more expensive the way out. And the smaller your room for negotiation at the next change of terms.

“Consulting, rebuild and operations sit with three different firms.”

A consultancy, a systems integrator and an operator. Responsibility shifts at every handover, and with it the question of who holds access when it matters.

None of these sentences is a failure. They are the normal result of sovereignty having been an architectural preference for years. Under the EU NIS2 directive and the national laws that implement it, in Germany since December 2025, it has become something you have to evidence.

03 The solution

A sovereign cloud is not bought. It is built and then kept that way.

Six building blocks that together cover the full life cycle: from establishing where you stand to the evidence that accumulates while the platform runs.

Your position on three levels

We look at location, at access and applicable law, and at operations and architecture separately. The result says which of the three levels puts you under the most pressure, not whether you are “sovereign” or “not sovereign” overall.

Stack assessment and sovereignty roadmap

Every core component is assessed for replaceability: how long a switch would take and what it would cost. That produces an order of work with effort and risk per step.

Open standards instead of a proprietary layer

Proxmox or KVM for classic virtualisation, Kubernetes to CNCF standard where it carries the load, storage and databases on open standards. No proprietary operating system, no home-grown orchestration.

Migration by business criticality

Less critical systems first, core systems with more care and more test coverage. Every service has a fallback path, and there is no cut-over date on which everything tips at once.

Cloud managed services with evidence built in

24/7 with on-call cover, monitoring and alerting, patch and escalation management. Access control, configuration state and tested recovery are documented as you go, instead of being reconstructed before an audit.

Exit capability as a test criterion

Your configurations stay with you as Git repositories, the stack is open source and close to CNCF. Any competent provider can take it over, and anyone who wants to understand what we do gets it explained.

04 How it works

Consulting, transition, operations: one contract instead of three remits

The three phases can be booked separately. The point of the offering is that they do not have to be.

Phase 01

Consulting

Your position and a stack assessment across all three levels. You get a report on where you actually stand and a sovereignty roadmap covering the next 12 to 24 months. After that you decide whether anything gets changed at all.

Phase 02

Transition

Stepwise migration into an open architecture, without new provider dependency. We work in five steps: analysis, target picture, test environment, migration, operations. Every handover has a go or no-go, and until the migration your existing environment keeps running untouched.

Phase 03

Operations

Ongoing sovereign operations, 24/7 with on-call cover. The evidence accumulates during operations rather than in a separate compliance project. Your configurations stay with you, and the contract stays terminable.

Whoever operates it at the end plans differently. We do not build anything we would not want to operate ourselves afterwards.

05 Proof

Three projects where the way out of someone else’s cloud has already been walked

Chosen because they show three different starting points: out of AWS, out of Azure, and own infrastructure under load peaks.

Textbroker A self-built AWS environment with more than 50 services. Then the systems architect, the platform manager and the DevOps people left the company. After the move: 75 per cent lower platform and service costs at unchanged availability. Debian · Percona · MariaDB · GitLab · Docker

Innotech The application ran in Azure, with severe performance problems and a cost curve that only pointed upwards. Two months from breaking ground to the new production environment on private cloud, then 24/7 with patch and escalation management. Proxmox · Debian · HAProxy · PostgreSQL · Redis

Aerosoft Their own dedicated infrastructure, but brutal load peaks at product launches and on Black Friday. Availability permanently above 99.9 per cent, the complete stack from one source. Proxmox · HAProxy · Apache2 · Percona · Redis

06 Read on and check

Free whitepaper · 8 pages

Digital Sovereignty

By Andreas Hankel, CTO onehundred. Download in exchange for your e-mail address, no sales call.

Get the whitepaper

07 To be honest

Four objections that come up in almost every first conversation

“Sovereignty means getting out of the cloud, does it not?”

Not necessarily. It means that your architecture does not tie you to a single provider. That can include public cloud, private cloud, edge or your own data centre in any sensible combination. The question is not where something runs, but whether you could move it somewhere else without anyone else agreeing.

“Our data is in the EU, that is enough for us.”

That answers the location question, not the legal one. Data residency describes where data is stored, data sovereignty describes who can gain access under which law. Treating the two as the same leaves a gap in an audit that cannot be closed at short notice.

“We cannot move everything at once.”

You should not. The transition is deliberately stepwise and follows business criticality: less critical systems first, core systems later with more test coverage. After every phase there is a go or no-go at which you can stop, without anything in production having been changed.

“Then we depend on you instead of on the hyperscaler.”

Only if we pulled you onto a platform of our own. We do not. The stack is open source and close to CNCF, and your configurations stay with you as Git repositories. The price we pay for that: we have to win you over again every month. That is exactly how it is meant to work.

08 Fasttrack analysis

Nils HornkeCEO, onehundred

A conversation in which you find out where you actually stand

There are people on the team who have been CTOs themselves. Tell us which of the three levels concerns you most: location, access or operations. You get an assessment of whether your setup has a problem and where it sits. We regularly tell people that they do not need to change anything.

Book a first conversation

15 minutes · not a sales call · book directly in the calendar

09 Frequently asked questions

What cloud leads ask us about this

What is a sovereign cloud?

An environment in which you decide about data, access and architecture yourself, without needing a third party to agree. It covers three levels: where the data sits, who can gain access under which law, and who operates the platform.

What is the difference between data residency and data sovereignty?

Data residency answers where data is stored. Data sovereignty answers who has legal authority over it. A German data centre run by a US group answers the first question fully and the second one not at all.

How do we become independent of the hyperscalers?

Through open standards and a tested exit capability per core component, not through moving to a European cloud provider on its own. The first step is an assessment of which services really tie you in and what a switch would cost.

Do we get consulting, migration and operations from one source?

Yes, that is exactly how this offering is cut: consulting, transition and operations with one contract, one team and one responsibility. You can also commission the three phases separately.

Does onehundred take on the legal NIS2 assessment?

No. We take full responsibility for the technical sovereignty basis. For the legal side, meaning whether you are in scope, how an ISMS is built and which reporting duties apply, we work with specialised partners and say openly in the first conversation where that line runs.

Where are the servers?

In German data centres. On request in your own as well, and we bring the stack. Your data does not leave the German data centres.

Is onehundred ISO 27001 certified?

onehundred works to ISO 27001 and BSI compliant processes, and the data centres in use are certified. We do not claim a certification of the company itself.

What if we want to operate it ourselves again in two years?

Then you take over your Git repositories and carry on. That is exactly why the stack is chosen the way it is.

10 Insights · NIS2 and digital sovereignty