Sovereignty arguments usually end in a slogan. This month, two European governments ended theirs in documents you can download.

Germany's IT-Planungsrat — the governance body where federal, state, and municipal administrations agree on shared digital infrastructure — decided in March 2026 that the standards of the Sovereign Cloud Stack (SCS) are now a binding component of the Deutschland-Stack, the common technical basis for government IT. In parallel it adopted a standard framework naming over 50 open standards across seven layers of the government stack, from document formats at the top of the list to OpenStack, Kubernetes, and identity management underneath. For the cloud layer, SCS is the reference. The Open Source Business Alliance's summary is the operative one: interoperable, verifiable, and without lock-in — and for the first time, open-source reference architectures are fixed requirements for government cloud procurement, not aspirations.

The Netherlands went one step further down the stack. This month the Dutch NDS Cloud programme published Het Ontwerp — the design of a sovereign government cloud — for public review, alongside a working proof of concept. The design commits to: a container platform compliant with the Haven standard, a government-wide sovereign cloud at the IaaS layer, open-source technology, hosted in a government data centre, focused on mid-category applications. Public review is open now; feedback sessions ran for government bodies on September 24 and for market parties on September 28; a market consultation is open via TenderNed. The Dutch framing is blunt about why they published it: transparency is essential to sovereignty.

These are two different instruments, and the difference is the lesson.

The law and the blueprint

The Germany Stack is a procurement standard. It binds buyers: if German public bodies build or buy cloud infrastructure, the SCS standards are part of the baseline. A standard governs what may be purchased. It does not tell an operator how to build anything.

The Dutch design is an engineering blueprint. It says which container platform standard, which hosting model, which application class, and it exists as a running PoC. A blueprint tells you how something was built and lets you check the claim by building it yourself.

Communities need both. Most community infrastructure projects fail in one of two symmetric ways: they get the money and buy whatever is on the vendor shortlist (no standard), or they get the principle and no concrete reference to copy (no blueprint). Germany fixed the first failure for itself. The Netherlands is addressing the second — in public, with review windows, on purpose.

And the two instruments reference each other's ecosystem. SCS itself is maintained under the Open Source Business Alliance as open standards plus open implementations — R9 shipped OpenStack 2025.1 (Epoxy) via OSISM, Ceph Reef, and Kubernetes 1.33, with an upgrade path that allows skipping a release and a Domain Manager role the SCS community contributed upstream. The Haven standard is a Kubernetes configuration specification, with the compliance tooling published as open source. Neither stack asks you to trust a vendor's word for what "sovereign" means; both ask you to run a check.

Haven: the standard that started as municipalities refusing lock-in

The Dutch government did not invent its container standard this year. Haven is a standard from the VNG — the association of Dutch municipalities — declared in March 2022, and its origin story is unusually relevant to anyone running community infrastructure.

Haven exists because Dutch municipalities wanted to host each other's applications without re-platforming every time. The specification pins a particular configuration of Kubernetes so that a Haven environment behaves the same regardless of what sits underneath — municipal data centre, commercial provider, whatever. An app that runs on one Haven environment runs on all of them. The enforcement mechanism is not paperwork: it is the Haven Compliancy Checker, which validates clusters automatically, and it is the single mandatory obligation in the whole standard.

The governance model is worth copying too. Dutch administrative law has the concept pas toe of leg uit — apply or explain. Haven applies it: municipalities must use the standard or publicly explain why not. That is accountability without a veto.

Two more details deserve attention, because they are unusually honest:

Haven+ is a suite of self-hostable components — monitoring (metrics, logging, tracing), authentication, databases, certificate management, secret management — so that a Haven-compliant platform does not quietly depend on Azure Blob Storage or AWS S3 for the things that matter. The project itself documents the gap in its own standard: compliance does not automatically make you platform-agnostic, because the standard still permits platform-specific storage services. Rather than pretending that away, they ship the components that close the gap. That is the same reflex as SCS publishing its own certification standard instead of letting marketing define conformance: define the words, then make them checkable.

The standards stack is FOSS the whole way down. Haven = Kubernetes configuration + CNCF open standards, published on a public GitLab, with its own compliance tooling in the repo. SCS = OpenStack + Ceph + Kubernetes under open standards with an open certification scheme. Nothing in either stack requires a license server, a phone-home, or a vendor's permission to read your own logs.

What a community operator can actually do with these documents

Skip the inspiration. Here is the operational takeaway.

  1. The blueprints are public and inspectable. The Dutch design document, its appendices, and the PoC status report are published for review — in Dutch, from a government whose entire premise is that the design should be readable by outsiders. SCS publishes its standards, reference implementations, and certification scheme openly. You do not need to be a nation-state to read either.

  2. The compliance tooling runs on your hardware. The Haven Compliancy Checker validates any Kubernetes cluster against the standard. If you operate a community cluster, running a foreign government's compliance checker against it costs nothing and tells you something real about your own portability. SCS's certification scheme (SCS-0004) plays the same role one layer up.

  3. The demand signal is now formal. Two German states moved 50,000 workers to AGPL Nextcloud and the German federal government is spending €1.9 billion on Microsoft licenses it cannot escape. The Deutschland-Stack is what happens after the invoice: the standards layer that makes the next migration a procurement decision instead of a heroic one. The pattern to copy is not "be Germany" — it is "decide your stack in writing, before the vendor renewal arrives."

  4. The gaps are named, not hidden. The German standard framework explicitly lists, layer by layer, where binding standards do not exist yet. That is the same move as the Canadian infrastructure inventory that found no Canadian CDN, DNS, or DBaaS: an honest map of what is missing is more useful than a complete-looking catalog that lies. A community that inventories its own gaps honestly can build the missing pieces itself — that is most of what sovereign infrastructure work actually is.

What it does not solve

Say the quiet part: a standard is not a budget line. Belgium forked an entire government messaging stack and met its AGPL obligations to the letter, and the fork still needs a maintenance budget that nobody has committed — that story ended with the upstream vendor publicly asking to be paid. Standards and blueprints do not fund merges, security releases, or the person on call. SCS is maintained by its member organizations; Haven by the VNG and municipal IT shops that run it; the Dutch design explicitly leaves governance, funding, and procurement to a later phase — which is exactly where the previous post's failure mode lives.

Also: "binding" binds German administrations. The Dutch review is Dutch process. The value for everyone else is not that these documents govern you — they don't — it is that two governments paid to produce sovereign reference material and then published it. Compare that to the sovereignty-washing pattern in the private sector: a hyperscaler rebrands a region "sovereign," or a Palantir/Nebius partnership rebrands a closed perimeter as sovereign AI. Nobody publishes the authorization layer's blueprints, because the blueprints are the product. Public money producing public, inspectable documents is the opposite move, and it is the reason these two stories belong on an infrastructure blog rather than a policy one.

Sovereignty you can read

The Germany Stack tells its public sector what a sovereign cloud must conform to. The Netherlands shows its public what one looks like and lets them file comments. Both treat auditability as the product, not the press release.

For a fire hall, a co-op, a small business, or a city IT department: you will never have the budget of either government, and you do not need it. You need a stack you can name, standards you can check against, and designs you can read. Those now exist in the public domain, one layer down from the slogans, where the work happens.

Government cloud projects die when the design documents are classified and the standards are whatever the incumbent shipped last. These two are neither. Read them.