The Dutch Government Is Building a Microsoft Alternative on NixOS: What National-Scale Self-Hosting Signals for Teams Who Own Their Stack

In February 2025, the chief prosecutor of the International Criminal Court lost access to his Microsoft email. The United States had imposed sanctions on the ICC prosecutor, and the mailbox that went dark reportedly held sensitive evidence, witness testimonies, and confidential material for active investigations. By October 2025, the Court — some 1,800 workstations — had moved to European open-source software. The Dutch government watched all of this happen in The Hague, its own backyard, and drew the obvious conclusion: essential services that depend on decisions made in another country are not really yours.

Its answer is DAWO, short for Digitaal Autonome Werkomgeving Overheid — the Digital Autonomous Government Work Environment. It is a sovereign workplace built on NixOS, covering the operating system, an office suite, collaboration apps, cloud services, IT management tools, and AI. The story broke widely on September 25, 2026, when a Hacker News thread on the Dutch project drew hundreds of comments, and it deserves a careful reading rather than a cheer. There is a real pilot, a real mandate, and a real technical reason NixOS was chosen — and there is a precise lesson in it for any team running its own platform, which is this post's actual subject.

Here is the verdict up front, so the recap that follows has somewhere to land: the sovereignty property the Dutch are buying is not "Linux instead of Windows." It is "the whole system is declared in config" — reproducible, versioned, rollback-capable, with no vendor able to change the terms underneath a running machine. That is the same property a self-hosted PaaS fleet wants from its node images and machine lifecycle one level down. But the correct scope of that bet for a fleet is narrower than the Dutch desktop bet: declarative, reproducible node images and machine configs, where a purpose-built immutable OS like Talos Linux is usually the better tool than NixOS-everywhere. The rest of this post substantiates both halves of that claim.

What DAWO actually is: mandate, scope, and pilots​

Start with what is verifiable, because "government switches to Linux" stories have a long history of outrunning their facts. According to Dutch technology publication Tweakers, whose behind-the-scenes look at the project drove this week's coverage, DAWO is already deployed on a small scale inside Dutch government bodies, where officials are testing it on everyday work. In one participating municipality, the city council itself is part of the pilot — not just the Linux enthusiasts and security specialists.

The institutional backing is concrete. In July 2026, the Interdepartmental Commission for Government Business Operations (ICBR) issued a directive for a standardized, sovereign digital work environment, making DAWO an official government mandate rather than a skunkworks experiment. Eight municipalities are testing the environment through a pilot run with the Association of Netherlands Municipalities, and an earlier April 2026 pilot put a Linux workplace plus the MijnBureau environment in front of users in Amsterdam, Ede, Zaanstad, and 's-Hertogenbosch. The work is happening in the open: dawo-core on GitHub documents a two-phase install from bare device to DAWO workstation using nixos-anywhere, the standard NixOS remote-install tool.

The scope is what separates this from a distro swap. DAWO's blueprint covers the OS, an office suite, collaboration apps, cloud services, management tooling, and AI — the full digital workplace, built from replaceable open-source components so no single vendor sits in the critical path again. And the choice of NixOS was explicitly a sovereignty decision: as It's FOSS put it, NixOS was chosen because it is a Dutch project with no company owning or controlling its development. There is no vendor board that can be pressured, acquired, or sanctioned into changing what the OS does.

One honesty note before moving on. In February 2026, Microsoft's senior director for corporate, external and legal affairs told the UK House of Commons that the ICC — not Microsoft — decided to suspend the prosecutor's email account amid the sanctions, and that the company "worked with the ICC throughout." Take that dispute seriously and the sovereignty lesson survives it intact: whether the off-switch is pulled by the vendor or forced onto the customer, the risk is the dependency on a provider subject to a foreign jurisdiction. The Dutch bet is against the dependency, not against any one company's telling of one incident.

The scope question, answered: NixOS-everywhere is a desktop answer, not a fleet answer​

This is the section the title promises, so it comes before the mechanism deep-dive: what should a team running its own PaaS fleet actually copy? The Dutch are declaring an entire interactive workplace — desktop environment, office suite, per-user configuration — where NixOS's generality is the point. A fleet operator's problem is narrower and harsher: dozens or hundreds of machines that must be identical, unattended, and cheap to reason about at 3 AM. Copying the tool without translating the scope is how you end up running a desktop distro's flexibility on machines that needed an appliance.

Put the two candidates side by side at node scope:

