Installer Incus sur un serveur dédié : conteneurs et VM légers sans Proxmox

Incus est un gestionnaire de conteneurs système et de machines virtuelles maintenu par le projet Linux Containers. Né en 2023 comme fork communautaire de LXD, il pilote depuis une seule ligne de commande des conteneurs LXC qui partagent le noyau de l'hôte et des VM QEMU/KVM qui démarrent leur propre noyau. Sur un serveur dédié bare metal, c'est l'alternative légère à un hyperviseur complet comme Proxmox VE : pas de distribution dédiée à installer, pas d'interface web obligatoire, juste un daemon et un client sur votre Debian ou votre Ubuntu habituel.

Ce guide couvre l'installation d'Incus depuis le dépôt Zabbly, l'initialisation du stockage et du pont réseau, la création d'un premier conteneur puis d'une première VM, l'exposition d'un service sur l'IP publique du serveur, le branchement sur un bridge physique, et la migration d'une installation LXD existante avec l'outil lxd-to-incus. Il s'adresse aux administrateurs qui gèrent un serveur dédié ou un VPS Linux et qui veulent isoler leurs services (serveur web, base de données, serveur de jeu, runner CI) sans passer par Proxmox ni par Docker.

Incus en deux mots : le fork communautaire de LXD, sous licence Apache 2.0

En juillet 2023, Canonical a sorti LXD du projet Linux Containers pour en reprendre le développement en interne. Aleksa Sarai a aussitôt créé un fork, Incus, que Linux Containers héberge depuis avec l'essentiel de l'équipe qui avait conçu LXD, Stéphane Graber en tête. En décembre 2023, LXD 5.20 est passé de la licence Apache 2 à l'AGPLv3 avec signature obligatoire du CLA de Canonical, et le projet Linux Containers a restreint l'accès de son serveur d'images communautaire aux clients LXD. Incus, lui, est resté sous licence Apache 2.0 et utilise ce serveur d'images comme remote par défaut (images:).

Côté versions, Incus suit deux rythmes de publication :

• Incus 7.0 LTS, publié le 5 mai 2026 et maintenu jusqu'en juin 2031 : deux ans de correctifs de bugs et de sécurité en versions 7.0.x, puis trois ans de correctifs de sécurité seulement. C'est la branche à installer en production. Incus 6.0 LTS, la LTS précédente, est entré en phase « sécurité uniquement » ;
• Les versions mensuelles (7.1 à 7.6 au moment d'écrire, la 7.6 datant du 30 octobre 2026) : nouvelles fonctionnalités chaque mois, pour les administrateurs qui veulent suivre le rythme de développement.

Incus 7 exige d'après sa documentation un noyau Linux 6.12 minimum, LXC 6.0 et QEMU 8.2 pour les machines virtuelles. Il ne prend plus en charge cgroup v1 ni iptables : le pare-feu passe exclusivement par nftables, ce qui compte si vous avez déjà des règles sur l'hôte (voir notre guide nftables sur serveur Linux).

Incus ou Proxmox VE sur un serveur dédié : ce qui change

Proxmox VE et Incus font tous les deux tourner des VM KVM et des conteneurs LXC sur une base Debian. La différence est dans l'approche : Proxmox VE est une distribution complète avec son installateur, son noyau, son interface web et son outillage de cluster, de sauvegarde et de haute disponibilité (nous l'avons détaillée dans Proxmox VE face à OpenStack). Incus est un daemon que l'on ajoute à une distribution existante, piloté par un CLI et une API REST, avec une interface web facultative.

En pratique, Incus convient quand vous voulez garder la main sur la distribution de l'hôte, scripter toute l'infrastructure en ligne de commande, ou faire cohabiter sur le même serveur dédié des conteneurs système, une ou deux VM et vos outils habituels. Proxmox VE reste le choix naturel pour un cluster piloté à la souris avec sauvegardes et haute disponibilité intégrées : notre guide pour dimensionner Proxmox VE sur un serveur dédié 40 coeurs couvre ce cas.

Prérequis : un serveur dédié avec KVM, Debian 13 ou Ubuntu LTS

