Explore the author's migration from Proxmox to NixOS and Incus, highlighting the advantages of declarative systems.
I have officially decommissioned my Proxmox cluster. After years of running my homelab on Proxmox—starting with a single NUC and eventually expanding to a multi-node cluster—I have migrated everything to NixOS running Incus.
This transition marks a significant change in how I manage my startups/">investment-in-ai-data-centers-in-france/">infrastructure, offering profound insights into the benefits of a declarative system.
I wasn’t always a Nix evangelist. In fact, my initial impressions were quite negative. I had difficulties grasping the language and its syntax. I relied heavily on my established methods for setting up dotfiles, using tools like Dotbot for symlinking and my own creation, dotbins, for managing binaries.
Although I dabbled with nix-darwin on my Mac for a while, it was solely for managing Homebrew packages and settings. My true conversion came after purchasing a gaming PC, as noted in my local LLM post.
Initially, I installed Pop!_OS to avoid Windows during my gaming sessions. However, I encountered consistent NVIDIA driver issues that required me to execute random, imperative commands for solutions. This felt entirely inadequate, as recreating those debugging steps proved nearly impossible, leading to an eventual GRUB boot loop due to a botched NVIDIA driver update.
Frustrated, I turned to NixOS. I hoped its promise of atomic updates would offer a better solution, and it did more than I expected. After migrating my system to a new disk without cloning, my Nix configuration managed to provide a byte-for-byte equivalent. The successful migration was my breakthrough moment in trusting declarative systems.
Proxmox is indeed powerful software. It lowered the barrier to entry and taught me a significant amount about virtualization, ZFS, and LXC containers. However, Proxmox fundamentally operates within a GUI-first paradigm. While it allows for automation through tools like Terraform or Ansible, I often felt like I was grappling with the software.
The reality of state drift was a massive concern. A UI change for debugging could lead to confusion down the line, leaving my infrastructure out of sync. This is particularly problematic in environments that deploy AI agents. Introducing agents operating in "YOLO mode" can lead to chaotic results, executing numerous imperative commands that may succeed but ultimately create an undefined and unreproducible state.
This friction extends into hardware management as well. For instance, I experienced issues with the Intel I219-LM network card on my HP EliteDesk. Previously, I managed to remedy the problem on Proxmox, but the fix was lost in the annals of history.
Upon setting up NixOS, the network issue resurfaced. However, this time, the fix was easily accessible through a documented systemd service in my configuration. I added comments explaining the necessity of disabling TSO and GSO, including forum citations. If I need to reinstall, the fix applies automatically. Under Proxmox, I would have been forced to rediscover the solution.
Similarly, my Intel NUC served as a test case. As my homelab resides behind my TV, I wondered if I could repurpose it into a Home Theater PC (HTPC). In Proxmox, this would have required GPU passthrough, restricting GPU access to the host. The dilemma was stark: either use the hardware as a media player or maintain a debuggable hypervisor. The process was frustrating enough that I eventually reverted. By contrast, with NixOS, I run Kodi directly on the host OS, enjoying hardware acceleration while Incus manages my containers in the background. The result? A dual-purpose setup without the overhead of virtualization or the limitations typical of headless hosts.
There’s also a philosophical shift at play. Proxmox or TrueNAS function somewhat as appliances, discouraging arbitrary command execution on the host. Straying into package installation or config tweaks could compromise middleware or lead to configuration losses during upgrades. This appliance model restricts access to the hardware’s potential.
With NixOS, I reclaim full control. I can freely install Kodi, tweak network drivers, and manage local models without concern. The declarative state format ensures everything is obvious and reproducible. I might break my host configuration, yet I can recover swiftly, even while essential services are running.
My prior discussions on agentic coding detail the importance of CLI-first and declarative systems. In a landscape increasingly dominated by AI agents, these tools reign supreme. Agents cannot efficiently navigate GUIs to execute configurations; they require deterministic, text-based inputs.
By transitioning to NixOS, my whole infrastructure is defined via text files, allowing AI agents to read, comprehend, and modify my setup safely. Proxmox’s opaque database and interface hinder agent interactions. In contrast, NixOS is accessible and transparent. For example, when directing an agent to deploy a Faster Whisper API server, it doesn’t need to navigate complex menus; it merely interacts with systemd service definitions, coupled with straightforward firewall configurations.
A friend who has long used NixOS praised the structure of my configurations, especially while managing eight different machines. Most of the setup has relied on agentic AI; I practically didn't write any of my configuration from scratch. This automated process allowed me to evolve from one to nine machines effectively. The AI simplifies structural changes, ensuring that my desktop, NUC, and HP share common modules while still accommodating unique requirements.
Although I desire a purely Nix-based solution for managing persistent, stateful LXC containers and VMs, existing projects like nixos-containers and microvm.nix often lack operational maturity. Thankfully, Incus, a community fork of LXD, adeptly fills this gap by offering seamless management.
Incus provides a “cattle” management approach for the host while supporting “pet” legacy workloads such as old Ubuntu containers or Home Assistant VMs in a stable environment. Additionally, Incus benefits from comprehensive command-line control, aligning perfectly with my agentic workflow.
Over time, I had transitioned many legacy LXC containers—such as those running DNS and media management—into declarative Docker Compose files nested within VMs. However, Home Assistant OS remained a holdout due to its reliance on a dedicated appliance OS.
I eventually learned that Incus running on NixOS could effortlessly manage a full VM for Home Assistant, simplifying the process to just another QEMU instance handled like any other container. I even set up Incus VMs to replicate configurations of my physical machines, ensuring everything functioned as intended before shutting down my last Proxmox host.
This level of validation instilled the confidence to transition my physical servers without the fear of failure.
What might seem like a daunting task turned out quite straightforward, thanks to tools like vzdump and qemu-img. Here’s a detailed account of how I preserved over seven years of digital history without data loss.
I maintained substantial migration notes within my dotfiles to assist anyone seeking a similar transition. Leveraging AI, such as Gemini 3 Pro, can simplify the process further.
For my LXC containers, the migration felt like teleporting them. I created a standardized tarball from the running container on Proxmox, transferred it, and seamlessly streamed it directly into a fresh Incus container.
As for VMs, especially Home Assistant OS, converting the disk format was key. Proxmox often employs LVM-thin or ZFS zvols, while Incus accepts formats like QCOW2 or raw ZFS.
All relevant configuration files referenced throughout this article are accessible via my dotfiles repository, providing further support for those interested in replicating my migration experience.