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. With declarative configuration the answers are in the file.
- 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 usually get a story rather than 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.
None of this comes from incompetence. It happens in any system where the machine's state and the description of that state are separate things, kept in sync by discipline alone.
NixOS merges the two, so the file is the machine. Anything not in the configuration is gone from the system after the next rebuild, so there is no drift to detect.
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 rather than what looks good in a demo.
01 Staging matches production
Staging and production run the same closure, byte for byte, down to the libc, which is a stronger guarantee than “built from the same playbook”. That removes the whole class of “it worked in staging” problems, and the class is much larger than most teams admit.
02 Rollback is a reboot
Every previous generation stays on disk and appears in the boot menu. A bad upgrade at 02:00 means rebooting into the last known-good system instead of spending an hour restoring from backup.
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 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 becomes a command instead of a document nobody has rehearsed.
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 are all answered from history rather than from memory, so the auditor gets evidence instead of 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” bugs go away.
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 |
| Talent pool | Large | Small, which is the downside |
Nackdelar · The downsides
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 steep. The Nix language is unusual, and its error messages have historically been unhelpful. Budget weeks rather than afternoons for a team meeting it for 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 and missing 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 can be awkward. Anything that expects a traditional filesystem layout, or ships a binary installer that writes to
/usr, needs wrapping, which is usually possible and 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.
NixOS pays off most 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.