• Un serveur dédié bare metal pour profiter des machines virtuelles : Incus crée ses VM avec QEMU et KVM, ce qui exige la virtualisation matérielle (Intel VT-x ou AMD-V) activée dans le BIOS et le périphérique /dev/kvm présent sur l'hôte. Sur un VPS Linux, les conteneurs fonctionnent, mais les VM dépendent de la virtualisation imbriquée, rarement activée chez les hébergeurs. Les serveurs dédiés ElypseCloud en bi-Xeon E5-2620 v4 (16 coeurs, 32 threads) ou bi-Xeon Gold 6230 (40 coeurs, 80 threads), de 32 à 256 Go de RAM ECC, sont taillés pour ce type de découpage ;
• Debian 12 ou 13, Ubuntu 22.04, 24.04 ou 26.04 LTS, en amd64 ou arm64 : ce sont les distributions prises en charge par le dépôt Zabbly. Debian 13 est le choix le plus simple, son noyau 6.12 respectant le prérequis d'Incus 7. Sur Ubuntu 22.04 ou 24.04, vérifiez la version du noyau avec uname -r avant de choisir la branche 7.x ;
• Un stockage dédié aux instances : une partition ou un disque vide pour un pool ZFS ou Btrfs, les deux backends recommandés par la documentation. Un pool en fichier loop suffit pour tester, pas pour la production ;
• Un accès SSH avec sudo et un premier durcissement de l'hôte : sécuriser un serveur dédié, les premiers réglages et sécuriser SSH. Toute personne membre du groupe incus-admin est l'équivalent de root sur la machine.

Contrôlez la virtualisation matérielle avant d'aller plus loin :

grep -cE 'vmx|svm' /proc/cpuinfo
ls -l /dev/kvm

La première commande doit renvoyer un nombre supérieur à zéro (le nombre de threads CPU exposant VT-x ou AMD-V), la seconde doit afficher le périphérique. S'il manque, activez la virtualisation dans le BIOS ou l'UEFI du serveur.

Installer Incus depuis le dépôt Zabbly sur Debian et Ubuntu

Zabbly est le dépôt maintenu par Stéphane Graber, le mainteneur d'Incus. Il publie des paquets .deb pour Debian 12 et 13 et pour Ubuntu 22.04, 24.04 et 26.04, en quatre branches : stable (dernière version mensuelle, 7.6 au moment d'écrire), lts-7.0, lts-6.0 et daily (builds de développement non testés). Pour un serveur de production, prenez lts-7.0. Les commandes suivantes s'exécutent en root.

Récupérez la clé de signature et contrôlez son empreinte, qui doit être exactement 4EFC 5906 96CB 15B8 7C73 A3AD 82CC 8797 C838 DCFD :

curl -fsSL https://pkgs.zabbly.com/key.asc | gpg --show-keys --fingerprint
mkdir -p /etc/apt/keyrings/
curl -fsSL https://pkgs.zabbly.com/key.asc -o /etc/apt/keyrings/zabbly.asc

Déclarez le dépôt au format Deb822. Le nom du fichier et l'URL reprennent la branche choisie, ici lts-7.0 (remplacez par stable pour suivre les versions mensuelles) :

sh -c 'cat <<EOF > /etc/apt/sources.list.d/zabbly-incus-lts-7.0.sources
Enabled: yes
Types: deb
URIs: https://pkgs.zabbly.com/incus/lts-7.0
Suites: $(. /etc/os-release && echo ${VERSION_CODENAME})
Components: main
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/zabbly.asc

EOF'

