Incus gère conteneurs, VMs et cluster depuis une seule CLI — sans Canonical, sans CLA et sans abonnement

Le 7 août 2023, Aleksa Sarai forkait LXD après que Canonical a repris le contrôle du projet et l’a retiré de la tutelle de Linux Containers. Le 26 juin 2026, Incus 7.2 sortait avec le support de la migration à chaud des VMs et la compatibilité OCI native pour les conteneurs applicatifs. Le 10 juillet 2026, le correctif 7.0.1 LTS verrouillait la branche stable jusqu’en juin 2029. En trois ans, le fork est devenu le projet principal — maintenu par la même équipe qui avait créé LXD, hébergé sous l’égide de Linux Containers, sous licence Apache 2.0 et sans CLA.

Incus ne remplace pas un seul outil. Il en remplace trois. Il fait tourner des conteneurs système Linux comme LXD, des conteneurs applicatifs OCI comme Docker, et des machines virtuelles QEMU comme Proxmox — le tout avec la même CLI, la même API REST, et la possibilité de les faire cohabiter sur un cluster de plusieurs nœuds. Pour un homelab, une PME ou un SRE qui gère des environnements hétérogènes, c’est un couteau suisse qui évite trois plans de maintenance distincts.

Le fork qui a avalé l’original

L’histoire d’Incus commence là où celle de LXD déraille. En juillet 2023, Canonical annonce que LXD ne sera plus maintenu sous l’égide de Linux Containers — le projet communautaire qui l’hébergeait depuis sa création en 2014 — mais deviendra un produit Canonical à part entière, avec un CLA obligatoire pour les contributeurs externes. Le CLA (Contributor License Agreement) permet à Canonical de relicencier le code sous une licence propriétaire sans demander l’accord des auteurs originaux. Pour la communauté qui avait construit LXD bénévolement pendant près de dix ans, c’est une ligne rouge.

Aleksa Sarai — le mainteneur des paquets LXD pour openSUSE et contributeur majeur à runc et umoci — réagit en quelques jours. Il fork le code de LXD 5.16, le débarrasse du CLA, et le publie sous le nom Incus (l’enclume, en référence au nuage Cumulonimbus incus). Linux Containers adopte officiellement le fork le 1er novembre 2023.

Le détail qui tue : l’équipe de maintenance initiale d’Incus inclut Stéphane Graber, Christian Brauner, Serge Hallyn et Tycho Andersen — soit la totalité de l’équipe qui avait créé LXD. Le fork n’a pas perdu ses auteurs : il les a récupérés. Résultat : 41 484 commits sur le dépôt GitHub, 5 800 étoiles, des releases mensuelles et une LTS 7.0 supportée jusqu’en juin 2029.

Conteneur système, conteneur applicatif, VM — la triple casquette

C’est la proposition de valeur centrale d’Incus. La plupart des outils de virtualisation sont spécialisés : Docker pour les conteneurs applicatifs, LXC pour les conteneurs système, QEMU/libvirt ou Proxmox pour les VMs. Incus fait les trois avec le même daemon, la même CLI et les mêmes abstractions de stockage et de réseau.

Un conteneur système simule un OS complet. Il boote avec systemd, lance des services, survit aux reboots et se comporte comme une machine Linux légère — sans le surcoût d’un noyau invité. C’est l’usage historique de LXD : isoler des services comme PostgreSQL, nginx ou Redis dans des environnements quasi-natifs qui partagent le noyau de l’hôte.

# Lancer un conteneur Debian 13 en 30 secondes
incus launch images:debian/13 mon-serveur
incus exec mon-serveur bash

Un conteneur applicatif OCI fait tourner une image Docker standard. Incus intègre un runtime OCI depuis la version 6.0 LTS — il peut exécuter n’importe quelle image Docker Hub, GHCR ou registre privé sans Docker Engine installé.

# Lancer une image Docker avec Incus
incus launch docker:n8nio/n8n mon-n8n

Une machine virtuelle tourne avec QEMU en backend, avec un noyau invité complet. Incus gère le cloud-init, l’UEFI, le Secure Boot, le TPM virtuel et le GPU passthrough. Vous pouvez lancer une VM Windows 11, une VM FreeBSD ou un noyau custom sans quitter l’écosystème Incus.

# Lancer une VM Ubuntu 24.04 LTS
incus launch images:ubuntu/24.04/cloud ma-vm --vm

