Le 7 novembre 2025, Stéphane Graber, le développeur principal d'Incus, a annoncé Incus OS : un système immuable qui ne fait tourner qu'une seule chose, Incus. Pas de paquets à gérer, pas de dérive de configuration, et surtout aucun shell. On n'ouvre pas de session SSH sur ces machines : tout passe par une API authentifiée.
J'ai voulu vérifier ce que cela donne en pratique, pas en lisant la doc mais en le faisant. Je me suis fixé un objectif volontairement inconfortable : monter un cluster 3 nœuds sur des machines virtuelles Proxmox, sans jamais ouvrir l'interface web. Rien que par fichiers de configuration et appels d'API. Voici ce que j'ai appris, ce qui coince, et pourquoi je pense que ce projet mérite qu'on regarde la section Incus de plus près, sans pour autant vous vendre du rêve.
Incus OS en une phrase
Incus OS n'est pas une distribution où l'on installe Incus. C'est une image système où le noyau, ZFS et Incus sont intégrés et signés, identique bit pour bit sur toutes les machines. La base est Debian 13, mais vous ne la gérez pas : les partitions système sont en lecture seule, les mises à jour sont atomiques A/B avec retour arrière automatique, et le démarrage est verrouillé par Secure Boot et TPM 2.0.
Le mot qui revient partout est immuable, mais ce n'est pas le vrai différenciateur. Des OS immuables, il en existe déjà : Talos Linux pour Kubernetes, Fedora CoreOS ou openSUSE MicroOS côté généraliste. La singularité d'Incus OS, c'est d'être mono-usage au service d'Incus, donc de la virtualisation et des conteneurs système dans le même outil. Là où Talos ne sait faire que du Kubernetes, Incus OS vise le poste d'hyperviseur complet.
Le pari derrière l'annonce
Incus OS ne sort pas de nulle part. Il fait partie d'un ensemble plus large présenté un mois plus tôt, le FuturFusion Cloud stack : Incus comme moteur, Incus OS comme socle, plus deux outils annoncés le 21 décembre 2025, Operations Center (déploiement de clusters à grande échelle) et Migration Manager (migration depuis VMware). Le positionnement est assumé : offrir un chemin de sortie de VMware entièrement open source.
C'est ce cadrage qui m'a intrigué. On ne parle pas d'un gadget de homelab, mais d'une tentative de couvrir la chaîne complète, du serveur nu au cluster de production. Reste à voir si le socle tient la route quand on le manipule vraiment.
Mon test : un cluster sans interface
L'installation se fait par image ISO accompagnée de petits fichiers de configuration, les seed, gravés sur un second média étiqueté SEED_DATA. Ces fichiers pilotent l'installation puis la première configuration du nœud : réseau, stockage, et surtout la confiance.
Le point de bascule a été là. Sur une machine sans shell, comment rendre mon client en ligne de commande de confiance sans passer par l'assistant graphique ? La réponse tient dans le seed : on y injecte directement un certificat client au format PEM. Au premier démarrage, le certificat est déjà reconnu. Une simple requête le confirme, "auth":"trusted", et à partir de là je pilote tout à distance.
Le cluster lui-même se monte ensuite comme un cluster Incus classique, mais avec deux subtilités propres à Incus OS que j'ai découvertes à la dure. J'ai détaillé la recette complète dans le guide Incus OS, et les concepts de quorum dans le guide Cluster Incus. Au bout de la chaîne, incus cluster list affiche mes trois nœuds ONLINE, quorum atteint, port SSH fermé partout. Le cluster complet monté sans un seul clic dans l'interface.
Les pièges qui m'ont coûté un cycle
Je préfère être honnête sur ce qui ne passe pas du premier coup, parce que ces messages d'erreur m'ont chacun coûté une réinstallation.
Le disque cible doit être en virtio-scsi. Avec un disque virtio-blk, l'installeur refuse de démarrer avec un laconique no potential install devices found. Le média de configuration doit porter exactement le label SEED_DATA, sinon l'installation s'arrête sur unable to begin install from read-only device without seed configuration.
Les deux vrais pièges arrivent à la jointure du cluster. Sans le certificat du cluster dans le seed, le nœud échoue sur No target cluster member certificate provided : le client interactif résout ce certificat tout seul, mais l'application du seed, elle, ne le fait pas. Et sans indiquer la source du pool de stockage, Incus tente un pool sur fichier que l'OS refuse net avec Loop backed pools aren't supported on IncusOS. Rien d'insurmontable, mais rien d'évident non plus quand on débarque.
Le sans-shell est un choix, pas un défaut
C'est le point qui divise le plus, et je le comprends. Ne pas pouvoir se connecter en SSH pour un correctif rapide, c'est un vrai changement d'habitude. Sur le forum officiel, la question « Incus OS ou Incus classique pour un homelab » revient souvent, et la réponse des mainteneurs eux-mêmes est nuancée : pour apprendre et expérimenter, commencez par Incus classique, plus souple ; gardez Incus OS pour une cible proche de la production, quand la reproductibilité prime sur le bricolage.
Je partage cet avis. L'absence de shell n'est pas une limite subie, c'est une décision de design : elle ferme un vecteur d'intrusion classique et garantit que deux machines de même version sont réellement identiques. Mais elle impose de tout penser en amont, dans le seed et l'API. Ce n'est pas le bon terrain pour découvrir Incus.
Les prérequis qui bloquent vraiment
Voici où je coupe court aux fausses promesses. Incus OS ne tourne pas « sur n'importe quel matériel ». Il exige un UEFI avec Secure Boot, un TPM 2.0 et un CPU récent (niveau x86-64-v3, soit un Xeon E5 v3 au minimum côté Intel). Il n'y a pas de TPM logiciel de secours : sans TPM, pas de déploiement.
Et la doc officielle est explicite : faire tourner Incus OS sans Secure Boot est déconseillé et « non recommandé » en entreprise. Avant même d'essayer, vérifiez votre matériel. Plusieurs testeurs indépendants ont aussi buté sur la confiance du certificat TLS dans le navigateur, un premier contact plus rugueux qu'attendu. Ce sont des frictions réelles, pas des détails.
Un projet jeune, mais bien vivant
Le moteur Incus, lui, avance vite. Rien que sur 2026 : la 7.0 LTS en mai a apporté le support des images OCI et un listener S3 intégré, la 7.2 de juin a ajouté le confinement SELinux par instance. Cette même 7.2 a aussi corrigé six failles critiques, dont des accès à des fichiers de l'hôte via des images malveillantes. J'en tire deux lectures, et je vous donne les deux : le projet est actif et réactif, et la sécurité s'y corrige au fil de l'eau, comme partout. Un socle vivant, pas un socle figé.
Côté outils d'entreprise, Operations Center et Migration Manager existent, mais le projet reconnaît lui-même qu'il s'agit du strict minimum pour déployer des clusters de production, avec « beaucoup de travail devant ». Le chemin de sortie de VMware est crédible sur le papier ; il n'est pas encore mûr. Incus OS a été annoncé il y a moins d'un an : c'est prometteur et déjà utilisable pour qui accepte ses contraintes, ce n'est pas une plateforme éprouvée depuis dix ans. Je ne dirai pas qu'il remplace Proxmox, qui garde une interface plus complète, un passthrough GPU plus simple et une communauté bien plus large.
Par où commencer
Si ce billet vous a donné envie de mettre les mains dedans, ne commencez pas par Incus OS. Commencez par Incus tout court, sur votre Debian ou Ubuntu, où vous gardez votre shell et toute votre liberté pour expérimenter. L'installation prend quelques minutes et les premiers pas vous font lancer conteneurs et VM avec une seule commande.
Une fois à l'aise, l'accès distant et l'interface puis le cluster vous préparent au modèle qu'Incus OS pousse à l'extrême. Et le jour où vous voudrez un socle immuable et reproductible, le guide Incus OS vous donnera la recette complète, testée, y compris le cluster sans interface. Toute la section Incus est construite dans cet ordre, du plus simple au plus engageant.
À retenir
- Incus OS est un OS immuable mono-usage Incus, annoncé en novembre 2025, sans shell, piloté par API.
- Son vrai différenciateur n'est pas l'immuabilité mais le fait d'être dédié à Incus, VM et conteneurs système compris.
- J'ai monté un cluster 3 nœuds sans interface, entièrement par seed et API : c'est faisable, et la confiance s'injecte par le seed.
- Les prérequis matériels sont bloquants : TPM 2.0, Secure Boot, CPU récent. Sans Secure Boot, la doc déconseille l'usage.
- Projet jeune mais actif : Incus enchaîne les versions, mais les outils d'entreprise sont encore au minimum viable.
- Pour apprendre, commencez par Incus classique ; gardez Incus OS pour une cible proche de la production.