NixOS: another way to run Linux

When organisations talk about Linux, they usually mean Debian, Ubuntu or RHEL: systems you install, update package by package, then keep aligned with Ansible, Puppet or golden images. NixOS lives in the same Linux world, but it changes the central question. Instead of “how do we keep this machine healthy over time?”, it asks “how do we describe the desired state so the machine reaches it, identically, every time?”

This is no longer a niche topic. In France, DINUM is building on that model with Sécurix and Bureautix, progressively moving its internal workstations to a Linux environment based on NixOS. The announced scale is about 250 staff workstations after earlier pilot phases. Other public bodies (Gendarmerie, DGFiP and others) already have long Linux experience; here the point is how the fleet is managed, not only which desktop is chosen.

For an organisation, the stakes look familiar: reproducible, auditable and reversible servers and workstations, without relying on tribal knowledge or machine-by-machine history.

Two ways to run a Linux machine

On a classic distribution, the familiar path looks like this:

• install packages;
• edit configuration files;
• start services;
• then automate with configuration management to limit drift.

It works. It is battle-tested. But a machine’s real state is still partly the product of its history: update order, manual fixes, forgotten packages, local exceptions. Two servers that look identical on paper can diverge. Ansible and similar tools reduce the gap; they do not remove it by design.

NixOS flips the priority. The system is declarative and deterministic: the configuration describes the target state, and nixos-rebuild brings the machine there. Two machines fed the same configuration converge to the same result, much like two CI builds from the same commit.

A useful comparison:

Both can coexist in an organisation. NixOS becomes interesting when fleet homogeneity and the ability to roll back matter more than immediate familiarity with apt / dnf.

Declarative configuration: describe, then apply

As with infrastructure as code, you centralise the desired state in files (often configuration.nix, extended with modules):

{
  services.nginx.enable = true;
  users.users.admin = {
    isNormalUser = true;
    extraGroups = [ "wheel" ];
  };
}

Then you apply:

nixos-rebuild switch

Where Debian often means apt install, file edits and service restarts, here one operation moves the system toward the description. It is not magic: you still learn the module language. The outcome, though, is no longer an approximation built from successive manual interventions.

The Nix store: what `/usr` does differently

On a classic distro, packages share common paths (/usr/lib, /usr/bin). That is convenient day to day; it also creates version conflicts and “works on my machine” surprises.

With Nix, built artifacts live in /nix/store. Each entry is:

• immutable once built;
• hash-addressed, the path encodes its dependencies;
• isolated, so two versions of the same software can coexist.

Example: /nix/store/…-nginx-1.24 next to another nginx generation. Think of virtualenvs or container images, applied to the whole system rather than a single app.

Derivations: recipes instead of opaque packages

Each Nix package is a derivation: a recipe with explicit dependencies and a reproducible build. Conceptually: source + dependencies + build script → immutable result in the store.

For an IT team or integrator, the useful parallel is a build pipeline: you can rebuild, audit and hand over an environment with the same discipline you already apply to application code.

Native rollback: the safety net classic distros improvise

On a classic Windows or Linux fleet, undoing a bad update often means restore images, hypervisor snapshots or a full rebuild. NixOS builds in generations: every nixos-rebuild switch creates one.

If something goes wrong:

nixos-rebuild switch --rollback

You can also pick a previous generation at boot (GRUB). In production, the gain feels closer to a blue/green deploy or release rollback: fix a regression in minutes without reconstructing yesterday by hand.

Modules, Nixpkgs and Home Manager

NixOS modules

Like Ansible roles or manifests, NixOS exposes modules (network, firewall, nginx, PostgreSQL, SSH, accounts…). You declare intent; the system generates the effective configuration. The difference: the same declarative model covers everything from the kernel to services.

Nixpkgs

Nixpkgs is one of the largest Linux package sets. The value is not only volume: coexisting versions, custom overlays, reproducible builds. With flakes, configuration and dependencies are pinned in a flake.nix, which again feels like versioning infrastructure as code (lab, staging, production).

Home Manager

For the user layer (shell, dotfiles, Git, IDE), Home Manager applies the same philosophy to workstations. On a classic fleet you often combine GPOs, login scripts and golden images; here the user desktop can be described with the same rigor as the server.

Why the public sector (and others) care

NixOS is not only for labs. As soon as you need to industrialise deployments, harden environments, reduce drift between machines or recover faster after incidents, the declarative model becomes an operational argument, not only a technical one.

That is the frame for Sécurix and Bureautix in the cloud-gouv / DINUM ecosystem:

Sécurix (hardened base)

• fully declared, auditable configuration;
• store immutability and fast rollback after incidents;
• fewer gaps between machines in the same fleet;
• security-oriented hardening (ANSSI-style guidance, depending on the project).

Bureautix (managed workstation)

• homogeneous workstation deployment from a definition;
• faster onboarding: a workstation becomes a description, not a long manual install;
• business / office layer on top of the base, beyond sysadmin-only use cases.

Rolling out around ~250 internal DINUM workstations does not mean the whole administration switches overnight. It shows a major public actor testing and deploying NixOS where fleet control and software sovereignty matter. For organisations watching this move, the goal is not to “become DINUM”, but to be able to fork and adapt these building blocks to their own context.

A model shift, without throwing everything away

Adopting NixOS is not swapping one distro for another of the same kind. It is accepting a different contract:

• you version an explicit description of the system;
• you rebuild and roll back with software-delivery discipline;
• you keep classic Linux skills where they still apply: the kernel, networking and services remain familiar; what changes is how they are assembled.

At HeBeKo, we explore and use this approach for deployment and operations of open source infrastructure (NixOS, Keycloak, Nextcloud, Ansible and Terraform), and we help organisations assess what Sécurix / Bureautix can bring once adapted to their fleet.

Go further

• NixOS training (3 days): administration, flakes, secrets, multi-machine deployments.
• Our services: audit, migration and managed services on open source stacks.
• Get in touch to discuss your context. We reply within one business day.