Les trois types d’instances partagent les mêmes profils de configuration, les mêmes pools de stockage (ZFS, Btrfs, LVM, Ceph, Dir) et les mêmes réseaux (bridge, macvlan, OVN). Un conteneur système et une VM peuvent se parler sur le même réseau bridge défini dans Incus, avec les mêmes règles de pare-feu.

Le cluster qui dort tranquille

Incus implémente un clustering natif sans dépendance externe. Pas besoin de etcd, de Consul ou de Corosync : le consensus est géré directement par le daemon Incus via Raft, et la base de données distribuée repose sur Dqlite (une version distribuée de SQLite créée par Canonical, ironiquement, mais reprise telle quelle dans le fork).

Ajouter un nœud au cluster prend trois commandes :

# Sur le nœud principal
incus config set core.https_address :8443
incus cluster enable nœud1

# Sur le nouveau nœud
incus admin cluster join <token>

Le résultat : une API unique qui expose toutes les instances du cluster, quel que soit le nœud physique sur lequel elles tournent. Les instances peuvent être migrées à chaud (live migration) entre nœuds, avec ou sans stockage partagé. Les conteneurs et les VMs peuvent cohabiter sur les mêmes nœuds ou être répartis par rôle.

Le clustering d’Incus n’est pas un orchestrateur au sens Kubernetes — il ne fait pas de scheduling automatique, de health checks applicatifs ou de rolling updates. Mais pour un cluster de trois serveurs qui fait tourner des services internes avec de la haute disponibilité manuelle, il remplace Proxmox VE sans l’interface web, sans l’abonnement et sans la surcouche de complexité.

Incus vs Docker — le bon outil pour le bon usage

La comparaison Docker/Incus est piégeuse parce qu’elle oppose deux philosophies différentes du conteneur.

Docker est pensé pour le conteneur applicatif : une image immutable, un processus unique, un cycle de vie éphémère. docker run, docker rm, et la reconstruction d’image si quelque chose change. C’est le modèle idéal pour du CI/CD, du microservice et du stateless.

Incus est pensé pour le conteneur de service : une distribution Linux complète, un init system, des mises à jour de paquets. incus exec pour entrer dedans, apt upgrade comme sur une machine physique, snapshots et rollback avant chaque changement risqué. C’est le modèle idéal pour un serveur qui vit des mois, avec des configurations qui évoluent dans le temps.

La zone grise, c’est que les deux peuvent faire le travail de l’autre. On peut lancer un Dockerfile dans Incus via le runtime OCI. On peut faire tourner systemd dans un conteneur Docker avec assez de --cap-add et de --privileged. Mais ce n’est pas pour ça qu’ils sont conçus.

Pour un SRE, la règle est simple : conteneur applicatif → Docker (ou Podman), conteneur de service → Incus, VM → Incus. Une stack web typique pourrait avoir Traefik en conteneur Incus (parce qu’il a besoin de Let’s Encrypt, de certificats persistants et de rechargements à chaud), PostgreSQL en conteneur Incus (parce qu’il mérite ZFS et des snapshots avant migration), et des workers applicatifs en conteneurs Docker. Incus orchestre la couche infrastructure, Docker la couche applicative — et les deux tournent sur le même hôte.

Incus vs Proxmox — le cluster sans l’usine à gaz

Proxmox VE est un hyperviseur complet avec une interface web, un orchestrateur HA, une gestion du stockage distribué (Ceph) et un pare-feu intégré. Il est excellent pour gérer une grappe de serveurs avec des dizaines de VMs, du live migration automatique et des politiques de backup granulaires. Mais il vient avec un abonnement (optionnel mais fortement recommandé pour les mises à jour enterprise), une interface web obligatoire pour beaucoup d’opérations, et une empreinte système non négligeable.

Incus n’a pas d’interface web native. Il se pilote entièrement en CLI ou via son API REST. Il ne fait pas de haute disponibilité automatique avec fencing et quorum — la migration à chaud est manuelle. Il n’intègre pas de backup scheduler ni de monitoring intégré.

En contrepartie, il est radicalement plus léger. Un nœud Incus sans instance tourne sous 100 Mo de RAM. Il n’impose pas de modèle de stockage — vous montez ce que vous voulez (ZFS, Btrfs, LVM, Ceph, NFS) et Incus s’adapte. Il n’y a pas d’abonnement, pas de licence, pas de popup de renouvellement.