Installez ensuite le paquet. Zabbly en propose cinq : incus (daemon complet, conteneurs et VM, avec tout le nécessaire pour QEMU), incus-base (conteneurs uniquement, plus léger), incus-client (le CLI seul, pour administrer des serveurs distants), incus-extra (outils annexes dont incus-migrate, incus-benchmark et, sur la branche LTS, lxd-to-incus) et incus-ui-canonical (l'interface web) :

apt-get update
apt-get install incus
incus --version

Donnez enfin à votre compte d'administration le droit de piloter le daemon sans sudo, puis rechargez les groupes de la session courante :

adduser votre_utilisateur incus-admin
newgrp incus-admin

Le groupe incus (sans suffixe) existe aussi : il donne un accès restreint, limité aux projets confiés à l'utilisateur, utile pour un développeur qui ne doit pas pouvoir toucher à l'hôte.

Et sans Zabbly ? Debian 13 livre nativement Incus 6.0.4 LTS (apt install incus, ou incus-base pour les conteneurs seuls), avec Incus 7.0.2 LTS dans trixie-backports. Ubuntu 24.04 propose Incus 6.0.0 dans universe ; pour les VM, ajoutez apt install qemu-system. Les paquets Zabbly ont l'avantage de suivre les versions 7.0.x au plus près, avec la clé et le dépôt sous le contrôle direct du mainteneur.

Initialiser Incus : pool de stockage, pont incusbr0 et accès distant

Avant de créer la moindre instance, Incus a besoin d'un pool de stockage et d'un réseau. L'assistant interactif pose une dizaine de questions, chacune avec une valeur par défaut raisonnable :

incus admin init

Les réponses qui comptent sur un serveur dédié :

• Would you like to use clustering? : no pour un serveur unique. Un cluster se forme plus tard, sans réinstaller ;
• Name of the new storage pool : default. Name of the storage backend : zfs ou btrfs, puis répondez yes à Would you like to use an existing empty block device? et indiquez la partition ou le disque réservé (par exemple /dev/nvme1n1). Avec un disque dédié, vous obtenez les snapshots instantanés, les copies rapides et les quotas par instance. Le backend dir fonctionne partout mais n'offre rien de tout cela ;
• Would you like to create a new local network bridge? : yes, nom incusbr0, IPv4 en auto avec NAT activé. Incus génère un sous-réseau privé libre, lance un dnsmasq qui sert le DHCP et le DNS des instances, et fait du NAT vers l'IP publique du serveur. IPv6 : auto si votre serveur en dispose, none sinon ;
• Would you like the server to be available over the network? : no par défaut. Le daemon n'écoute alors que sur une socket Unix locale, ce qui est la configuration la plus sûre. Activez-le uniquement pour l'interface web ou un client distant, et filtrez le port 8443 au pare-feu ;
• Would you like stale cached images to be updated automatically? : yes, les images téléchargées restent à jour.

Pour un environnement de test jetable, incus admin init --minimal applique les valeurs par défaut sans poser de question, mais avec le backend dir. Pour reproduire la même configuration sur plusieurs serveurs dédiés, incus admin init --preseed lit un fichier YAML sur l'entrée standard, ce qui se glisse dans un playbook Ansible.

Vérifiez le résultat :

incus storage list
incus network list
incus profile show default

Le profil default contient deux périphériques hérités par toutes les instances : un disque root sur le pool default et une carte réseau eth0 branchée sur incusbr0.

Si vous voulez l'interface web, installez incus-ui-canonical, activez l'écoute HTTPS et ouvrez https://IP_DU_SERVEUR:8443 en acceptant le certificat auto-signé. Restreignez ce port aux IP de vos postes d'administration : avec cette API, un certificat de confiance vaut un accès root à l'hôte, comme l'a rappelé la faille critique CVE-2026-112816 de LXD en octobre 2026.

apt-get install incus-ui-canonical
incus config set core.https_address :8443

Créer un premier conteneur système

Un conteneur système Incus ressemble à une VM allégée : il démarre un init complet (systemd sur Debian), on s'y connecte en shell, on y installe des paquets avec apt, on y fait tourner plusieurs services. Il partage le noyau de l'hôte, donc il démarre en une seconde et ne consomme que la mémoire réellement utilisée. Listez les images disponibles sur le serveur communautaire, puis lancez un conteneur Debian 13 :

incus image list images: debian
incus launch images:debian/13 web1
incus list

Le premier lancement télécharge l'image (quelques dizaines de Mo pour Debian), les suivants partent du cache local et prennent moins de deux secondes. incus list affiche l'état, l'adresse IPv4 attribuée par le DHCP d'incusbr0 et le type d'instance. Entrez dans le conteneur et installez un service :

incus exec web1 -- bash
apt update && apt install -y nginx
exit

Les limites de ressources se fixent à la création ou à chaud, sans redémarrage pour les conteneurs :

incus launch images:debian/13 db1 --config limits.cpu=2 --config limits.memory=4GiB
incus config set web1 limits.memory=2GiB
incus config show web1

Les snapshots, les copies et les transferts de fichiers se font depuis l'hôte :

incus snapshot create web1 avant-maj
incus snapshot restore web1 avant-maj
incus copy web1 web2
incus file push nginx.conf web1/etc/nginx/nginx.conf
incus file pull web1/var/log/nginx/access.log .

Arrêt et suppression : incus stop web1, puis incus delete web1 (ajoutez --force pour supprimer une instance encore allumée). Pour faire tourner Docker à l'intérieur d'un conteneur système, activez security.nesting=true sur ce conteneur ; en revanche un conteneur ne peut pas charger de module noyau, c'est l'hôte qui s'en charge.

Créer une première machine virtuelle QEMU/KVM

La même commande avec --vm crée une machine virtuelle. Incus télécharge alors la variante « virtual-machine » de l'image, qui embarque l'agent incus-agent : c'est lui qui rend incus exec, incus file et la remontée d'adresse IP possibles dans une VM, exactement comme dans un conteneur. Les VM reçoivent par défaut 1 vCPU et 1 Gio de RAM, trop peu pour un usage réel, donc fixez les limites et la taille du disque dès la création :

incus launch images:debian/13 vm1 --vm --config limits.cpu=4 --config limits.memory=8GiB --device root,size=40GiB
incus list vm1
incus exec vm1 -- bash

Pour agrandir le disque d'une VM existante, surchargez le périphérique root hérité du profil puis redémarrez :

incus config device override vm1 root size=60GiB
incus restart vm1

Deux consoles sont disponibles pour déboguer un démarrage, y compris quand l'agent ne répond pas : la console série, et pour les VM une console graphique SPICE qui demande un client remote-viewer (paquet virt-viewer) ou spicy sur votre poste :

incus console vm1
incus console vm1 --show-log
incus console vm1 --type vga

Incus passe le processeur de l'hôte à la VM sans émulation : un serveur dédié amd64 fait tourner des VM amd64, pas arm64. Les images du serveur images: couvrent en variante VM Debian, Ubuntu, Alpine, Fedora, Rocky Linux, AlmaLinux et Arch. Pour un autre système (Windows Server pour un serveur de jeu ou un logiciel métier, FreeBSD), on importe sa propre image ISO en positionnant la propriété image.os adéquate. Pour un seul serveur Windows, un VPS Windows reste plus simple qu'une VM à administrer soi-même.

Réseau : pont NAT, exposition de ports et bridge physique

Avec le pont incusbr0 créé à l'initialisation, chaque instance reçoit une IP privée et sort vers Internet en NAT derrière l'IP publique du serveur. Rien n'est joignable depuis l'extérieur tant que vous ne l'avez pas décidé, ce qui est le bon défaut sur un serveur dédié exposé. Trois mécanismes permettent ensuite d'ouvrir ou de contourner ce NAT.

1. Le périphérique proxy, le plus simple pour publier un port d'un conteneur sur l'IP publique. Incus relaie la connexion lui-même :

incus config device add web1 http proxy listen=tcp:0.0.0.0:80 connect=tcp:127.0.0.1:80
incus config device add web1 https proxy listen=tcp:0.0.0.0:443 connect=tcp:127.0.0.1:443

Pour une VM, le mode relais n'est pas disponible : ajoutez nat=true, qui remplace le relais par une règle de NAT (l'adresse source du client est alors conservée). Ce mode exige que l'hôte soit la passerelle de l'instance, ce qui est le cas avec incusbr0 :

