Portainer abandonne son édition communautaire et bascule toute sa feuille de route sur Kubernetes
Le 11 septembre 2026, le PDG de Portainer a annoncé que la 3.0, désormais centrée sur Kubernetes, ne sortira pas en édition communautaire : la CE reste figée sur la branche 2.x. Les auto-hébergeurs sous Docker peuvent rester sur la 2.45 LTS, qui continue de recevoir des correctifs de sécurité, mais doivent préparer leur trajectoire.
11 septembre 2026. Neil Cresswell, PDG de Portainer, publie un billet qui acte la fin d’une époque : la 3.0, à venir, sera centrée sur Kubernetes et ne sortira pas en édition communautaire. 18 septembre. La lettre Self-Host Weekly relaie la nouvelle auprès du public qui la subit le plus directement : les auto-hébergeurs. 20 septembre. La 2.45 LTS reste la dernière version de la branche historique. Pourquoi c’est important : Portainer est l’interface de gestion Docker la plus installée dans les homelabs, et son éditeur vient d’annoncer que le cœur de la communauté ne verra plus jamais de nouvelle fonctionnalité.
Ce qui disparaît exactement
Le billet est explicite sur le sort de la Community Edition (CE). Depuis dix ans, la CE est la porte d’entrée gratuite de Portainer pour gérer des environnements Docker et Swarm. La 3.x ne la reconduira pas : « CE will continue on the 2.x codebase. It will not receive the 3.x changes ». Traduction concrète — la CE est figée sur la branche 2.x, qui ne recevra plus de fonctionnalités nouvelles, seulement des correctifs de sécurité, des bugs fixes et des backports sélectifs de la 3.x.
La contrepartie annoncée est le programme « 3 Nodes Free » : la version principale de Portainer 3.x reste gratuite jusqu’à trois nœuds, sur candidature. L’argument de l’éditeur est que personne ne perd l’accès, mais le changement de nature est net. Une édition communautaire est un produit pensé pour une communauté ; un palier gratuit d’un produit entreprise est une porte d’entrée commerciale. Les deux ne se gouvernent pas de la même façon, et la communauté l’a compris : le premier réflexe, sur les forums et dans la lettre hebdo, a été de relire les conditions du « gratuit ».
Le motif avancé est technique et honnête. Selon Cresswell, l’écart entre Docker et Kubernetes s’est creusé au point qu’il n’est plus viable de maintenir un code unique couvrant Docker, Podman, Swarm et Kubernetes à armes égales. Chaque capacité — le moteur de politique, l’API d’opérations, le modèle d’authentification — devait être construite trois fois, pour trois substrats. La 3.x est donc une base Kubernetes-first, et c’est ce choix qui rend possibles les consoles à usage unique décrites dans le billet.
Un virage Kubernetes assumé
La 3.0 n’est pas une simple mise à jour : c’est une réorganisation du produit autour de consoles à usage unique, chacune ciblant un profil.
- Portainer-Run est déjà en ligne : un déploiement en self-service pour que des « business builders » non développeurs poussent leurs applications générées par IA sur le Kubernetes de l’entreprise, sans toucher à l’infrastructure.
- Portainer-IDP sera un portail développeur interne pour les équipes d’ingénierie.
- Portainer-Command est une passerelle MCP qui empêche les agents IA de modifier directement le cluster, en distribuant des rôles en lecture seule, expirants, et en forçant chaque changement par GitOps.
- Portainer-Operations sort la gestion de cluster de l’interface générale, vers une console dédiée GitOps-first.
- Portainer-AiGrid aligne l’éditeur sur l’exécution de charges IA.
Le socle commun est KubeSolo, un cluster Kubernetes mononœud open source (MIT), rapproché du calendrier officiel de Kubernetes, et censé consommer moins de 200 Mo de RAM. Et pour ceux qui ne veulent pas abandonner la syntaxe Docker, Portainer-D2K se présente comme un traducteur Docker vers Kubernetes : un environnement Docker synthétique qui accepte les commandes docker et docker compose, y compris pour les outils de CI/CD et de monitoring construits exclusivement contre l’API Docker.
La direction est cohérente, mais elle acte un fait que les auto-hébergeurs connaissent depuis des années : le Docker du homelab n’est plus, pour les éditeurs, un marché à servir — c’est une communauté à convertir.
Ce qui se passe pour les utilisateurs Docker
Le billet tient à rassurer, et c’est la partie la plus importante pour un auto-hébergeur. Si vous restez sur la 2.x, rien ne change aujourd’hui. Portainer s’engage à continuer de livrer des correctifs de sécurité, des bugs fixes et des backports sélectifs sur la branche 2.x. Rester est une décision supportée, pas un abandon forcé.
La nuance est ailleurs. La 2.x entre en maintenance : plus de nouvelles capacités, plus d’évolution du moteur de politique ni de la couche d’observabilité. Et si vous migrez vers la 3.x, Docker, Swarm et Podman restent ajoutables comme environnements natifs, mais ils sont reclassés en second dans l’interface, et ils ne recevront aucune nouvelle capacité au fil des versions. Tous les nouveaux produits — Run, IDP, Command, AiGrid — sont Kubernetes uniquement.
L’éditeur recommande explicitement d’envisager la migration de Docker vers D2K ou un Kubernetes natif, et annonce un outil de migration qui transformera les conteneurs et stacks Docker en manifests Kubernetes, les poussera dans un dépôt Git, puis les déploiera via le GitOps natif de Portainer. Le message commercial est limpide : l’avenir de Portainer passe par Kubernetes, et les utilisateurs Docker sont invités à suivre — à leur rythme, mais à suivre.
La lecture pour un auto-hébergeur
La décision pratique se résume à une question de trajectoire, pas d’urgence.
Pour un homelab qui gère une poignée de conteneurs Docker et ne demande rien de plus, Portainer 2.45 LTS reste parfaitement fonctionnel, et continuera d’être corrigé en sécurité. Il n’y a aucune urgence à migrer, et aucune donnée ne disparaît. La seule chose à intégrer, c’est que la branche 2.x est désormais au bout de sa route fonctionnelle : n’attendez plus d’elle aucune nouveauté.
Pour celui qui veut les consoles à usage unique, le GitOps intégré ou la gestion d’agents IA, la réponse est le passage à Kubernetes — via KubeSolo pour un mononœud léger, ou via D2K pour conserver l’ergonomie Docker en surface. Le coût n’est pas la licence (trois nœuds gratuits), c’est la montée en compétence : Kubernetes, même édulcoré, reste une machine d’état complexe, et la promesse de Portainer est de l’abstraire, pas de la faire disparaître.
Le point de vigilance, enfin, est celui de la gouvernance. Le passage d’une édition communautaire à un palier gratuit d’un produit commercial change la nature de la relation : les conditions du « gratuit » sont désormais des conditions de service, pas un statut de licence. Pour un service qui touche l’infrastructure de production d’un homelab ou d’une petite structure, lire ces conditions avant de basculer n’est pas de la prudence excessive — c’est le minimum.
Verdict
Si vous auto-hébergez Portainer CE sur Docker et que vous en êtes satisfait, ne migrez pas dans la précipitation : la 2.45 LTS reste supportée en sécurité, et une bascule vers Kubernetes n’apporte rien à un homelab qui n’en a pas besoin. Si vous voulez les nouveautés — GitOps natif, consoles à usage unique, orchestration d’agents IA — planifiez une migration vers KubeSolo ou D2K sur votre propre calendrier, en commençant par un environnement de test et en relisant les conditions du programme 3 Nodes Free. Si vous maintenez Portainer pour d’autres, anticipez dès maintenant : la 2.x est une branche en fin de vie fonctionnelle, et toute décision d’architecture prise aujourd’hui sur Docker devra être justifiée demain face à une feuille de route qui ne le sert plus.