Incus vs Docker : quelles différences et quand choisir quoi

Incus et Docker ne font pas le même métier. Docker lance des conteneurs applicatifs (un processus, une image, jetable) pour empaqueter et distribuer une application. Incus lance des conteneurs système (une distribution Linux complète, persistante) et des machines virtuelles, façon machine légère. Ce guide explique la différence fondamentale, la pose dans un tableau clair, et indique quel outil choisir selon le besoin. Pour qui hésite entre les deux ou vient de Docker.

Ce que vous allez apprendre

• La différence fondamentale : conteneur applicatif vs conteneur système.
• Un tableau comparatif Incus / Docker.
• Quel outil choisir selon votre cas d'usage.
• Que Incus sait aussi lancer des images Docker (OCI).

La différence fondamentale

Tout se joue sur ce que contient un conteneur.

Un conteneur Docker exécute un seul processus : votre application (un serveur web, une API, une base de données). L'image est construite en couches, le conteneur est éphémère (on le jette et on le recrée), et il ne contient que le strict nécessaire pour faire tourner ce processus. Pas d'init, pas de services système, pas de SSH.

Un conteneur Incus exécute un système complet : une distribution Linux avec son init (systemd, openrc), ses services, ses utilisateurs, ses logs. Il est persistant : on s'y connecte, on l'administre, on le sauvegarde par snapshot, comme une petite machine. C'est la différence entre « emballer une application » et « provisionner une machine ».

Deux philosophies, pas un gagnant

Ce n'est pas « Incus meilleur que Docker » ni l'inverse. Ce sont deux outils pour deux besoins. Beaucoup d'infrastructures utilisent les deux : Incus pour les machines, Docker pour les applications qui tournent dessus.

Tableau comparatif

Critère	Docker	Incus
Type de conteneur	applicatif (1 processus)	système (distribution complète)
Machines virtuelles	non	oui (QEMU/KVM)
Durée de vie	éphémère	persistante
Image	en couches (Dockerfile)	distribution (remote images:)
Accès interactif	docker exec, logs	incus shell, comme une machine
Init / services	non (1 process)	oui (systemd, openrc)
Cas typique	déployer une app	provisionner un serveur Linux

Glissez pour voir

Ce premier tableau compare les natures. Pour choisir, il faut aussi comparer le workflow applicatif, car « Incus lance des images OCI » ne signifie pas qu'il remplace la chaîne Docker. Les quatre capacités ci-dessous sont souvent confondues en une seule, alors qu'elles se décident séparément.

Capacité	Docker	Incus
Exécuter une image OCI	oui, c'est son métier	oui, depuis la 6.3
Construire une image	oui, Dockerfile et BuildKit	non, aucun équivalent
Décrire un ensemble multi-services	oui, Compose	non, profils et projets ne couvrent pas ce besoin
S'intégrer à une CI ou à Kubernetes	écosystème complet	clustering Incus natif, hors écosystème Kubernetes

Glissez pour voir

Quel outil choisir

Le bon réflexe : partir du besoin, pas de l'outil.

Choisissez Docker (ou un autre moteur applicatif) quand vous voulez empaqueter et distribuer une application : un microservice, une stack web reproductible, un build de CI/CD. L'écosystème qui l'entoure, de Docker Hub à Compose, est taillé pour ça.

Choisissez Incus quand vous voulez une machine Linux : un serveur de test, un environnement de développement complet, un homelab, une VM pour un autre noyau ou Windows. Vous gérez l'instance comme un système, avec snapshots et API, sans la lourdeur d'un hyperviseur complet comme Proxmox.

Incus sait aussi lancer des images Docker

La frontière n'est pas étanche : depuis la version 6.3, Incus peut lancer des images OCI (le format de Docker) en plus de ses conteneurs système. Aucun remote OCI n'est préconfiguré, il s'ajoute d'abord :

incus remote add docker https://docker.io --protocol=oci
incus launch docker:nginx web

L'image démarre comme un conteneur applicatif, marqué CONTAINER (APP) dans incus list, avec sa propre adresse IP sur incusbr0. Un incus exec web -- nginx -v y répond comme dans n'importe quelle instance Incus.

Une vérification s'impose avant d'essayer : le support OCI date de la 6.3, donc de la branche de fonctionnalités. Debian 13 livre Incus 6.0.4, la branche LTS, qui lui est antérieure. Sur une installation Debian standard, incus --version répond 6.0.4 et la commande ci-dessus ne peut pas fonctionner : il faut passer au dépôt amont.

Une fois cette condition remplie, vous exécutez de l'applicatif sans installer Docker, sur la même plateforme que vos conteneurs système et vos VMs. Le détail dans le guide lancer des conteneurs OCI avec Incus.

Docker et Incus sur le même hôte : le réseau casse-t-il vraiment ?

C'est le piège le plus cité, et il est conditionnel, pas automatique. Le démon Docker peut mettre la politique de la chaîne FORWARD à DROP, ce qui empêche l'hôte de router : les conteneurs Incus obtiennent alors une IP sur incusbr0 sans pouvoir sortir. Mais Docker ne le fait que dans un cas précis, et Incus s'en protège désormais lui-même.

