IncusOS : un hyperviseur immutable, et sans shell

Prenez n'importe quel parc d'hyperviseurs qui a trois ans. Ouvrez un shell sur le nœud 1, puis sur le nœud 7. Comparez /etc/sysctl.d, les paquets installés, le contenu de /root, les règles de pare-feu locales. Vous trouverez des écarts. Toujours. Un collègue a poussé un module kernel pour débugger une carte réseau en 2024, un autre a installé tcpdump et trois dépendances au passage, un troisième a désactivé un service parce qu'il polluait les logs. Rien de tout ça n'est documenté, et rien n'a été remis en place après.

C'est la dérive de configuration. Elle ne casse pas la prod tout de suite, elle attend le jour où vous devez reconstruire un nœud à l'identique, en urgence, à 3h du matin. IncusOS attaque le problème par la racine : il supprime le shell.

Annoncé le 7 novembre 2025 par Stéphane Graber après plus d'un an de développement, IncusOS est une image système immutable dont l'unique fonction consiste à faire tourner Incus, le gestionnaire de conteneurs système et de VM. Base Debian 13, kernel et ZFS issus des builds Zabbly, le tout assemblé avec l'outillage systemd moderne : mkosi pour la construction d'image, sysext pour l'ajout de composants, sysupdate pour les mises à jour.

Les partitions système sont en lecture seule et signées. Le boot passe par UEFI Secure Boot avec mesures TPM 2.0. La racine chiffrée s'ouvre via LUKS scellé au TPM, avec chiffrement ZFS par-dessus. Et surtout : aucun shell, ni local ni distant. Tout passe par l'API Incus authentifiée, en certificat client TLS ou en OIDC.

Ce n'est pas une distribution Linux avec une couche de durcissement. C'est un appliance logiciel qui se trouve tourner sur du Linux.

Le mécanisme mérite qu'on s'y arrête, parce qu'il change la façon dont on planifie une fenêtre de maintenance.

IncusOS utilise deux jeux de partitions système, A et B. La machine tourne sur A. La mise à jour se télécharge et s'écrit dans B pendant que la prod continue. Au reboot suivant, le système démarre sur B. Si ça se passe mal, on repart sur A. Le rollback n'est pas une procédure de restauration, c'est un changement d'entrée de boot.

Le système vérifie les mises à jour toutes les 6 heures. Deux canaux existent : stable, avec au minimum une publication hebdomadaire, et testing, en build quotidien. Les mises à jour d'Incus lui-même s'appliquent avec une interruption minimale de l'API et sans impact sur les instances en cours d'exécution ; seules les mises à jour de l'OS attendent un redémarrage.

Côté ops, la conséquence est directe. Sur un parc Proxmox ou Debian classique, l'état d'un hyperviseur après dix-huit mois de apt upgrade successifs dépend de l'ordre des opérations, des paquets tiers, et de ce qui a été retenu par un apt-mark hold oublié. Avec une image signée en A/B, deux nœuds sur la même version portent exactement les mêmes octets. La reconstruction d'un nœud n'est plus un projet, c'est un boot.

Cette logique n'a rien d'inédit. C'est celle de bootc et des systèmes image-based, et celle de Talos Linux côté Kubernetes. IncusOS l'applique au poste d'hyperviseur généraliste, ce qui manquait dans l'écosystème.

Beaucoup d'équipes vont buter là-dessus, et c'est normal : ça remet en cause une partie du métier.

Plus de shell, ça veut dire plus de strace sur un processus qui rame, plus de dmesg | grep improvisé, plus de fichier de config bricolé à la main pour tenir jusqu'au lendemain. Chaque diagnostic doit passer par un endpoint d'API ou ne pas exister. Ce que l'API n'expose pas, vous ne le verrez pas.

L'argument sécurité tient debout, lui. Une surface d'attaque sans interpréteur de commandes, sans gestionnaire de paquets et sans partition racine inscriptible enlève une bonne partie des primitives de post-exploitation. Un attaquant qui obtient une exécution de code dans un conteneur ne trouve pas d'environnement hôte à piller derrière. Combiné à la chaîne Secure Boot et UKI, la mesure TPM garantit qu'un système modifié hors ligne ne déverrouille pas ses disques. Ce n'est pas cosmétique : c'est la différence entre un serveur volé qui expose ses données et un serveur volé qui est une brique.

Le vrai gain est ailleurs, et il est humain. Un hyperviseur sans shell ne peut pas être modifié en douce. La procédure de changement devient la seule voie possible, non par discipline mais par construction. Toutes les équipes qui ont déjà cherché à comprendre pourquoi le nœud 7 se comporte différemment savent ce que ça vaut.

Le prix à payer se mesure en compétence. Une équipe qui exploite son parc au feeling et au shell sera perdue. Une équipe qui travaille déjà en infrastructure as code, avec du monitoring instrumenté et des runbooks, n'y perdra presque rien.

Un point qui élimine des candidats d'entrée de jeu : le TPM 2.0 est obligatoire. Pas de TPM matériel, pas de boot. Le support d'un TPM logiciel est suivi comme une évolution à venir, il n'est pas là.

Côté CPU, le minimum annoncé correspond à un Xeon E5 v3 ou plus récent, pour le support du jeu d'instructions x86-64-v3. Les générations v1 et v2 finiront hors périmètre. En pratique, tout serveur bare metal des cinq dernières années avec UEFI et TPM passe ; les architectures visées sont x86-64 et arm64.

