Portainer vs Dokploy : lequel déployer en 2026 ?

Un VPS nu livré avec Docker vous expose à une seule interface : la ligne de commande. C'est suffisant pour une machine, laborieux pour cinq, et ingérable pour une équipe. Une interface web centralise les logs, les mises à jour d'images, les variables d'environnement et les certificats TLS — sans vous forcer à maintenir un pipeline CI/CD complet dès le premier jour.

Deux familles s'affrontent : les gestionnaires (Portainer, Yacht) qui exposent Docker comme il est, et les PaaS légers (Dokploy, Coolify, CapRover) qui ajoutent une couche de déploiement — branches Git, domaines automatiques, certificats Let's Encrypt. La frontière n'est pas cosmétique : elle détermine si vos développeurs peuvent déployer seuls ou s'ils ont besoin d'un accès SSH.

Portainer CE (Community Edition) a été la référence du genre pendant des années. Avec Portainer 3, l'éditeur a arrêté l'édition Community : Portainer 3 n'a pas d'édition CE, et CE 2.45 est la dernière version Community publiée. Portainer 3 est livré en Business Edition (gratuite jusqu'à trois nœuds avec la licence « 3 Nodes Free »), donne la priorité à Kubernetes pour les nouvelles fonctions et conserve Docker, Swarm et Podman. Les instances CE 2.45 continuent de fonctionner et reçoivent les correctifs de la 2.45 LTS jusqu'en août 2027, mais plus aucune nouvelle fonction.

Cette bascule a plusieurs conséquences pratiques. D'abord, les nouvelles installations qui cherchent une interface Docker gratuite se trouvent sans roadmap côté CE. Ensuite, les images portainer/portainer-ce continuent d'exister et de recevoir les correctifs de la branche 2.45, mais n'évolueront plus. Enfin — et c'est le point critique — Portainer 2.x a accumulé des failles critiques, dont deux CVE de score 9.4, qui restent exploitables sur toute installation non patchée.

Si vous tournez encore sur Portainer 2.x, la question n'est pas « migrer ou rester » par principe : elle est « est-ce que mon instance est à jour, et est-ce que le risque est acceptable ? »

Deux CVE touchent toutes les branches de Portainer jusqu'aux versions correctives ci-dessous (les versions antérieures à 2.33.0, en fin de vie, ne seront pas corrigées) :

CVE-2026-44848 (CVSS 9.4) — Les endpoints /plugins/* de l'API Docker relayée par Portainer échappent au contrôle d'autorisation. Un utilisateur standard (non administrateur) ayant accès à un environnement Docker peut installer et activer un plugin Docker, qui s'exécute en root sur votre hôte.

CVE-2026-44849 (CVSS 9.4) — Le mécanisme de restrictions Swarm peut être contourné : un utilisateur Portainer avec des droits réduits peut exécuter des actions normalement réservées à l'administrateur sur un cluster Swarm.

Versions corrigées : 2.33.8, 2.39.2, 2.41.0. D'autres failles critiques ont été publiées depuis, corrigées en 2.45.2 et 2.45.3 et sans correctif sur la branche 2.39 : visez la 2.45.3 LTS, dernière version publiée au 7 novembre 2026.

Pour vérifier votre version :

docker exec portainer /portainer --version

Pour mettre à jour :

docker pull portainer/portainer-ce:lts
docker stop portainer
docker rm portainer
docker run -d \
  --name=portainer \
  --restart=always \
  -p 127.0.0.1:9443:9443 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v portainer_data:/data \
  portainer/portainer-ce:lts

Si vous êtes en dessous de 2.45.3, mettez à jour avant de continuer à utiliser l'instance. Cette commande ne publie l'interface que sur 127.0.0.1 : accédez-y par un tunnel SSH (ssh -L 9443:127.0.0.1:9443 user@votre-vps, puis https://localhost:9443) ou via un reverse proxy. Ajoutez -p 8000:8000 uniquement si vous utilisez des agents Edge. Portainer exposé sur Internet sans patch est un vecteur d'intrusion directe sur votre hôte Docker.

Dokploy n'est pas exempt de vulnérabilités. CVE-2026-45631 (CVSS 10.0) touchait les installations par défaut antérieures à 0.29.3 : quand la variable BETTER_AUTH_SECRET n'était pas définie — et le script d'installation ne la définissait pas —, le code retombait sur une valeur codée en dur, identique sur toutes les instances. N'importe qui pouvait alors forger un jeton et prendre le compte administrateur, sans authentification.

Le correctif est arrivé en 0.29.3, avec un script de migration à lancer après la mise à jour. De nombreuses autres failles critiques (injections de commandes, contrôles d'accès manquants) ont été corrigées jusqu'en 0.29.13 : ne restez pas en dessous, et visez la dernière version (0.31.0 au 7 novembre 2026). Pour vérifier et mettre à jour :

# Vérifier la version installée (tag de l'image du service)
docker service inspect dokploy --format '{{.Spec.TaskTemplate.ContainerSpec.Image}}'

# Mettre à jour via le script officiel
curl -sSL https://dokploy.com/install.sh | sh -s update

Depuis 0.29.3, Dokploy lit BETTER_AUTH_SECRET dans un secret Docker (variable BETTER_AUTH_SECRET_FILE). Après mise à jour, vérifiez que le service l'utilise bien :

docker service inspect dokploy --format '{{range .Spec.TaskTemplate.ContainerSpec.Env}}{{println .}}{{end}}' | grep BETTER_AUTH_SECRET_FILE

Si la ligne est absente, lancez le script de sécurité officiel publié avec la 0.29.3 : il génère un secret unique et met à jour le service.

curl -sSL https://dokploy.com/security/0.29.3.sh | bash

Les deux outils tournent sur Docker. Dokploy demande légèrement plus de ressources car il embarque une base de données PostgreSQL et un proxy Traefik en plus du service principal.

Rester sur Portainer 2.x a du sens dans trois situations : vous gérez déjà un cluster Docker Swarm ou Kubernetes avec des configurations complexes ; vous avez des équipes qui maîtrisent l'interface et des runbooks documentés dessus ; ou vous avez besoin du niveau de détail sur les réseaux et volumes que Portainer expose nativement.

Dans ces cas, la condition non négociable est d'être sur une version à jour (2.45.3 au 7 novembre 2026) et de restreindre l'accès à l'interface : ne jamais exposer le port 9000/9443 directement sur Internet, placer Portainer derrière un reverse proxy avec authentification supplémentaire si des utilisateurs non-admins y accèdent.

Migrer vers Dokploy est la bonne décision si : vous partez de zéro sur un nouveau VPS ; vous voulez que vos développeurs déploient depuis Git sans SSH ; vous gérez plusieurs domaines et ne voulez pas maintenir Nginx/Traefik à la main ; ou vous cherchez une alternative après la fin de CE (Portainer 3 n'a plus d'édition Community) pour votre usage Docker.

Portainer — interface inaccessible après mise à jour
Vérifiez que le volume portainer_data est bien monté. Une mise à jour sans volume nommé repart sur une base vide et redemande la création du compte admin.

Portainer — TLS handshake error sur le port 9443
Portainer génère un certificat auto-signé. Votre navigateur l'avertit à juste titre. Placez Portainer derrière un reverse proxy (nginx, Caddy) avec un vrai certificat pour un accès sécurisé en production.

Dokploy — Traefik ne génère pas de certificat
Cause la plus fréquente : le DNS n'est pas encore propagé vers le VPS. Vérifiez avec dig +short votre-domaine.com. Traefik attend une réponse DNS valide avant de lancer le challenge ACME. Si le DNS est bon, vérifiez que le port 80 est ouvert (ufw allow 80).

Dokploy — déploiement Git qui échoue silencieusement
Vérifiez les logs du service dans l'interface (Deployments → onglet Logs). Sur un dépôt privé, une cause fréquente est une clé SSH absente ou non autorisée côté dépôt. Dokploy permet d'en créer une dans Settings → SSH Keys (bouton Create SSH Key), à ajouter comme clé de déploiement du dépôt ; pour GitHub, GitLab, Gitea ou Bitbucket, vous pouvez aussi connecter le fournisseur dans les paramètres Git de Dokploy.