Docker ne pose cette politique que lorsqu'il active l'IP forwarding lui-même. S'il trouve net.ipv4.ip_forward déjà à 1, il n'y touche pas. Or Incus active ce réglage à son initialisation : sur une machine où Incus est installé avant Docker, la chaîne reste en ACCEPT et le problème ne survient jamais. Ce comportement concerne par ailleurs le backend iptables, resté le défaut ; le backend nftables introduit dans Docker 29.0.0, expérimental et à activer explicitement, n'active pas l'IP forwarding de lui-même.

Et même sous policy DROP, un conteneur Incus récent garde son réseau. Incus inscrit ses propres règles ACCEPT pour incusbr0 dans la chaîne FORWARD, et elles survivent au redémarrage du démon Docker. Le correctif historique par DOCKER-USER devient alors inutile. Il reste utile sur les versions plus anciennes d'Incus ou de LXD, qui ne posaient pas ces règles : c'est de là que vient la consigne.

Le diagnostic, avant tout correctif

Trois commandes suffisent à savoir si vous êtes dans le cas décrit, et elles évitent de modifier un pare-feu pour rien :

iptables -L FORWARD -n | head -1          # la politique : ACCEPT ou DROP
docker info --format '{{.FirewallBackend}}'  # iptables ou nftables
sysctl net.ipv4.ip_forward                # 1 si quelqu'un l'a déjà activé

Si la politique est ACCEPT, il n'y a rien à corriger. Si elle est DROP, vérifiez d'abord que vos conteneurs perdent réellement le réseau avec un incus exec <nom> -- ping -c 2 9.9.9.9 : la présence du DROP ne suffit pas à conclure, puisque les règles d'Incus peuvent laisser passer le trafic.

Les correctifs, du plus propre au plus radical

Si le blocage est confirmé, la configuration de Docker est le levier le plus net : "ip-forward-no-drop": true dans /etc/docker/daemon.json lui demande de ne pas toucher à la politique. Le correctif par règles, sur les versions d'Incus qui n'en posent pas, autorise explicitement le pont :

iptables -I DOCKER-USER -i incusbr0 -j ACCEPT
iptables -I DOCKER-USER -o incusbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

La séparation reste la solution la plus durable : faire tourner l'un dans une instance de l'autre supprime la question du pare-feu partagé.

Peut-on remplacer Docker par Incus

En partie. Pour un homelab ou un poste de développement, lancer ses quelques services applicatifs en OCI dans Incus évite d'installer Docker en plus, et tout se gère au même endroit. En revanche, pour un usage applicatif intensif (build d'images via Dockerfile, Compose multi-services, intégration Kubernetes), l'écosystème Docker reste plus complet et mieux outillé. Incus complète Docker plus qu'il ne le remplace totalement.

À retenir

• Docker = conteneurs applicatifs (1 processus, éphémère) pour empaqueter une application.
• Incus = conteneurs système (distribution complète, persistante) et VMs pour provisionner des machines.
• On choisit selon le besoin : emballer une app (Docker) ou provisionner une machine (Incus).
• Depuis la 6.3, Incus lance aussi des images OCI (docker:), marquées CONTAINER (APP) ; la branche LTS 6.0 de Debian 13 ne les prend pas en charge.
• Les deux sont souvent complémentaires, pas concurrents.

FAQ : questions fréquentes sur Incus vs Docker

Quelle est la différence fondamentale entre Incus et Docker ?

Docker lance des conteneurs applicatifs : un seul processus, une image en couches, éphémère, pour empaqueter une application. Incus lance des conteneurs système : une distribution Linux complète avec init et services, persistante, qu'on administre comme une machine.

Incus ou Docker : lequel choisir ?

Choisissez Docker pour empaqueter et distribuer une application : microservice, stack web reproductible, pipeline CI/CD, avec son écosystème Docker Hub, Compose et Kubernetes. Choisissez Incus pour une machine Linux : serveur de test, environnement de développement complet, homelab, ou une VM.

Peut-on remplacer Docker par Incus ?

En partie. Pour un homelab ou un poste de développement, lancer quelques services en OCI dans Incus évite d'installer Docker. Mais pour un usage applicatif intensif (build via Dockerfile, Docker Compose, intégration Kubernetes), l'écosystème Docker reste plus complet.

Incus peut-il lancer des images Docker ?

Oui, depuis la version 6.3. On ajoute le remote OCI avec incus remote add docker https://docker.io --protocol oci, puis on lance une image avec incus launch docker:nginx. Le conteneur apparaît avec le type CONTAINER APP. Incus consomme les images OCI mais ne les construit pas via Dockerfile.

Pour aller plus loin

• Gestion des conteneurs et des VM avec Incus : Le registre d'images, la configuration et les commandes qui reviennent tous les jours.
• Réseau Incus : Le modèle réseau d'Incus, qui n'a pas grand-chose à voir avec les réseaux bridge de Docker.
• Profils et projets Incus : L'équivalent, chez Incus, de ce que vous factorisez ailleurs dans un fichier Compose.

×

📖 Voir la documentation →