Portainer 2.45 LTS apporte le RBAC natif Kubernetes et l’élagage automatique des images aux homelabs
Le 27 août 2026, Portainer a fait passer sa ligne LTS de la 2.39.6 à la 2.45.0, en consolidant un an de versions intermédiaires. La nouveauté qui compte n’est pas cosmétique : c’est l’arrivée des politiques Pod Security Standards, du RBAC natif Kubernetes et du nettoyage automatisé d’images dans l’interface.
27 août 2026. Portainer publie la version 2.45.0, une Long Term Support, et fait glisser sa ligne stable de la 2.39.6 vers la 2.45.0. 28 août 2026. Les utilisateurs de Synology et des NAS domestiques reçoivent l’image Docker mise à jour. Ce n’est pas une release de plus : la 2.45 embarque les politiques Pod Security Standards, le RBAC natif Kubernetes et le nettoyage automatisé des images — de quoi transformer une interface de gestion de conteneurs en petit plan de contrôle de gouvernance.
Le geste a une logique limpide. Depuis le passage en LTS, Portainer alterne des versions Short Term Support qui expérimentent, puis consolide le tout dans une version LTS testée et stabilisée. La 2.45 est ce point de consolidation : tout ce qui s’est accumulé depuis la 2.39 arrive d’un coup, poli et supporté sur le long terme. Pour un homelab qui tourne depuis deux ans sur une 2.39 vieillissante, c’est l’occasion de basculer — à condition de savoir ce qu’on y gagne vraiment.
Ce que « LTS » veut dire, concrètement
Une LTS n’est pas une version plus riche qu’une STS : c’est une version plus assumée. Les fonctionnalités sorties au fil des STS — souvent marquées « expérimental » — deviennent ici stables, documentées et couvertes par un cycle de support long. Pour un auto-hébergeur, la différence se mesure en sérénité : on met à jour une fois, et on n’a plus à suivre les releases intermédiaires pendant des mois.
La 2.45.0 succède directement à la 2.39.6 comme référence LTS. Entre les deux, plusieurs STS ont apporté de la matière : refonte de l’accueil, gestion GitOps repensée, alertes généralisées, et surtout une couche de politiques qui rapproche Portainer d’un vrai outil de gouvernance multi-environnements. La question n’est donc plus « est-ce que Portainer fait du Kubernetes » mais « est-ce qu’il le fait avec le même niveau de contrôle qu’un Rancher ou un Lens ». La réponse, avec la 2.45, est de plus en plus souvent oui.
La gouvernance Kubernetes arrive dans l’interface
C’est le cœur de la release. Portainer 2.45 introduit plusieurs types de politiques qui s’appliquent à un ou plusieurs environnements à la fois.
Pod Security Standards. La politique permet d’imposer les profils privilégié, baseline ou restreint par namespace, indépendamment en mode enforce, audit ou warn. Concrètement, un admin peut bloquer les pods privilégiés partout sauf dans un namespace dédié, sans écrire une ligne de YAML. C’est la brique que les homelabs négligent le plus — et la première qu’un auditeur regarde.
NetworkPolicy Kubernetes. On définit des règles d’ingress et d’egress via des presets ou des règles à base de labels, déployées comme de vrais objets NetworkPolicy natifs. Là encore, l’interface traduit en Kubernetes ce que l’utilisateur exprime en clic.
RBAC natif Kubernetes. Le changement le plus profond : à côté de l’ancien modèle de privilèges maison, Portainer propose désormais un modèle de permissions natif Kubernetes, où les droits s’accumulent à travers les rôles de cluster, d’équipe et de namespace. Pour une PME qui veut aligner Portainer sur ses habitudes kubectl, c’est la fin d’une traduction hasardeuse entre deux systèmes de permissions.
Observabilité. Une politique dédiée connecte Portainer à une instance OneUptime pour ramener logs et métriques directement dans la vue namespace.
Le point commun de ces quatre briques : elles rendent la gouvernance déclarative et réutilisable, au lieu de la disperser dans des réglages par environnement. Pour un auto-hébergeur qui gère un cluster maison et une poignée de VM, c’est la différence entre « je fais tourner des conteneurs » et « je pilote une infrastructure ».
GitOps centralisé et nettoyage d’images
Deux autres nouveautés parlent directement aux pratiques de l’auto-hébergement moderne.
D’un côté, le GitOps est enfin centralisé. Une nouvelle vue Sources regroupe les connexions Git au lieu de les ressaisir par workflow. Un assistant guide la création d’un workflow de bout en bout — source, fichier de stack, cibles de déploiement, variables d’environnement, registre, stratégie de déploiement avec lots parallèles et pause ou rollback automatique. Un tableau de bord Workflows unifie ensuite la santé des charges déployées depuis Git, qu’elles soient Docker, Edge ou Kubernetes.
De l’autre, le nettoyage d’images passe de corvée manuelle à politique automatique. On peut élaguer les images dangling ou inutilisées depuis la vue Images, ou programmer un nettoyage automatique selon l’âge des images ou des seuils de stockage — avec la possibilité de protéger des images précises. C’est le genre de fonctionnalité qui ne brille pas en démo, mais qui évite qu’un homelab se retrouve un matin avec le disque plein à cause d’images de build oubliées.
Le reste du tableau de bord
La release complète le panorama. La page d’accueil a été refaite, avec des groupements d’environnements triables par groupe, plateforme ou santé — pratique dès qu’on dépasse trois hôtes. Les add-ons font leur apparition : des outils installables qui se déploient en release Helm dans le cluster, avec un premier module, Portainer-Run. L’alerting passe en disponibilité générale, avec des seuils multi-gravité, de nouvelles règles Kubernetes (etcd, serveur d’API, expiration de certificat TLS, nœuds NotReady) et des notifications Slack, e-mail ou Teams. La visibilité GPU s’affiche pour les clusters équipés. Enfin, un provider Terraform officiel permet de gérer environnements, équipes et stacks en Infrastructure as Code.
L’ensemble dessine une trajectoire claire : Portainer cesse d’être la « jolie interface Docker » pour devenir le plan de contrôle d’une infra auto-hébergée, du serveur unique au petit cluster Kubernetes.
Migrer depuis la 2.39 sans casse
La bascule d’une LTS à l’autre est un chemin documenté, pas un clic silencieux. Portainer recommande de sauvegarder le volume de données (/data) avant toute mise à jour, puis de re-puller l’image Docker. Pour une installation classique en docker run, la séquence est la suivante :
docker stop portainer
docker rm portainer
docker run -d -p 9443:9443 \
-v /var/run/docker.sock:/var/run/docker.sock \
-v portainer_data:/data \
--name portainer portainer/portainer-ce:2.45.0Les équipes qui passent par Docker Compose se contentent de changer le tag d’image puis de lancer docker compose up -d. Le point de vigilance porte sur les politiques nouvellement créées : elles ne s’appliquent pas rétroactivement, il faut les attacher explicitement aux environnements existants. Et pour ceux qui utilisaient l’ancien modèle de privilèges Kubernetes, le RBAC natif est une option additionnelle, pas un remplacement forcé — les deux modèles coexistent.
Côté comparaison, la 2.45 rapproche Portainer de Rancher sur la gouvernance Kubernetes, tout en restant plus simple à prendre en main. Face à Cockpit ou Yacht, l’écart se creuse nettement sur les politiques et le GitOps. L’arbitrage se résume à une phrase : un plan de contrôle riche mais abordable, contre une plateforme Kubernetes-native complète mais plus lourde à opérer.
Verdict
Si vous gérez un cluster Kubernetes, même modeste, basculez sur la 2.45 LTS : le RBAC natif et les Pod Security Standards comblent l’écart de gouvernance qui vous poussait ailleurs, et la politique d’élagage d’images règle un problème opérationnel récurrent.
Si vous ne gérez qu’un ou deux hôtes Docker avec une poignée de stacks, la mise à jour reste recommandée pour la stabilité LTS, mais la moitié des nouveautés ne vous concernera pas — prenez-la pour le nettoyage d’images et la refonte de l’accueil, pas pour le Kubernetes.
Si vous êtes encore en 2.39.6, planifiez le saut : c’est une LTS vers une LTS, le chemin est propre, et les deux années de fonctionnalités intermédiaires valent l’effort d’une mise à jour.