incus config device add vm1 game proxy listen=udp:0.0.0.0:30120 connect=udp:0.0.0.0:30120 nat=true

2. Les network forwards, qui associent une IP publique du serveur à une instance et redirigent des ports au niveau du réseau géré, sans processus relais. Fixez d'abord une IP stable à l'instance, puis créez le forward :

incus config device override web1 eth0 ipv4.address=10.42.0.10
incus restart web1
incus network forward create incusbr0 203.0.113.10
incus network forward port add incusbr0 203.0.113.10 tcp 80,443 10.42.0.10
incus network forward list incusbr0

Remplacez 203.0.113.10 par l'IP publique du serveur et 10.42.0.10 par une adresse du sous-réseau d'incusbr0 (visible dans incus network show incusbr0). Les forwards ne fonctionnent que sur les réseaux gérés de type bridge ou OVN.

3. Le bridge physique, quand vos instances doivent avoir leur propre IP publique. Les serveurs dédiés ElypseCloud acceptent des adresses IP supplémentaires ; une fois attribuées, créez sur l'hôte un pont br0 qui englobe l'interface physique, puis branchez les instances dessus. Sur Debian avec ifupdown (paquet bridge-utils, remplacez eno1 et les adresses par les vôtres) :

auto br0
iface br0 inet static
    bridge_ports eno1
    bridge_stp off
    bridge_fd 0
    address 203.0.113.10
    netmask 255.255.255.0
    gateway 203.0.113.1

