Incus en production en 2026 : le fork de LXD qui a pris le relais

Quand Canonical a retiré LXD du giron de la communauté Linux Containers à l'été 2023 pour en reprendre le développement en interne, beaucoup d'opérateurs ont eu la même réaction : on garde un outil dont la gouvernance vient de basculer chez un éditeur unique, ou on suit l'équipe qui l'a écrit ? Trois ans plus tard, la réponse est tranchée sur le terrain. L'équipe historique est partie, le fork communautaire a hérité de l'écosystème, et c'est lui qui tourne sur les hyperviseurs qu'on déploie aujourd'hui.

La chronologie mérite d'être posée correctement, parce qu'elle conditionne le choix technique. En juillet 2023, Canonical annonce que LXD ne sera plus un projet indépendant : l'outil quitte Linux Containers et son développement repasse en interne chez l'éditeur d'Ubuntu. Dans la foulée, Stéphane Graber, ingénieur en chef de LXD depuis ses débuts, quitte Canonical.

Le fork arrive début août 2023. Il est techniquement créé par Aleksa Sarai, développeur chez SUSE, avec le soutien immédiat de l'ancienne équipe LXD. Le nom retenu est Incus. L'équipe de mainteneurs initiale regroupe Christian Brauner, Serge Hallyn, Stéphane Graber et Tycho Andersen : autrement dit, la quasi-totalité des gens qui avaient construit LXD à l'origine. Incus est ensuite adopté par la communauté Linux Containers, qui récupère ainsi la place laissée vacante par le départ de LXD.

C'est le point qui change tout. Incus n'est pas un fork de garage maintenu par un inconnu. C'est le projet qui a hérité de l'expertise originelle et de l'ombrelle Linux Containers, pendant que LXD repartait sous le contrôle exclusif d'un éditeur commercial. Pour qui décide d'une stack d'infrastructure censée vivre cinq à dix ans, la nature de la gouvernance n'est pas un détail philosophique : c'est un facteur de risque opérationnel.

Avant d'aller plus loin, une distinction que trop de monde confond, et qui explique pourquoi Incus n'est pas un concurrent de Docker au sens strict.

Un conteneur applicatif à la Docker embarque un processus et ses dépendances. Pas de systemd, pas de gestionnaire de paquets fonctionnel à demeure, pas de plusieurs services qui cohabitent. On le détruit et on le recrée, il est jetable par conception. C'est parfait pour packager une appli et la déployer en masse.

Un conteneur système se comporte comme une machine virtuelle légère. Il fait tourner un init complet, plusieurs services, des utilisateurs, des logs persistants. On s'y connecte en SSH, on y installe des paquets, on le sauvegarde comme un serveur. La différence avec une VM : pas d'hyperviseur ni de noyau invité, le conteneur partage le noyau de l'hôte. Densité supérieure, démarrage quasi instantané, overhead négligeable.

Incus gère les deux mondes sous un seul outil. Des conteneurs système (basés sur LXC), des machines virtuelles complètes (via QEMU/KVM) quand on a besoin d'un noyau séparé ou de faire tourner du Windows, et depuis 2025 des conteneurs applicatifs créés directement à partir d'images OCI. Une même CLI, une même API, un même modèle de clustering pour piloter ces trois formats. C'est cette polyvalence qui rend l'outil intéressant en infrastructure : on arrête de jongler entre trois orchestrateurs.

La question revient à chaque audit. La réponse tient en trois points.

La gouvernance d'abord. LXD est repassé sous contrôle Canonical, distribué prioritairement via snap, avec les contraintes que ça implique. Incus est un projet Linux Containers, gouverné par sa communauté, paquets natifs disponibles dans les dépôts des distributions. Debian 13 trixie l'embarque nativement, en suivant la ligne LTS d'Incus pour rester aligné sur son propre cycle de support. Quand l'outil qui gère votre parc dépend du bon vouloir commercial d'un seul acteur, vous héritez de son agenda, pas du vôtre.