The table is not anti-NixOS. NixOS on nodes is a legitimate choice — its store model gives you reproducibility proofs Talos answers with image immutability instead — and teams already fluent in Nix get a single language from laptop to fleet. But notice what each row costs at fleet scale. Every interactive affordance NixOS keeps (a shell to debug with, a package manager to hotfix with) is a drift vector across N machines that a controller must then reconcile away. Talos deletes the vector: there is no way to hand-edit a node, so "the production environment matches the manifest" holds by construction rather than by discipline. For the SNCF-style zero-drift posture — monthly forced reconciliation of every cluster to its declared state — the OS that cannot drift is doing half the reconciliation for you.

So the translated bet is: declare the machine, not just the workload. Cluster API machine manifests versioned in git, node images built reproducibly and pinned by digest, provider versions treated as a supply-chain question (the ORAS-as-OCI-artifact pattern, not a clusterctl URL floating at latest). Whether the image bytes come from Nix or Talos matters less than that the bytes are a pure function of checked-in config and that no human or vendor can perturb a running machine outside that pipeline. That is the Dutch property, at fleet scope, with the desktop generality correctly left behind.

Why "declared in config" is the sovereignty property — and how Europe-wide the pattern is​

Why does declarative configuration equal sovereignty, technically? Three mechanisms, all of which NixOS happens to embody and all of which a fleet should demand from its own stack regardless of distro.

First, reproducibility: Nix builds every package into a content-hashed store path, so a given configuration expression yields bit-identical system state on any machine, at any time. Reproduce the config, reproduce the system — which means an auditor, a second supplier, or your own future self can verify that what runs is what was declared, with no vendor-side mutation possible between declaration and deployment.

Second, atomicity with rollback: NixOS upgrades switch the whole system to a new generation atomically, and the previous generation stays bootable. A bad update is a reboot away from undone. Compare that to the modal enterprise upgrade — a stateful, partially-reversible mutation applied by a vendor's agent — and the sovereignty content is clear: the operator holds the rollback, not the supplier.

Third, no privileged vendor channel: a system fully described in your own config has no component that only the vendor can change. No license server that can revoke, no forced-update channel that can rewrite behavior, no telemetry-gated feature flag. The Dutch requirement — no foreign entity can change the terms underneath a running system — is exactly this row, and it is a property of the architecture, not of any vendor's promises. A vendor can pledge good behavior; only your own config can make misbehavior structurally impossible.

The Dutch are not alone in drawing this conclusion; they are the newest and most technically ambitious entry in a 2025–2026 European pattern:

Read the table as a market signal, not just politics. Every row is a large buyer deciding that vendor-controlled infrastructure is a liability class of its own — alongside cost, alongside features — and paying real migration money to exit it. When governments pay a ~€9M migration bill to save €15M a year and recover control, the "just use the managed suite" default has lost its unexamined status. Self-hosting teams should notice who is validating their model: not hobbyists, but states with auditors.

What to do Monday morning​

The Dutch project will take years; your fleet can move this week. Concretely:

1. Pin your node images by digest and build them from checked-in config. If you cannot rebuild today's node image from git tomorrow, you have the pre-DAWO problem at fleet scope. NixOS image builds and Talos factory images both satisfy this; a hand-baked AMI does not.
2. Version every machine manifest. Cluster API Machine/MachineDeployment specs, Talos machine configs, cloud-init — all in git, all applied by automation, none hand-edited. Treat "someone SSH'd a fix onto a node" as an incident, or run an OS where it is impossible.
3. Treat provider and component versions as supply chain. Pin CAPI provider versions, distribute them as versioned artifacts, and verify signatures. "Latest" is a vendor-controlled channel wearing an open-source costume.
4. Keep the rollback you already paid for. Atomic generations (NixOS), A/B partitions (Talos), blue-green node pools (either) — verify the rollback path exists before the upgrade that needs it, and rehearse it on a staging pool.
5. Audit your own off-switches. List every component a foreign vendor can revoke, reprice, or rewrite under you — license servers, SaaS control planes, unpinned container tags — and rank them the way The Hague now ranks email: by what goes dark if the terms change.

The forward-looking point is the one the HN thread kept circling: DAWO's real bet is that declarative, reproducible, vendor-independent systems are operationally superior, not merely politically preferable. Reproducibility kills "works on my machine" at national scale; atomic rollback kills the failed-upgrade outage; config-as-truth kills drift. Those are the same properties that make a two-person team able to run a fleet that used to need a department. Sovereignty and operability turn out to be the same engineering — declared systems you can rebuild, roll back, and reason about — sold to a parliament in one register and to an on-call rotation in another.

A government just validated the architecture your fleet already wants. Build like it.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.