04 Module · Why NixOS
The end of
server archaeology.
Most infrastructure problems are archaeology problems. Nobody knows why that package is installed, who added that cron job, or whether staging matches production. Declarative configuration ends the digging.
- First released
- 2003 (Nix) · 2007 (NixOS)
- Model
- Purely functional
- Rollback
- One reboot
- Licence
- MIT / LGPL
Ask a team how their production server got into its current state and you will get a story, not an answer.
Somebody ran apt install during an incident in 2021.
Somebody else edited a config file directly and meant to put it back.
The configuration-management tool covers about seventy per cent of the
box, and nobody is quite sure which seventy. Staging was built from the
same playbook eighteen months ago and has drifted since.
This is not incompetence. It is the natural entropy of a system where the machine's state and the description of that state are two different things that are expected to stay in sync by discipline alone.
NixOS collapses the two. The file is the machine. There is no drift to detect, because there is nowhere for drift to live: anything not in the configuration is not on the system after the next rebuild.
Argumenten · The case
Seven reasons,
in order of how often they matter.
Ranked by what you notice in the second year of running a fleet, not what impresses in a demo.
01 Staging genuinely matches production
Not “built from the same playbook” — the same closure, byte for byte, down to the libc. The entire class of “it worked in staging” disappears, and it is a much larger class than anyone admits.
02 Rollback is a reboot
Every previous generation stays on disk and appears in the boot menu. A bad upgrade at 02:00 is a reboot into the last known-good system, not a restore from backup and an hour of adrenaline.
03 Changes are reviewable before they happen
dry-activate tells you exactly which units will restart and what will change. Infrastructure changes go through pull requests like application code, because they are diffable in the same way.
04 No drift, by construction
There is no partial coverage. Anything not declared is not present after a rebuild, so the honest answer to “what is installed on that box?” is “read the file” rather than “let me log in and look”.
05 A new machine is a copied file
Adding a second region, replacing dead hardware or spinning up a per-client environment is an editing task. Disaster recovery stops being a document nobody has rehearsed and becomes a command.
06 Auditors get git log
Who changed the firewall, when, who approved it, and what the machine looked like on the day of the incident. Answered from history rather than from memory — which is the difference between evidence and testimony.
07 Developer environments come free
The same expressions that build the server build a shell with the exact toolchain. New engineers are productive on day one, and “works on my machine” stops being a category of bug.
Jämförelse · Side by side
Against the usual approach
Compared with a hand-built machine under Ansible or Puppet, which is what we most often find when we arrive.
| Concern | Imperative config management | NixOS |
|---|---|---|
| Model | Steps that converge, mostly | A description that is realised |
| Drift | Detected, sometimes, afterwards | Structurally impossible |
| Rollback | Write a reverse playbook, hope | Reboot into the previous generation |
| Staging parity | Same recipe, different result | Identical closure |
| Preview a change | A --check run that lies a little | dry-activate, exact |
| Partial application | Half-applied states are normal | Atomic switch, or nothing |
| Secrets | Vault plus a lot of glue | sops-nix or agenix, in the repo |
| Learning curve | Gentle | Steep, and genuinely so |
| Talent pool | Large | Small — the honest disadvantage |
Ärligt talat · Honestly
When NixOS is the wrong answer.
NixOS asks more of a team than any other choice on this site, and we would rather talk you out of it than hand over something nobody wants to maintain.
- The learning curve is real. The Nix language is unusual, and the error messages have historically been unkind. Budget weeks, not afternoons, for a team meeting it the first time.
- The talent pool is small. Hiring someone who already knows Nix is harder than hiring someone who knows Ansible. This is the objection we take most seriously, and the reason handover documentation is half of what we deliver.
- Documentation is uneven. Excellent in places, absent in others. The answer is often in the source of a module, which is fine for us and frustrating for a team learning alone.
- Vendor appliances fight back. Anything that expects a traditional filesystem layout, or ships a binary installer that writes to
/usr, needs wrapping. Usually possible, occasionally not worth it. - One or two servers may not justify it. The payoff scales with fleet size and rate of change. For a single box that changes twice a year, a well-documented Debian install is a defensible answer and we will say so.
The case is strongest from roughly five machines upward, for teams that deploy regularly, and anywhere an auditor will eventually ask what a server looked like on a particular Tuesday.