Pour un homelab ou une PME avec trois serveurs, le choix est souvent :

• Moins de 5 VMs, beaucoup de conteneurs → Incus. La légèreté et la simplicité l’emportent sur l’interface web.
• Plus de 10 VMs, migration automatique, backup policy → Proxmox. L’interface web et l’orchestrateur HA justifient l’abonnement.
• Un seul serveur → Incus, sans hésiter. Proxmox sur un nœud unique, c’est un moteur de formule 1 pour faire ses courses.

Stockage, snapshots et backups — la base solide

Incus hérite de l’excellente gestion du stockage de LXD. Les instances tournent sur des pools de stockage qui peuvent être en ZFS, Btrfs, LVM, Ceph ou directory. Le choix du backend détermine les fonctionnalités disponibles :

• ZFS et Btrfs activent les snapshots quasi-instantanés, la déduplication et le send/receive pour les backups incrémentaux. Un snapshot de conteneur sous ZFS prend moins d’une seconde, quelle que soit la taille des données.
• LVM offre des volumes logiques classiques avec redimensionnement à chaud.
• Ceph (via RBD) permet le stockage distribué avec réplication multi-nœuds pour les clusters de production.

# Créer un pool ZFS et lancer une instance dedans
incus storage create pool1 zfs source=/dev/sdb
incus launch images:debian/13 mon-serveur --storage pool1

# Snapshot avant une migration risquée
incus snapshot create mon-serveur avant-migration

# Restaurer en cas de problème
incus snapshot restore mon-serveur avant-migration

Pour les backups, Incus peut exporter une instance complète (conteneur ou VM) en une archive compressée, ou utiliser incus copy pour dupliquer une instance entre pools de stockage, entre nœuds d’un cluster ou vers un serveur distant via l’API. Pas de scripts de backup externes, pas de cron — tout passe par la CLI.

La migration depuis LXD

Si vous utilisez déjà LXD, la migration vers Incus est documentée et réversible. L’outil lxd-to-incus (fourni par le projet) convertit la base de données LXD au format Incus et recrée les instances sans perte de données.

# Installer l'outil de migration
sudo apt install incus-tools

# Lancer la migration
sudo lxd-to-incus

La compatibilité est quasi-totale : les images, les profils, les pools de stockage et les réseaux sont préservés. Les conteneurs existants ne sont pas redémarrés pendant la migration. Le seul point d’attention concerne les configurations réseau complexes — les bridges OVN et les tunnels inter-hôtes peuvent nécessiter une reconfiguration manuelle.

Si vous partez de zéro, l’installation tient en deux commandes sur Debian, Ubuntu, Fedora ou Arch Linux :

# Debian/Ubuntu
sudo apt install incus

# Initialisation interactive (répondre aux questions)
sudo incus admin init

Verdict

Prenez Incus si vous gérez un homelab, une PME ou un parc de serveurs hétérogènes avec un mix de conteneurs et de VMs. La CLI unifiée, le clustering sans dépendance externe, les snapshots ZFS et la licence Apache 2.0 sans CLA en font l’outil le plus polyvalent de l’écosystème Linux Containers. La LTS 7.0 est garantie jusqu’en juin 2029 — votre infra ne sera pas orpheline dans six mois.

Gardez Docker pour vos conteneurs applicatifs et Proxmox pour vos gros clusters de VMs. Incus ne remplace pas l’écosystème Docker (Docker Compose, Docker Hub, BuildKit) ni l’orchestrateur HA de Proxmox. Mais entre LXD, un serveur Docker pour des services persistants et une petite grappe Proxmox, Incus remplace les trois avec un seul daemon, une seule CLI et zéro abonnement.

Le vrai coût d’Incus, c’est l’absence d’interface web et la nécessité de lire la documentation pour le clustering avancé. Pour un SRE qui passe ses journées dans un terminal, ce n’est pas un coût — c’est un argument de vente.

Références

• Incus — Site officiel — consulté le 8 juillet 2026
• Incus — Annonce du fork — 7 août 2023
• Incus GitHub Repository — 5 800 étoiles, 41 484 commits, Apache 2.0
• Incus 7.2 — Release notes — 26 juin 2026
• Incus 7.0 LTS — Release notes — avril 2026
• Incus Documentation — consulté le 8 juillet 2026
• Zabbly — Incus packages and commercial support — consulté le 8 juillet 2026
• LXD — Canonical takeover announcement — consulté le 8 juillet 2026