Migrating from Proxmox to NixOS and Incus

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. Another example is my Intel NUC. Since my homelab lives behind my TV, I wondered if I could also use it as a Home Theater PC (HTPC). On Proxmox, this would have required passing the GPU through to a VM to get video output. But doing so would mean the Proxmox host loses access to the GPU entirely, meaning no local console if things go wrong. It was a strict trade-off: either a media player, or a debuggable hypervisor. I tried it, but it was so much trouble that I quickly reverted. With NixOS, I don t have to choose. The host OS runs Kodi directly, giving me native hardware acceleration and video output. Simultaneously, incus runs in the background, hosting my containers. I get my HTPC and my server on the same metal, without the virtualization tax or the headless host limitation. There is a deeper philosophical difference too. Systems like Proxmox or TrueNAS are designed as appliances. You aren t supposed to run arbitrary commands on the host; installing packages or tweaking config files is discouraged because you might break the middleware or lose changes on upgrade. You are effectively locked out of your own hardware s full potential. With NixOS, the host is fully mine. I can mess with it—installing Kodi, tweaking network drivers, running local LLMs—without fear. Because the state is declarative, it is 100% obvious and reproducible. I can break the host configuration and recover to a working state in seconds, even if the machine is running essential services. I have written before about my shift towards agentic coding. In a world where AI agents execute tasks, CLI-first and declarative systems are king. An AI agent cannot reliably c

Migrating from Proxmox to NixOS and Incus

Key takeaways

More in computer-science