Le rythme et la cohérence ensuite. Incus a profité du fork pour corriger des choix de conception de LXD qu'on ne pouvait pas changer sans casser la compatibilité ascendante. Les releases s'enchaînent à un rythme soutenu, avec une ligne LTS pour les environnements de production qui veulent de la stabilité. Concrètement, Debian 13 trixie fournit en natif la série 6.0 LTS, tandis que la 7.0 LTS plus récente s'obtient via les backports ou le dépôt Zabbly maintenu par le projet. Le choix dépend de l'appétit pour les nouveautés : on reste sur la LTS empaquetée par la distribution si on veut le moins de surface de maintenance, on passe aux backports si on a besoin des dernières fonctionnalités de clustering.

L'équipe enfin. Les gens qui maintiennent Incus sont ceux qui ont écrit LXD. Le savoir-faire est parti avec eux. Ça ne garantit rien sur dix ans, mais en 2026 le centre de gravité technique de cet écosystème est clairement du côté d'Incus.

Bonne nouvelle pour qui tourne encore sous LXD : la migration est outillée et conçue pour être indolore. Incus fournit un binaire dédié, lxd-to-incus, qui convertit une installation LXD existante en installation Incus.

La marche à suivre, telle qu'elle ressort des retours de migration de terrain :

# Installer la dernière version stable d'Incus SANS l'initialiser
apt install incus

# Vérifier que les deux outils répondent
lxc info
incus info

# Lancer la migration
lxd-to-incus

Le point à comprendre : on installe Incus mais on ne l'initialise surtout pas. L'outil transfère l'intégralité de la base de données et de tout le stockage depuis LXD, ce qui aboutit à une configuration strictement identique après migration. Pas de réimport manuel des conteneurs, pas de reconfiguration réseau à la main.

Deux gotchas à connaître. Le premier : la migration ne touche pas aux groupes utilisateurs. Après coup, il faut ajouter les utilisateurs qui étaient dans le groupe lxd au groupe équivalent incus-admin, et comme l'appartenance à un groupe ne se rafraîchit qu'à la connexion, ces utilisateurs devront fermer puis rouvrir leur session. Le second : la configuration du client en ligne de commande n'est pas migrée. Pour la récupérer, on recopie le contenu de ~/.config/lxc/ ou ~/snap/lxd/common/config/ vers ~/.config/incus/.

Sur un parc de plusieurs hôtes, on teste la procédure sur une machine non critique d'abord, on valide le comportement, puis on déroule. Pas de migration de prod un vendredi soir sans un retour arrière documenté.

Pour situer l'ergonomie, voici à quoi ressemble le quotidien. Lancer un conteneur système Debian, lister, entrer dedans :

incus launch images:debian/13 web01
incus list
incus exec web01 -- bash

Lancer une VM complète plutôt qu'un conteneur, c'est un simple flag :

incus launch images:debian/13 vm01 --vm

Le serveur d'images public de Linux Containers (images:) fournit un catalogue large de distributions prêtes à l'emploi, conteneurs comme VM. On peut aussi gérer ses propres images, les publier dans un dépôt interne, et versionner ses templates. En parc managé, on bâtit ses images de référence durcies une fois, on les pousse, et chaque nouvel hôte tire la même base.

Une machine isolée, c'est un POC. La production, c'est du clustering, et c'est là qu'Incus a beaucoup travaillé.

Plusieurs hôtes Incus se fédèrent en cluster avec une base de données distribuée, sans dépendance externe lourde. Les instances se placent et se déplacent entre nœuds. Incus 7.0 LTS a introduit une action d'arrêt configurable pour les nœuds en cluster : avec core.shutdown_action réglé sur evacuate, un serveur qui s'arrête déplace ses instances vers les autres nœuds au lieu de les éteindre localement. Pour la maintenance planifiée, c'est exactement le comportement qu'on veut.

