Résumer cet article :
Portainer fait presque partie des meubles dans beaucoup de home labs. On l’installe sur un NAS, un Raspberry Pi, un mini PC ou dans une VM Proxmox, et cinq minutes plus tard on a une interface Web pour lancer, arrêter, mettre à jour et surveiller ses conteneurs Docker.
En domotique, c’est bien pratique. Home Assistant tourne très bien en conteneur, et autour on retrouve souvent Mosquitto, Zigbee2MQTT, Node-RED, ESPHome, Frigate, InfluxDB, Grafana, AdGuard Home, Nginx Proxy Manager… La liste s’allonge vite.
Le 11 septembre 2026, Portainer a annoncé un changement de cap : la version 3.0 sera pensée d’abord pour Kubernetes, et la Community Edition restera sur la branche 2.x.
Faut-il désinstaller Portainer demain matin ? Non. Mais c’est le bon moment pour aller voir ce qui pousse dans le jardin du voisin.
Portainer 3.0 : cap sur Kubernetes
C’est Neil Cresswell, le CEO de Portainer, qui a détaillé la nouvelle stratégie dans un billet de blog. Et on ne parle pas d’un simple changement de numéro de version.
Portainer 2.45 LTS, sortie en août, est la dernière version de la branche 2.x. La 3.x sera développée avec une priorité : Kubernetes.
L’éditeur l’explique assez franchement. L’écart entre Docker et Kubernetes s’est tellement creusé qu’il n’est plus tenable de tout développer en parallèle pour Docker, Podman, Swarm et Kubernetes dans une même base de code. Ses clients entreprise réclament des politiques de sécurité, de l’observabilité, du GitOps, de quoi faire tourner des workloads IA… Tout ça repose sur des mécanismes propres à Kubernetes (network policies, admission controllers) que Docker n’a pas.
Plusieurs produits sont en préparation autour de cet écosystème : Portainer-Run, Portainer-IDP, Portainer-Command, Portainer-Operations ou encore Portainer-AiGrid. Rien que les noms donnent le ton.
Quand on veut juste faire tourner Zigbee2MQTT et une poignée de services sur un mini PC, on est assez loin du besoin de départ.
Portainer CE n’est pas mort pour autant
Certains titres parus après l’annonce étaient franchement alarmistes, alors mettons les choses au clair : Portainer n’abandonne pas Docker et ne débranche pas la Community Edition du jour au lendemain.
La CE reste sur la branche 2.x et continuera de recevoir des correctifs de sécurité et des corrections de bugs. Portainer promet aussi d’y rétroporter les nouveautés de la 3.x qui ont un équivalent dans l’API Docker. La 2.45 LTS est maintenue jusqu’en mai 2027.
Si votre serveur tourne bien aujourd’hui avec Portainer CE, rien ne presse.
Par contre, il n’y aura pas de Portainer CE 3.0. Pour profiter gratuitement de la 3.x, il faudra passer par le programme « 3 Nodes Free », c’est-à-dire l’édition Business offerte jusqu’à trois nœuds. Les environnements Docker, Swarm et Podman y restent gérés, mais ils passent au second plan dans l’interface, et les nouvelles fonctions arriveront d’abord, voire uniquement, côté Kubernetes.
Aujourd’hui, la différence paraît mince. Dans deux ou trois ans, je pense qu’elle se verra beaucoup plus.
Pourquoi ça concerne la domotique
Pour un home lab, Kubernetes est le plus souvent démesuré.
Prenez un serveur classique avec Home Assistant, Mosquitto, Zigbee2MQTT, Node-RED, Frigate et deux ou trois outils de supervision. Docker Compose fait le travail : un fichier par application, les données dans des volumes, et quelques commandes pour tout sauvegarder ou tout reconstruire.
Monter un cluster Kubernetes juste pour garder les dernières fonctions d’une interface d’admin, c’est un peu sortir la pelleteuse pour planter trois tulipes.
Portainer le reconnaît d’ailleurs : Docker reste pris en charge en 3.x, mais l’effort de développement ira vers Kubernetes. Si vous n’avez aucune intention d’y passer, la question se pose : existe-t-il des interfaces pensées d’abord pour Docker et Docker Compose ?
Oui. Et plusieurs ont fait de gros progrès ces derniers mois.
Arcane : sans doute le remplaçant le plus convaincant aujourd’hui
S’il ne fallait en tester qu’un en 2026, ce serait celui-là.
Arcane ressemble à ce qu’on attendrait d’un Portainer moderne : conteneurs, images, volumes, réseaux et projets Docker Compose dans une interface Web, plus la gestion de machines distantes grâce à un agent.
Côté authentification, on trouve OIDC, les passkeys et la double authentification. Il y a aussi une API, la gestion des mises à jour d’images et un scanner de vulnérabilités qui affiche les risques associés à chaque image.

