Technical

Why NixOS

The core bet is declarative over imperative. NixOS configuration is code. The entire system state is defined in .nix files, not accumulated through a history of manual commands and forgotten tweaks.

This matters for several reasons:

Cross-machine consistency

NixOS configurations carry across machines. The same module definitions work on a VPS, a laptop, or a new host. Shared config lives in a common directory, host-specific config in per-host directories. Spinning up a new machine means importing the shared base and adding hardware-specific overrides, not re-discovering and re-running a sequence of setup steps.

Atomic, rollbackable changes

Every system change is a discrete, atomic deployment. If something breaks, the previous generation is one boot menu entry away. This encourages experimentation because the cost of trying something is low and reverting is trivial.

LLM-accessible control surface

This is the increasingly important one. Because the entire system is defined in structured, readable code:

• LLMs can read and understand the full system state: no need to run diagnostic commands or parse scattered config files. The .nix files are the source of truth.
• LLMs can propose and make changes: modifying infrastructure is a code edit, reviewable in a diff, not a sequence of shell commands with side effects.
• Iterative improvement becomes natural: each conversation with an AI can produce a commit that incrementally improves the system. The configuration grows more robust over time through accumulated small improvements.

This is infrastructure as code in the strongest sense: not just deployment scripts, but the system itself defined as a pure function of its inputs.

Durability

The configuration is version-controlled, backed up, and self-documenting. If the server disappears tomorrow, rebuilding from the repo gets back to the exact same state. No tribal knowledge, no “I think I also installed X and changed Y.”