Sur du matériel hétérogène, les groupes de cluster supportent la définition de baselines CPU, ce qui permet de calculer un jeu de fonctionnalités CPU commun pour que la migration d'instances entre nœuds aux processeurs différents reste possible. C'est le genre de détail qui fait la différence quand on étend un cluster avec des générations de serveurs successives, situation banale en parc qui vit plusieurs années.

Pour qui veut pousser plus loin la logique de l'immuable, le projet développe IncusOS, une image système minimale et immuable dédiée uniquement à faire tourner Incus. L'approche est intéressante pour réduire la surface de maintenance des hyperviseurs, à surveiller selon sa maturité avant un déploiement large.

Pas de réponse universelle, mais des lignes claires.

Face à Proxmox, le partage est net : Proxmox excelle comme plateforme de virtualisation complète avec une interface web aboutie et un écosystème de sauvegarde mûr, là où Incus brille sur la densité de conteneurs système et la légèreté. Les deux ne s'excluent pas : on voit souvent Proxmox pour le socle VM lourd et Incus pour les conteneurs système à forte densité. On a détaillé ailleurs l'usage des conteneurs LXC sous Proxmox en production et le comparatif Proxmox face à VMware.

Face à Docker, il n'y a pas vraiment de compétition : ce sont des problèmes différents. Docker package des applications, Incus fait tourner des systèmes. Si votre besoin est de déployer des conteneurs applicatifs stateless, Docker ou un runtime OCI restent l'outil adéquat, et le débat se déplace plutôt vers les runtimes eux-mêmes, qu'on a abordé côté Podman en 2026 et côté containerd comme runtime. Si votre besoin est de remplacer une flotte de VM ou de petits serveurs par des conteneurs système denses, c'est Incus.

On le déploie quand on veut de la densité de serveurs Linux légers, un mélange conteneurs système et VM sous un même outil, une gouvernance communautaire, et qu'on est à l'aise en ligne de commande et en API. Pour de la consolidation de petits serveurs, des environnements de dev et de test à la pelle, ou un socle de virtualisation léger maîtrisé en CLI, c'est un excellent choix.

On s'abstient si l'équipe exige une interface web riche clé en main avec support commercial cadré : Proxmox répond mieux. On s'abstient aussi si le besoin réel est de l'orchestration d'applications conteneurisées à grande échelle : c'est le terrain de Kubernetes, et le rapprochement VM et conteneurs y a sa propre réponse via KubeVirt. Et si vous sortez d'un parc VMware en quête de remplacement, le chemin le plus direct passe en général par une migration vers Proxmox avant de réfléchir à pousser certaines charges vers des conteneurs système.

Le bon réflexe : ne pas choisir Incus parce qu'il est à la mode dans les home labs, mais parce que le profil de charge correspond à des conteneurs système denses. Sur ce terrain précis, en 2026, c'est l'outil de référence.

Mettre Incus en production, ce n'est pas que incus launch. C'est le clustering, le stockage, le réseau, la sauvegarde testée et le runbook qui va avec. C'est précisément ce qu'on outille sur les infrastructures qu'on opère : si vous évaluez Incus pour consolider un parc ou monter un socle de virtualisation léger, on peut cadrer l'architecture et l'exploitation avec vous.

• Linux Containers Forks LXD Project As "Incus" (Phoronix) : annonce du fork et de son adoption par la communauté Linux Containers.
• Incus: A new fork of Canonical's LXD 'containervisor' (The Register) : contexte du départ de Canonical, équipe de mainteneurs et genèse du projet.
• Migration (Incus documentation) : panorama officiel des scénarios de migration vers Incus et des outils associés.
• Migrating to Incus from LXD (blog de Simos Xenitellis) : procédure détaillée lxd-to-incus, installation sans init, groupe incus-admin, re-login et copie de la config CLI.
• Incus (Debian Wiki) : disponibilité des paquets natifs à partir de Debian 13 trixie et suivi des releases LTS.
• Incus 7.0 LTS Container & Virtual Machine Manager Released (Linuxiac) : nouveautés clustering et action d'évacuation à l'arrêt en 7.0 LTS.