Quand une infrastructure virtualisée fonctionne, on la laisse tourner. C'est du moins le réflexe naturel. Mais sous la surface, les modifications manuelles s'accumulent, les correctifs urgents ne reviennent jamais dans les scripts d'automation, et au bout de quelques années, l'écart entre ce que les fichiers de configuration décrivent et ce qui tourne réellement sur les machines devient un problème concret. C'est ce constat qui a poussé Bas Nijholt à décommissionner entièrement son cluster Proxmox au profit de NixOS couplé à Incus, une migration documentée fin 2025.
Pourquoi quitter Proxmox
Le parc initial de Bas Nijholt comptait neuf machines, des NUC et serveurs physiques répartis sur un cluster multi-noeuds Proxmox. L'infrastructure avait grossi progressivement, partant d'un seul NUC pour atteindre cette configuration. Le problème n'était pas fonctionnel : Proxmox faisait son travail. Il était structurel.
Même avec Terraform et Ansible en place, la configuration dérivait. "Even with that automation, state drift can still creep in when debugging means running one quick command, especially if an agent is allowed to execute imperative fixes that never make it back into the automation framework", explique Bas Nijholt. Cette dérive - ces modifications imperatives qui n'intègrent jamais le framework d'automatisation - est un travers connu des approches impératives de gestion d'infrastructure. Le diagnostic est clair : tant que la configuration n'est pas la source unique de vérité, la reproductibilité est compromise.
Le choix de NixOS répond directement à ce problème. Son modèle déclaratif impose que chaque aspect du système - matériel, logiciel, services - soit décrit dans des fichiers textuels versionnés dans Git. Pas de modification non documentée possible : chaque changement est un commit, chaque état du système est auditable. "Your entire infrastructure is defined in text files. This means my AI agents can read, understand, and even safely modify my infrastructure", note Bas Nijholt.
Incus : la flexibilité que Proxmox n'offre pas
Le remplacement de Proxmox ne se fait pas par un simple hyperviseur générique. Incus, fork communautaire de Canonical LXD créé par @cyphar et aujourd'hui intégré au projet Linux Containers, apporte des garanties techniques spécifiques. Même socle technique - LXC - que Proxmox, mais avec une gouvernance indépendante et une architecture conçue pour la flexibilité.
La différence fondamentale tient à une contrainte de Proxmox :后者 impose son propre OS basé sur Debian. On ne fait pas tourner Proxmox VE sur Fedora ou Arch. Incus, à l'inverse, s'exécute sur n'importe quelle distribution Linux. Cette liberté n'est pas anecdotique : elle permet précisément de choisir NixOS comme système hôte, ce qui serait impossible avec Proxmox sans abandonner l'outil de virtualisation lui-même.
Sur le plan du clustering, Incus abandonne la dépendance à Corosync au profit d'une base de données distribuée basée sur le protocole Raft. L'équilibrage de charge est natif. Cette architecture réduit la complexité opérationnelle à mesure que le nombre de noeuds croît - un avantage direct pour les setups multi-machines.
Le processus de migration concrète
La migration d'un homelab entier soulève d'abord une question de données : comment déplacer des années d'historique numérique sans perte ? La réponse, dans ce cas, a été "surprisingly straightforward" selon Bas Nijholt. Deux outils ont suffi : vzdump pour extraire les dumps LXC des conteneurs Proxmox, et qemu-img pour convertir les disques des machines virtuelles vers le format compatible Incus.
Le point de vigilance n'était pas la conversion elle-même mais la validation. L'approche retenue mérite l'attention : avant de déconnecter le dernier hôte Proxmox, des machines virtuelles Incus ont été créées reproduisant exactement la configuration des serveurs physiques. Cette duplication virtuelle permettait de vérifier que l'ensemble fonctionnait - configuration NixOS, services, réseau - sans risquer de compromettre la production. "Before I actually switched off my last Proxmox host, I was already confident that the full configuration worked because I had a virtual machine running the same setup", précise Bas Nijholt.
Cette méthode élimine le scénario redouté du "nuking and paving" - formatage et réinstallation à l'aveugle - en permettant une validation complète sur un environnement jetable avant toute coupure définitive.
Les gains concrets du modèle déclaratif
L'infrastructure définie dans des fichiers texte versionnés apporte des bénéfices mesurables. Les mises à jour sont atomiques : un commit applique ou annule un changement complet. Les démarrages generational offrent un rollback instantané en cas de problème - il suffit de rebooter sur la génération précédente. La configuration d'une nouvelle machine devient triviale : cloner le dépôt Git, exécuter une commande, et l'ensemble du setup est reproduit à l'identique.
Au-delà de l'aspect reproductibilité, cette configuration texte ouvre des possibilités inédites par rapport à une interface graphique. Les agents d'intelligence artificielle peuvent lire, comprendre et modifier l'infrastructure via ces fichiers, ce qui était structurellement impossible avec le workflow piloté par l'interface web de Proxmox.
La courbe d'apprentissage : le prix à payer
Il serait malhonnête de présenter cette migration comme un simple changement d'outil. NixOS représente un changement de paradigme. Le langage Nix, le concept de dérivations, les Flakes - autant de notions qui n'ont pas d'équivalent direct dans les distributions Linux classiques. "Learning the Nix ecosystem is a big commitment. The ideas are very different from other Linux systems, so your existing knowledge doesn't help much", reconnaissent les utilisateurs expérimentés. Le délai avant de devenir productif se compte en mois, pas en semaines.
Ce coût d'apprentissage est le principal frein à l'adoption. Il s'agit d'un investissement initial lourd dont le retour se situe à moyen et long terme. Les utilisateurs qui ont franchi ce cap considèrent cependant que la stabilité et le contrôle acquis justifient l'effort initial.
Pour qui cette migration a du sens
Le cas Bas Nijholt est un homelab individuel, pas une production d'entreprise. Aucun témoignage documenté ne montre actuellement une organisation - association ou startup - ayant réalisé cette migration complète en environnement professionnel. Les retours disponibles émanent de configurateurs passionnés ou d'ingénieurs systèmes gérant des infrastructures personnelles.
La migration Proxmox vers NixOS et Incus s'adresse principalement à des profils techniques précis : développeurs ou administrateurs systèmes qui perçoivent leur OS comme un composant critique de leur outillage, aussi versionné et fiable que leur code. Les équipes cherchant la reproductibilité absolue, la traçabilité des changements et un contrôle total sur leur pile d'infrastructure y trouveront un parti. Ceux qui ont besoin d'une solution opérationnelle en quelques heures, ou dont l'équipe ne dispose pas du temps nécessaire à l'apprentissage de Nix, feront mieux d'attendre.
L'investissement en apprentissage peut se justifier par des gains réels de stabilité. Mais il ne se justifie que si le contexte technique et organizationnel est propice à un engagement à long terme sur un paradigme de configuration fondamentalement différent.