Traduction pour un parc réel : les vieux nœuds de 2016 qui traînent encore dans un rack, ceux qu'on garde pour la préprod et les bacs à sable, ne migreront pas. Ils resteront sur du Proxmox ou du Debian classique. Vous aurez donc deux modes d'exploitation en parallèle pendant plusieurs années. Autant l'acter dès la conception plutôt que le découvrir au troisième nœud.

Le projet est jeune. Le dépôt lxc/incus-os affiche une cinquantaine d'issues ouvertes, ce qui est sain pour un projet actif, mais indique aussi que la surface fonctionnelle bouge encore.

Le stockage couvre ZFS nativement, avec création automatique du pool, plus Ceph, Fibre Channel, NVMe-over-TCP, iSCSI et LVM clusterisé. Linstor est annoncé pour plus tard. Le réseau tient la route pour un usage sérieux : bridges VLAN-aware, agrégation de liens, LLDP, OVS et OVN, proxy authentifié Kerberos, syslog distant en UDP, TCP ou TLS. Tailscale est intégré, Netbird annoncé.

Les vrais risques ne sont pas dans la liste de fonctionnalités.

Le premier, c'est la dépendance à un fournisseur unique d'images signées. Vos hyperviseurs bootent des binaires signés par le projet, et vous n'avez pas de shell pour intervenir si un build casse quelque chose sur votre matériel. Le canal stable limite l'exposition, il ne l'annule pas. Une politique de mise à jour échelonnée par vagues, avec un nœud témoin sur testing et le reste du parc en retard d'une semaine, n'est pas de la paranoïa : c'est le minimum.

Le deuxième, c'est le débogage matériel. Une carte réseau exotique, un contrôleur RAID capricieux, un firmware à mettre à jour : sans shell, vous dépendez de ce que le projet a prévu. Sur du matériel standard bien supporté par le kernel Zabbly, aucun souci. Sur du matériel de niche, vous prenez un risque réel.

Le troisième tient au temps. Proxmox VE traîne quinze ans de retours d'exploitation et une communauté qui a documenté tous les cas tordus. IncusOS a moins d'un an. Les scénarios de panne exotiques n'ont pas encore été rencontrés par assez de monde pour être écrits quelque part.

La comparaison avec Proxmox VE, dont on a détaillé le positionnement face à VMware, est inévitable, et la réponse est plus simple qu'il n'y paraît.

Proxmox reste le choix par défaut pour une infrastructure de virtualisation généraliste : interface web complète, sauvegarde intégrée avec PBS, communauté massive, matériel hétérogène toléré, shell disponible quand il faut. Si votre équipe pilote son parc à la main et que le virtualiseur doit encaisser des demandes variées, ne changez rien.

IncusOS vise autre chose : un socle de calcul homogène, piloté par API, sur du matériel standardisé, dans une organisation qui déploie déjà en infrastructure as code. Le cas d'usage évident, ce sont les flottes. Vingt nœuds identiques répartis sur plusieurs sites, tous exploités par le même pipeline, où la moindre dérive coûte des heures de diagnostic. La discipline ZFS que le projet impose au socle rejoint d'ailleurs les bonnes pratiques ZFS qu'on applique sur Linux, avec cet avantage que la configuration du pool n'est plus laissée à l'improvisation de celui qui a installé le nœud.

Pas de migration de production vers IncusOS en 2026 sans avoir tenu un pilote pendant au moins trois mois. Le protocole tient en quatre points : deux nœuds identiques au matériel de production, un cycle complet de mise à jour A/B avec rollback forcé, une simulation de panne disque avec remplacement à chaud, et un incident réseau à diagnostiquer sans shell, chronomètre en main. Si l'équipe n'arrive pas à qualifier une panne réseau via l'API seule, le sujet n'est pas l'outil, c'est l'instrumentation.

Le pari technique du projet est bon. Un hyperviseur qui ne peut pas dériver règle une classe entière de problèmes d'exploitation, et le modèle A/B rend les mises à jour banales au lieu d'anxiogènes. Le pari calendaire, lui, dépend de votre tolérance au risque. Sur une infrastructure critique, attendez que le projet ait deux ans et quelques retours publics de panne. Sur un socle de calcul neuf, où vous choisissez le matériel et où l'équipe travaille déjà par API, l'essai vaut d'être tenté maintenant.

Standardiser un parc d'hyperviseurs, tester les rollbacks avant d'en avoir besoin et instrumenter le diagnostic pour ne plus dépendre d'un shell, c'est le travail qu'on fait sur les infrastructures qu'on opère dans le DC Fullsave de Toulouse et sur le site TDF de Bordeaux. Si vous évaluez un socle de virtualisation immutable et que la question du pilote vous bloque, on peut cadrer la migration et opérer le parc plutôt que de le découvrir en production.

• Introducing IncusOS, Stéphane Graber : annonce officielle du 7 novembre 2025, prérequis matériels, exigence TPM 2.0 et minimum Xeon E5 v3.
• IncusOS Introduction, LinuxContainers : documentation officielle, schéma A/B, fréquence de vérification des mises à jour et canaux stable et testing.
• IncusOS Announced As Immutable Linux OS With ZFS For Running Containers, Phoronix : couverture de l'annonce, contexte du fork LXD vers Incus et modèle d'accès API.
• lxc/incus-os, dépôt GitHub : sources des images de production, état des issues ouvertes et pipeline de build testing vers stable.
• IncusOS: A New Immutable Linux System Built for Running Incus, Linuxiac : détail des backends de stockage supportés, fonctionnalités réseau et intégrations annoncées.