HN Debrief

Migrating from Proxmox to NixOS and Incus

  • Infrastructure
  • Open Source
  • Developer Tools
  • AI

The post is a personal migration story from Proxmox to NixOS and Incus. The author’s core claim is not that Proxmox cannot be automated, but that they wanted the hypervisor host, networking, and supporting services rebuilt from text files under version control with minimal drift. Incus supplied containers and VMs, NixOS supplied the declarative host, and that combination felt safer for experimentation, agent-driven changes, and host customization than an appliance-style platform.

If you want reproducible virtualization infrastructure, the choice is less "Proxmox versus declarative" than where you want the source of truth to live. For most teams, the practical question is whether your current Proxmox plus Terraform, Ansible, or Nix workflow already captures enough host and guest state before you take on a platform migration.

Discussion mood

Mixed but engaged. People liked the declarative-host goal and several were positive on Incus and NixOS, but many were annoyed by the article’s framing of Proxmox as GUI-first, appliance-like, and hard to automate when they already run it successfully through CLI, API, Terraform, or Ansible.

Key insights

  1. 01

    Declarative host state is the actual gap

    The useful distinction is not GUI versus CLI. It is whether the host itself can be rebuilt from version-controlled text with confidence that debugging changes did not escape the automation path. That reframes the whole migration. Proxmox can be scripted extensively, but that still leaves room for state drift on the box in a way a NixOS-managed host is designed to avoid.

    Audit where your operational truth really lives today. If host rebuilds still depend on tribal knowledge or ad hoc fixes, add host-level codification before assuming guest automation is enough.

      Attribution:
    • RossBencina #1
    • basnijholt #1
  2. 02

    Proxmox automation stops short of full infrastructure coverage

    People running large Proxmox estates said the rough edge is not VM creation. It is the uneven coverage around networking, firewalls, and broader infrastructure primitives, plus the lack of a first-party Terraform provider. That makes Proxmox workable as code, but not as complete or consistent as teams want once they move past simple guest provisioning.

    Before standardizing on Proxmox as an infrastructure-as-code platform, test the exact resources you need to manage, not just VM builds. Expect custom REST calls or provider gaps around platform-level configuration.

      Attribution:
    • cassianoleal #1
    • kube-system #1
    • mikestorrent #1
  3. 03

    Cluster features remain Proxmox’s strongest moat

    For anyone who actually depends on high availability, live migration, shared storage, Ceph integration, snapshots, and fast cloning, Proxmox still offers a more mature control plane. That comment cuts through the homelab romance. Swapping platforms to make the host prettier in Git can mean giving up battle-tested operational conveniences that matter once uptime is real.

    Map your must-have cluster operations before copying this migration. If your recovery plan depends on point-and-click HA or storage workflows, make sure Incus can replace them cleanly in drills, not just in theory.

      Attribution:
    • cromka #1
  4. 04

    Incus is broader than the post made obvious

    Incus came across as more capable than many casual readers assumed. It runs system containers, fronts QEMU and KVM for full VMs, can host Windows, and supports GPU and PCI passthrough including SR-IOV according to the linked device docs. That does not make it a drop-in Proxmox replacement, but it does make it more than a lightweight Linux-container tool.

    If you dismissed Incus as only for Linux containers, revisit the VM and device-passthrough docs. It may cover more of your workload mix than its messaging suggests.

      Attribution:
    • mindcrash #1
    • yobert #1
    • gchamonlive #1
    • scorpioxy #1
    • evanjrowley #1
  5. 05

    NixOS friction often comes from package layering

    One practical NixOS point stood out. Fast-moving user applications do not need to be pinned at the operating system layer. Home Manager and mixing a stable NixOS channel with an unstable `nixpkgs` source for selected packages is the common escape hatch. That is a concrete answer to the usual complaint that NixOS makes ordinary updates tedious.

    Separate workstation-style apps from base system state when adopting NixOS. That keeps the host stable while letting fast-moving tools update without dragging the entire system along.

      Attribution:
    • daft_pink #1
    • soraminazuki #1
  6. 06

    LLM workflows favor reversible infrastructure definitions

    The agent angle sounded hype-driven to some people, but the sharper point survived the backlash. If you are going to let an LLM touch infrastructure at all, a declarative system with versioned files, cheap rollbacks, and low-cost experimentation gives you a tighter blast radius than imperative shell sessions. Several people using Terraform or Nix with LLMs said the models still produce too much bad code, but the workflow is viable precisely because everything can be reviewed and reverted.

    Treat LLM infrastructure changes as code generation, not autonomous ops. Put them behind reviewable files and rollback-friendly systems, or do not use them for infra changes at all.

      Attribution:
    • linsomniac #1
    • h4kunamata #1
    • lmm #1
    • pxc #1

