NixOS is a good server OS, except when it isn't

Original Article ↗ Hacker News Discussion ↗

Efforts to slim NixOS for tiny server and micro-VM use highlight both its strengths—reproducible, declarative systems—and its weaknesses, such as disk footprint, RAM usage during builds, and a steep learning curve around the Nix language and tooling. Commenters trade techniques for building minimal images, offloading builds to more powerful hosts, and reusing stores, while contrasting NixOS with alternatives like Alpine, Guix, Yocto, Debian, and Proxmox-based setups. A recurring theme is that NixOS can be exceptionally powerful and maintainable once tamed, but its fragmented ecosystem, short support windows, and opaque debugging make it a poor fit for some production and low-resource scenarios.

Slimming NixOS and MicroVM Use

  • Several comments praise the article’s deep dive into shrinking NixOS images, comparing it to building minimal Docker images.
  • Suggestions include: using coreutils’ single-binary mode; including only the closure of the target binary and kernel; and borrowing ideas from router‑style Nix systems or projects like microvm.nix and not‑os.
  • One approach is to share or snapshot /nix/store across many VMs (virtiofs, ZFS clones, NFS), trading isolation for space efficiency.
  • Some are interested in “scratch-like” NixOS VMs and immutable live systems built from custom installer ISOs.

Nix Language, Debugging, and Tooling

  • Strong split in opinion: some find Nix “pleasant,” a good JSON-with-functions DSL; others find it opaque, full of sugar/idioms, and hard to debug.
  • Pain points: poor typing, discoverability of options/symbols, lazy evaluation making errors obscure, and non-obvious defaults (e.g., service auto-enabling).
  • Mitigations mentioned: REPL (nix repl, nix-instantiate), Nix LSPs (nil, nixd), search.nixos.org, and better structuring for REPL‑friendliness.
  • Alternatives discussed: Nickel (typed Nix-like), Guix/Scheme, jsonnet, Pulumi/Terraform-style declarative APIs. No consensus “better” replacement emerges.

Deployment Models and Resource Constraints

  • Nix builds can be RAM-heavy; suggested workaround is remote builds: evaluate/build on a beefier machine, then nix copy/nixos-rebuild --target-host or similar workflows.
  • Some use central build/caching servers, netboot minimal NixOS, then kexec into the desired system.
  • Others prefer using NixOS only for VMs on top of Proxmox/Debian, or abandon NixOS entirely for Proxmox + bash/Ansible setups.

Stability, Releases, and Security

  • Debate over NixOS as a “server OS”: critics cite lack of long LTS (roughly 7–9 months of backports per release vs. Debian/Ubuntu’s years).
  • Supporters argue upgrades are much safer and easier to roll back, making 6‑monthly upgrades acceptable.
  • There is mention of a security team and release channels, but some remain unconvinced compared to traditional LTS distros.

Ecosystem, Docs, and Direction

  • Repeated complaints: steep learning curve, sparse/fragmented documentation, many side projects and patterns with no clear “blessed” path.
  • Others see the breadth of tools (nixos-generators, nixos-anywhere, deploy-rs, agenix, OCI image building) as evidence of a mature, powerful ecosystem.