Post

Why I replaced my clickable hypervisor with declarative text files

I have officially decommissioned my Proxmox cluster. After years of running my homelab on Proxmox, starting with a single NUC and expanding to a multi-node cluster, I have migrated everything to NixOS running Incus.

I wasn’t always a Nix evangelist. In fact, I initially despised the language and its syntax. I couldn’t figure out how it worked, and I already had my own specific way of setting up my dotfiles. I used Dotbot for symlinking and a tool I wrote called dotbins for managing binaries. I didn’t feel like I required Nix for most of my tools. I used nix-darwin on my Mac for a long time, but only to specify Homebrew packages and application settings.

My true conversion happened when I bought my gaming PC, as described in my local LLM post . I initially installed Pop!_OS because I wanted to play games and absolutely wanted to avoid Windows. I got some games to work, but I constantly ran into NVIDIA driver issues that required running random, imperative commands to fix. I felt that was a bad solution because I could never reproduce those debugging steps later. Then I did the dumb thing of updating my NVIDIA drivers, not realizing that imperatively managing driver versions and repositories is a recipe for disaster, and got stuck in a GRUB boot loop. Frustrated, I installed NixOS, hoping its promise of atomic updates would solve this. The result was glorious. I never really believed that everything would be byte-for-byte equivalent until I migrated that system to a new disk. I didn’t clone the drive; I just applied my Nix configuration to a fresh install. It booted, I copied my data, and everything was identical. That was the moment it clicked.

Proxmox is fantastic software. It lowered the barrier to entry for me and taught me almost everything I know about virtualization, LXC containers, and ZFS. But fundamentally, Proxmox is built around clicking buttons . It is a GUI-first paradigm. While you can automate it with Terraform or Ansible, it often feels like fighting the tool. State drift is real. You change a setting in the UI to debug something, forget about it, and six months later your “infrastructure as code” is out of sync with reality. For a human maintaining a system manually, this is annoying. But when you introduce AI agents, this becomes a disaster for the operator. An agent running in “YOLO mode” might execute hundreds of imperative commands to fix a problem. It might succeed, but it leaves your system in an undefined, unreproducible state that no one—not even the agent—can fully understand or replicate later.

This friction manifests in hardware management too. On my HP EliteDesk, the Intel I219-LM network card has a known bug where it hangs with hardware offloading enabled. I vaguely remembered fixing this years ago on Proxmox, but I had forgotten the details. When I set up NixOS, I ran into the same issue: the network would randomly drop. This time, however, the fix isn’t a forgotten command run in a root shell history. It is a documented systemd service in my configuration. I added a comment explaining exactly why tso off gso off is needed, citing the forum threads. If I ever reinstall this machine, the fix applies automatically. On Proxmox, I would have had to rediscover this pain all over again.