03 Systems & networks
NixOS
The whole machine described in one file, built identically every time, rolled back in one reboot.
- Role
- Operating system
- Licence
- MIT / LGPL
- Since
- 2007
- Upstream
- Project site ↗
Almost everything else here runs on NixOS. The machine is described in a file,
and nixos-rebuild switch makes the machine match the file.
Why we still choose it
Most infrastructure problems turn into archaeology. Nobody knows why a package is installed, who added a cron job, or whether staging matches production. NixOS makes the machine and its description the same thing: anything that is not declared is gone after the next rebuild, so the two cannot drift apart.
This has large practical consequences. Staging is identical to production, not
just built from the same recipe. A bad upgrade is fixed by rebooting into the
previous generation, which is still on disk. dry-activate tells you which
units will restart before you commit. When an auditor asks what a server looked
like on a particular Tuesday, git log answers the question.
How we run it
Each client gets one repository with one file per machine. Secrets are handled with sops-nix or agenix, and infrastructure changes go through pull requests like application code. Deploys reach hosts over SSH, so there is no agent running on the box.
Where it falls short
The learning curve is real and the talent pool is small. We take that objection more seriously than any other, and it is why handover documentation makes up half of what we deliver. The upstream documentation is uneven, and vendor software that expects a traditional filesystem layout has to be wrapped. For a single server that changes twice a year, a well-documented Debian install is a defensible choice.