Sur Ubuntu avec Netplan, dans /etc/netplan/01-bridge.yaml :

network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: false
  bridges:
    br0:
      interfaces: [eno1]
      addresses: [203.0.113.10/24]
      routes:
        - to: default
          via: 203.0.113.1
      nameservers:
        addresses: [9.9.9.9]
      parameters:
        stp: false
        forward-delay: 0

Appliquez avec netplan try (qui annule tout seul si vous perdez la main) puis netplan apply. Attachez ensuite une instance au pont physique en remplaçant sa carte eth0 héritée du profil par une carte non gérée, et configurez l'IP supplémentaire dans le système invité :

incus config device add vm1 eth0 nic nictype=bridged parent=br0

Dans cette configuration, Incus ne gère ni le DHCP ni le DNS de l'instance : vous fournissez tout, comme pour une machine physique. Une interface macvlan (nictype=macvlan parent=eno1) évite de créer le pont, au prix d'une limite à connaître : l'hôte et ses instances ne peuvent pas se parler directement. Cette opération coupe le réseau quelques secondes : gardez une console de secours ouverte, et relisez notre guide diagnostic réseau en 30 secondes avant de toucher à l'interface principale.

Pare-feu et Docker. Incus pose ses règles dans sa propre table nftables, mais une règle de blocage posée ailleurs l'emporte. Avec UFW, autorisez explicitement le pont :

ufw allow in on incusbr0
ufw route allow in on incusbr0
ufw route allow out on incusbr0

Docker installé sur le même hôte passe la politique FORWARD à DROP et coupe la sortie Internet des instances. La documentation Incus propose soit de faire tourner Docker dans un conteneur Incus, soit d'activer "ip-forward-no-drop": true dans /etc/docker/daemon.json, soit d'ajouter des règles d'acceptation dans la chaîne DOCKER-USER pour incusbr0. Notre comparatif Podman contre Docker détaille ce comportement réseau de Docker.

Migrer depuis LXD avec lxd-to-incus

Si votre serveur tourne déjà sous LXD (en snap sur Ubuntu, le plus souvent), l'outil lxd-to-incus convertit l'installation en place : base de données, pools de stockage, réseaux, profils et instances passent à Incus sans export ni réimport. Trois points à connaître avant de lancer :

• L'outil n'existe que dans les branches LTS. Il a été retiré du développement d'Incus avec la version 7.2 (26 juin 2026, changelog « Remove LXD to Incus logic »). Il reste livré dans Incus 6.0.x et 7.0.x : paquet incus-extra de la branche Zabbly lts-7.0, paquet incus-extra de Debian 13 (Incus 6.0.4), incus-tools dans trixie-backports (7.0.2). Avec la branche stable de Zabbly, il n'est plus là ;
• LXD 5.21.x au maximum. Au-delà, l'outil refuse avec LXD version is newer than maximum version "5.21.99". L'option --ignore-version-check force la migration depuis LXD 6.x, mais les mainteneurs la qualifient de terrain inconnu : testez sur une copie, ou passez par la méthode côte à côte décrite plus bas ;
• Les instances doivent être arrêtées, l'opération est destructive pour LXD et le nom du pont (lxdbr0) est conservé, tout comme le passage du suffixe DNS .lxd à .incus pour les noms d'instances. Faites un export complet avant : sauvegardes et haute disponibilité sur serveur dédié.

