Portainer 3.0 supprime la CE : trois alternatives open source

Depuis sa création, Portainer Community Edition permettait de gérer des conteneurs Docker et des stacks Compose via une interface web, gratuitement, sans limite de nœuds. Portainer 3.0 change ce modèle : la CE disparaît au profit d'une édition unique avec un palier gratuit restreint et une offre Business payante.

Concrètement, les fonctionnalités avancées — gestion multi-environnements, RBAC, intégrations d'authentification externe — passent derrière un abonnement. Pour un développeur indépendant ou une agence qui gère plusieurs VPS, le coût peut devenir significatif.

La bonne nouvelle : l'écosystème open source de gestion de conteneurs s'est considérablement étoffé depuis 2022. Trois outils couvrent aujourd'hui les cas d'usage principaux, chacun avec une approche différente.

Cet article vous guide vers le bon choix selon votre contexte réel : vous ne perdrez pas de fonctionnalités si vous choisissez l'outil dont vous avez réellement besoin, plutôt que le plus complet sur le papier. La migration n'est pas une urgence qui justifie n'importe quel choix — prenez le temps d'identifier votre cas.

Dockge est un gestionnaire de stacks docker-compose.yml développé par le créateur d'Uptime Kuma. Il ne cherche pas à remplacer Portainer dans sa totalité : il cible un périmètre précis, gérer et déployer des fichiers Compose depuis une interface web minimaliste.

Points forts : démarrage en deux commandes, interface réactive, édition en ligne des fichiers Compose, logs en temps réel. Points faibles : un seul hôte Docker, pas de RBAC, pas de gestion multi-serveurs.

Dockge convient aux développeurs qui gèrent un VPS personnel et veulent simplement visualiser, démarrer ou arrêter leurs stacks sans ouvrir un terminal. La gestion des fichiers Compose reste dans un répertoire standard sur le disque — vous n'êtes pas enfermé dans une base de données propriétaire. Si Portainer stockait vos stacks dans son format interne, Dockge vous rend la lisibilité directe.

Un comparatif détaillé Dockge vs Portainer est disponible dans l'article portainer-vs-dockge-gestion-conteneurs-vps.

Coolify se positionne comme un Heroku ou un Render que vous hébergez vous-même. Il va plus loin que la gestion de conteneurs : il gère le déploiement depuis Git (push-to-deploy), configure automatiquement le reverse proxy (Traefik) et renouvelle les certificats SSL.

Points forts : déploiement depuis GitHub/GitLab/Gitea en quelques clics, support de Dockerfile, Docker Compose et Nixpacks, interface moderne, support multi-serveurs (nœuds distants ajoutés via SSH). Points faibles : plus lourd à l'idle qu'un gestionnaire Compose pur, la courbe de configuration initiale est plus prononcée.

Coolify convient aux agences ou développeurs qui déploient régulièrement des applications depuis un dépôt Git et veulent éviter de configurer nginx et Certbot manuellement à chaque projet. Si votre workflow repose déjà sur des branches et des push, vous retrouverez vos réflexes en quelques heures.

Pour la migration depuis Portainer : Coolify lit directement les fichiers compose.yml existants, mais le reverse proxy Traefik remplace nginx ou Caddy si vous les gérez manuellement. Prévoyez de migrer en deux temps — d'abord les stacks sans domaine, puis les services exposés publiquement une fois Traefik validé.

Komodo (anciennement Monitor) est l'outil le plus complet des trois. Sous licence GPL-3.0, il propose une architecture Core/Periphery : un Core central orchestre des agents Periphery déployés sur chaque serveur. Il gère les déploiements Docker et Docker Compose, synchronise les stacks depuis un dépôt Git, centralise les logs et les alertes, et expose une API.

Le Core Komodo consomme moins de 256 Mo de RAM à l'idle — il tient sur le même VPS d'entrée de gamme que vos apps. C'est l'alternative la plus proche de Portainer en termes de périmètre fonctionnel, et la seule des trois à couvrir nativement le cas multi-serveurs avec GitOps.

Pour l'installation complète, consultez le guide dédié : self-host-komodo-vps. Komodo est également disponible directement depuis le catalogue ServOrbit.

Le port 9000 de Portainer CE entre en conflit avec Komodo. Si vous faites tourner Portainer en parallèle pendant la migration, vérifiez que Komodo écoute sur un port différent (9120 par défaut). Modifiez KOMODO_PORT dans le Compose de Komodo si nécessaire.

docker.sock refusé par l'agent Periphery. Sur certaines distributions (Ubuntu 22.04+), le socket appartient au groupe docker. Ajoutez l'utilisateur courant à ce groupe (usermod -aG docker $USER) ou lancez l'agent avec --user root — uniquement si vous comprenez l'impact de sécurité.

Les stacks Compose importés depuis Portainer ne démarrent pas. Portainer stocke certaines variables d'environnement dans son propre coffre (Secrets). Vérifiez que chaque compose.yml migré dispose d'un fichier .env complet, ou déclarez les variables dans l'interface Komodo (section Variables).

Coolify ne trouve pas le Dockerfile après connexion Git. Le champ « Build path » doit pointer vers le répertoire qui contient le Dockerfile, pas la racine du dépôt si le fichier est dans un sous-dossier. Vérifiez aussi que la branche configurée existe bien sur le remote.

Dockge affiche « Compose file not found » après un redémarrage. Le montage de volume doit pointer vers le répertoire parent du projet, pas vers le fichier compose.yml directement. La convention Dockge est /opt/stacks/<nom-du-stack>/compose.yml — respectez cette arborescence.