NixOS

NixOS is the foundation almost everything else here sits on. The machine is described in a file; nixos-rebuild switch makes the machine match the file.

Why we still choose it

Because most infrastructure problems are archaeology problems. Nobody knows why that package is installed, who added that cron job, or whether staging matches production. NixOS collapses the machine and its description into one thing, so there is nowhere for drift to live: anything not declared is not present after the next rebuild.

The practical consequences are large. Staging is genuinely identical to production rather than built from the same recipe. A bad upgrade is a reboot into the previous generation, which is still on disk. dry-activate tells you exactly which units will restart before you commit. And an auditor’s question about what a server looked like on a particular Tuesday is answered with git log rather than a guess.

How we run it

One repository per client, one file per machine, secrets with sops-nix or agenix, and infrastructure changes through pull requests like application code. Deploys target hosts over SSH; nothing needs an agent running on the box.

The honest limit

The learning curve is real and the talent pool is small — this is the objection we take most seriously, and it is why handover documentation is half of what we deliver. Documentation is uneven, and vendor software that expects a traditional filesystem layout needs wrapping. For a single server that changes twice a year, a well-documented Debian install is a defensible answer.