Against the grain

  1. 01

    You can keep Proxmox and still get Nix workflows

    A strong counterexample argued there is no need to migrate platforms to get most of the declarative benefits. Proxmox can stay as the virtualization target while Nix builds and deploys the guest images from a separate workstation, avoiding the GUI almost entirely. That weakens the idea that the clean path is necessarily Proxmox out, Incus in.

    Try moving your image build and deployment workflow into Nix before replacing the hypervisor. You may get reproducibility where it matters without reopening the whole platform decision.

      Attribution:
    • EnigmaCurry #1 #2 #3
  2. 02

    Terraform already scales Proxmox in practice

    Operators managing 10, 20, or hundreds of VMs said Proxmox plus Terraform is not a toy setup. It is production-capable, integrates with monitoring and configuration management, and has multiple actively used providers even if none is first-party. That pushes back on the sense that serious automation requires abandoning Proxmox.

    If you already know Terraform, benchmark provider maturity and your missing features before rewriting around Incus. The migration cost may exceed the operational gain.

      Attribution:
    • mikestorrent #1 #2
    • wingmanjd #1
    • catdog #1
  3. 03

    The article overreached on Proxmox’s limits

    Several blunt comments said the post weakened its own case by confusing an appliance philosophy with an actual lockout. Proxmox is still Debian underneath, its hosts can be customized, and many people simply avoid the GUI except for occasional convenience. That does not erase the host-drift problem, but it does mean the article sold the migration with too much caricature and too little operational nuance.

    When pitching a tooling migration inside your team, describe the current platform honestly. Overstating pain points makes the proposal easier to dismiss, even when the destination has real advantages.

      Attribution:
    • daft_pink #1
    • redlewel #1
    • h4kunamata #1
    • Rekindle8090 #1

In plain english

Ansible ↩
An automation tool that configures servers and software using playbooks written in text files.
Ceph ↩
A distributed storage system often used to provide shared block, file, or object storage across clusters.
CLI ↩
Command-line interface, a text-based way to manage software by typing commands in a shell.
HA ↩
High availability, a design approach that keeps services running despite hardware or software failures.
Home Manager ↩
A Nix-based tool for declaratively managing user-level packages and dotfiles outside the core NixOS system configuration.
Incus ↩
An open source system for managing Linux system containers and virtual machines, developed as a fork of LXD.
KVM ↩
Kernel-based Virtual Machine, a Linux virtualization technology for running virtual machines.
LLM ↩
Large language model, a type of AI system trained on massive text data to generate and analyze language.
NixOS ↩
A Linux distribution built around declarative configuration, where the whole system is described in version-controlled files and rebuilt from them.
nixpkgs ↩
The main package collection used by Nix and NixOS.
PCI passthrough ↩
A way to give a virtual machine direct access to a physical hardware device such as a GPU or network card.
pct ↩
Proxmox’s command-line tool for managing Linux containers.
Proxmox ↩
A virtualization platform used to run multiple virtual machines on one physical server.
QEMU ↩
A widely used open source machine emulator and virtualizer for running virtual machines.
qm ↩
Proxmox’s command-line tool for managing virtual machines.
REST API ↩
Representational State Transfer Application Programming Interface, a common way software exposes operations over HTTP for automation.
SR-IOV ↩
Single Root I/O Virtualization, a hardware feature that lets multiple virtual machines share a physical device more directly.
Terraform ↩
An infrastructure-as-code tool that declares infrastructure resources in files and applies them automatically.

Reference links

Incus documentation and tooling

  • Incus GPU device reference
    Used to show how Incus handles GPU assignment, including physical passthrough and SR-IOV devices.
  • incus-windows
    A helper project mentioned as an easy path to running Windows on Incus.
  • NixOS Wiki: Incus
    Cited as an example of terse documentation that leaves too many gaps for newcomers.
  • Ansible collection for Incus
    An attempt to revive automation support for managing Incus resources through Ansible.

Proxmox automation

Nix and declarative deployment examples

Alternative platforms and adjacent tools

  • Sylve
    Mentioned as a FreeBSD-based control plane for jails, bhyve virtual machines, and containers.
  • Sylve developer talk
    A talk from one of the developers, offered as a way to understand the project better.
  • vmfactory
    A simple custom provisioning tool for baking images and deploying them to Proxmox.