Procédure, Incus LTS installé mais pas initialisé (pas d'incus admin init), le service simplement démarré :

apt-get install incus incus-extra
incus info
lxc info
lxc stop --all
lxd-to-incus

L'outil exécute d'abord une validation à blanc (versions, pools, réseaux, chemins) et n'écrit rien si elle échoue. Il arrête ensuite LXD, déplace la base de données et le stockage, puis démarre Incus. Passez --yes pour une exécution sans confirmation dans un script. Une fois incus list satisfaisant, retirez LXD et donnez l'accès à vos administrateurs :

snap remove --purge lxd
usermod -aG incus-admin votre_utilisateur
incus config set web1 boot.autostart=true

Vérifiez les règles de pare-feu qui citaient lxdbr0 et les scripts qui résolvaient nom.lxd. Pour un LXD 6.x, ou pour changer de serveur en même temps, la méthode recommandée par le mainteneur est de faire tourner les deux daemons côte à côte et de transférer instance par instance avec incus copy, ou de reconstruire les instances depuis leurs exports avec incus import. Les administrateurs qui ont migré des clusters de production rapportent que la copie de la configuration client LXD vers Incus demande d'ajuster le protocole dans ~/.config/incus/config.yml, le format des jetons de confiance ayant changé.

Exploitation au quotidien : démarrage automatique, snapshots, sauvegardes

Quelques réglages d'instance évitent les mauvaises surprises après un redémarrage du serveur dédié ou une mise à jour ratée :

incus config set web1 boot.autostart=true
incus config set web1 boot.autostart.priority=10
incus config set db1 snapshots.schedule="0 3 * * *"
incus config set db1 snapshots.expiry=7d
incus export db1 /srv/backups/db1.tar.gz --optimized-storage

boot.autostart relance l'instance au démarrage du daemon, la priorité la plus haute partant en premier (utile pour démarrer la base de données avant le serveur de jeu qui en dépend). Le planning de snapshots prend une expression cron ou un raccourci comme @daily, et snapshots.expiry purge les anciens. incus export produit une archive restaurable sur n'importe quel serveur Incus avec incus import, y compris sur un pool d'un autre type si vous omettez --optimized-storage. Copiez ces archives hors du serveur, chiffrées : chiffrer et externaliser ses sauvegardes.

Pour les mises à jour, Incus se gère comme n'importe quel paquet apt : la branche lts-7.0 ne reçoit que des correctifs, donc unattended-upgrades peut les appliquer (automatiser les mises à jour de sécurité). Les instances, elles, se mettent à jour de l'intérieur, chacune avec son propre apt, ce qui est précisément l'intérêt d'avoir isolé chaque service dans son conteneur.

Conclusion

Incus donne à un serveur dédié la souplesse d'un hyperviseur sans en faire une appliance : la distribution reste la vôtre, chaque service vit dans un conteneur système ou une VM selon qu'il tolère ou non de partager le noyau, et tout se pilote depuis un CLI scriptable et une API REST. L'installation depuis le dépôt Zabbly en branche LTS, un pool ZFS ou Btrfs sur un disque dédié et le pont NAT par défaut suffisent pour démarrer ; les forwards, le périphérique proxy ou un bridge physique avec des IP supplémentaires ouvrent ensuite ce qu'il faut vers Internet. Pour quitter LXD, lxd-to-incus fait le travail en place tant que vous restez en LTS et sous LXD 5.21.

Si vous hésitez encore entre un serveur dédié et un VPS pour ce type de découpage, notre comparatif serveur dédié bare metal ou VPS met les deux côte à côte : la réponse courte est que les conteneurs tournent partout, mais que les VM Incus réclament le KVM d'un serveur physique.