Et ça bouge vite. Les versions 2.10 à 2.14 sont sorties en moins d’un mois. La 2.14.0 date du 26 septembre 2026, quelques jours avant que j’écrive ces lignes. Elle ajoute des actions groupées sur les vulnérabilités, une vue des risques de sécurité retravaillée et un onglet qui affiche les processus de chaque conteneur.
L’installation est simple : Arcane tourne lui-même dans un conteneur et accède au socket Docker de l’hôte. Comme avec Portainer, gardez en tête que l’accès au socket revient à donner les droits root sur la machine. On évite donc d’exposer l’interface sur Internet sans précaution.
Si je devais remplacer Portainer demain dans mon home lab, c’est le premier que j’installerais.
Dockge : la simplicité avant tout
Dockge est l’autre nom qui revient sans arrêt dans les discussions.
Il est signé Louis Lam, le développeur d’Uptime Kuma, et sa philosophie est différente. Il n’essaie pas de refaire tout Portainer : il se concentre sur Docker Compose. On crée, modifie, démarre, arrête et met à jour ses stacks depuis une interface très dépouillée.
Ce que j’apprécie le plus, c’est que les fichiers compose.yaml restent de vrais fichiers sur le disque (dans /opt/stacks par défaut), et pas des entrées dans une base de données interne. On peut les ouvrir avec n’importe quel éditeur ou lancer un bon vieux docker compose up -d depuis le terminal.
Depuis la version 1.4, il sait aussi se connecter à d’autres instances Dockge pour afficher les stacks de plusieurs machines dans la même interface.
Sur un Raspberry Pi ou un mini PC qui fait tourner une dizaine de services domotiques, c’est franchement agréable.
Le bémol, c’est le rythme de développement. La dernière version stable, la 1.5.0, date de mars 2025. Ça ne l’empêche pas de fonctionner, mais pour une nouvelle installation que je compte faire vivre plusieurs années, j’hésiterais à en faire mon premier choix.
Komodo : quand le home lab compte plusieurs serveurs
Si votre home lab a pris de l’embonpoint, Komodo mérite le détour.
Il est conçu pour déployer et gérer plusieurs serveurs. C’est un projet open source sous licence GPLv3, sans limite sur le nombre de machines connectées.
Il gère Docker Compose, sait importer des stacks existantes et récupérer les configurations depuis un dépôt Git. Vous pouvez donc décrire une stack dans Git, la déployer automatiquement sur un serveur et la redéployer à chaque modification du dépôt. Et si vous préférez garder vos fichiers Compose directement sur la machine, à l’ancienne, c’est possible aussi.

Komodo 2 a ajouté la gestion de Docker Swarm, la double authentification (TOTP ou passkey) pour les comptes locaux, la possibilité de lier plusieurs méthodes de connexion (locale, OIDC, GitHub…) à un même compte, et des terminaux distants revus. Côté automatisation, il était déjà bien fourni.
Un exemple concret : un mini PC pour la domotique, un second serveur pour Frigate et les caméras, un NAS avec quelques services et un VPS à l’extérieur. Komodo centralise tout ça.
Il est plus long à prendre en main que Dockge, évidemment. Mais il est aussi beaucoup plus puissant.
Dockhand : le nouveau venu à surveiller
Dernier de la liste : Dockhand. Sa première version date de décembre 2025, et il avance à une vitesse impressionnante.
Il gère les conteneurs, les stacks Compose, plusieurs environnements Docker, les dépôts Git et les webhooks. On peut aussi parcourir les volumes et les fichiers à l’intérieur des conteneurs, visualiser les connexions réseau ou planifier des opérations de maintenance.
Il se démarque surtout sur la sécurité, avec des fonctions qu’on voit rarement dans un outil de self-hosting. Il analyse les images avec Grype et Trivy pour repérer les vulnérabilités connues, et peut scanner une nouvelle image avant de remplacer un conteneur en cours d’exécution. C’est pratique pour éviter qu’une mise à jour automatique installe en pleine nuit une image truffée de failles connues.

La version 1.0.50 est sortie le 30 septembre 2026.
Attention à la licence, en revanche. Dockhand est sous Business Source License 1.1 : il est gratuit pour un usage personnel ou interne en entreprise, mais ce n’est pas un logiciel libre au sens d’un projet GPL ou MIT. On ne peut pas, par exemple, le revendre comme service hébergé. Le code passera sous licence Apache 2.0 en 2029.
Alors, faut-il quitter Portainer ?
Pas forcément.
Si vous avez Portainer CE 2.45 sur un serveur Docker à la maison et que tout tourne, je ne vois aucune raison de tout casser. La branche est maintenue et les correctifs continueront d’arriver.
Mais l’annonce a changé ma façon de voir l’outil sur le long terme. Portainer a choisi sa voie : Kubernetes et l’entreprise. Je le comprends très bien du point de vue de l’éditeur. Ce n’est simplement pas la voie de quelqu’un qui a un mini PC et une vingtaine de conteneurs dans son placard technique.
Pour ce profil-là, voici mon avis :
- Arcane est aujourd’hui ce qui se rapproche le plus d’un Portainer moderne et activement développé ;
- Dockge reste excellent si vous voulez une interface minimaliste autour de Docker Compose et que le ralentissement du développement ne vous gêne pas ;
- Komodo prend tout son sens dès qu’on gère plusieurs serveurs ou qu’on veut passer au GitOps ;
- Dockhand est très complet, surtout sur la sécurité, et à suivre de près, si sa licence vous convient.
Le plus prudent reste de ne rien migrer tout de suite. Installez l’un de ces outils à côté de Portainer et testez-le quelques semaines. Ils parlent tous au même démon Docker et cohabitent sans problème ; la FAQ de Dockge le dit d’ailleurs noir sur blanc. Un seul point d’attention : les stacks créées depuis l’éditeur Web de Portainer sont stockées dans son volume de données, pas dans un dossier que vous maîtrisez. Récupérez leurs fichiers Compose avant de basculer.
C’est ce que je ferais à votre place.
Pendant des années, la question « quelle interface pour gérer Docker ? » appelait une réponse quasi automatique : Portainer. En 2026, on a enfin un vrai choix, et pour ceux qui bricolent leur home lab, c’est plutôt une bonne nouvelle.
Et vous, qu’en pensez vous ?






Merci de rester courtois: un bonjour et un merci ne coutent rien ! Nous sommes là pour échanger de façon constructive. Les trolls seront supprimés.