Dockge : pourquoi j’ai lâché Portainer pour gérer mes containers Docker

J’ai utilisé Portainer pendant plus d’un an. Interface lourde, base de données interne, conflits sur les compose.yml modifiés en SSH… Ça marche, mais c’est overkill pour un homelab. Un jour je suis tombé sur Dockge — créé par Louis Lam, le même dev qu’Uptime Kuma. J’ai fermé l’onglet Portainer pour la dernière fois.

Voici mon retour après plusieurs mois d’utilisation quotidienne sur un cluster de 3 serveurs Proxmox.

Dockge affiche le compose.yaml en direct, ici avec le label Watchtower configuré

Le problème avec Portainer

Portainer fait le job, je ne vais pas le nier. Quelques trucs m’ont progressivement agacé :

Les stacks sont « propriétaires » : quand tu crées une stack dans Portainer, il la gère en interne. Si tu modifies le docker-compose.yml en SSH, Portainer ne suit pas toujours. Ça crée des conflits frustrants.
L’interface est lourde : beaucoup de fonctionnalités dont je n’ai pas besoin — Swarm, Kubernetes, registries… Pour un homelab, c’est overkill.
La base de données : Portainer stocke sa config dans une base interne. Si elle se corrompt, tu perds ta configuration et tu recommences.
Les mises à jour : parfois cassantes sur les versions CE, surtout en upgrade majeur.

Portainer est un bon outil enterprise, mais pour un homelab perso avec 20-30 containers, c’est trop.

💾 Volumes Docker : tes données survivent au container

Un container Docker est éphémère : si tu le supprimes, tout ce qu’il contient disparaît. Les volumes Docker sont la solution — ce sont des dossiers sur l’hôte montés dans le container. Dans Dockge, tu les vois clairement dans chaque compose.yml sous la clé volumes:. Règle d’or : toute donnée importante (base de données, config, médias) doit être dans un volume. Jamais dans le container lui-même.

Dockge : le retour à la simplicité

Dockge (prononcé « dockgé ») est créé par Louis Lam — le même développeur qu’Uptime Kuma. C’est dire le niveau de finition. Le code source est open source sur GitHub.

Le concept est radical de simplicité :

Pas de base de données : tout repose sur des fichiers docker-compose.yml classiques, stockés sur le disque.
Édition bidirectionnelle : tu modifies un compose dans Dockge, ça met à jour le fichier. Tu modifies le fichier en SSH, Dockge le détecte. Zéro conflit.
UI minimaliste : une stack = une carte. Start, stop, restart, logs, éditeur. C’est tout ce qu’il faut.
Léger : un seul container, ~30 Mo de RAM.

Installation en 2 minutes

L’installation est stupidement simple. Crée la structure :

mkdir -p /opt/stacks /opt/dockge
cd /opt/dockge

Crée le fichier docker-compose.yml :

services:
  dockge:
    image: louislam/dockge:1
    container_name: dockge
    restart: unless-stopped
    ports:
      - "5001:5001"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./data:/app/data
      - /opt/stacks:/opt/stacks
    environment:
      - DOCKGE_STACKS_DIR=/opt/stacks

docker compose up -d

Accès à http://<IP>:5001. C’est fait. Chaque stack que tu crées dans Dockge sera un dossier dans /opt/stacks/ avec son propre docker-compose.yml. Propre, lisible, versionnable avec Git.

⚠️ Note v1.5 : depuis la version 1.5.0 (mars 2025), la fonctionnalité Console est désactivée par défaut pour des raisons de sécurité. Si tu en as besoin, ajoute la variable d’environnement DOCKGE_ENABLE_CONSOLE=true dans ton compose.

Créer une stack dans Dockge : on colle le docker-compose.yml, on clique Déployer

Mon utilisation au quotidien

Actuellement, je gère plus de 30 stacks avec Dockge réparties sur mes 3 nœuds Proxmox :

Glance : dashboard homelab
Uptime Kuma : monitoring disponibilité
Stack media : Sonarr, Radarr, Prowlarr, Transmission, Overseerr
Stack domotique : Zigbee2MQTT, Mosquitto MQTT broker
Stack monitoring : Beszel Hub, Grafana, InfluxDB
Et une vingtaine d’autres : TeslaMate, FreshRSS, Wallos…

Une bonne pratique que j’applique systématiquement : le label Watchtower sur les stacks que je veux mettre à jour automatiquement.

labels:
  - "com.centurylinklabs.watchtower.enable=true"

Tu ne l’ajoutes pas partout (certaines stacks méritent une mise à jour manuelle), mais pour les outils matures et stables, c’est très pratique.

Les logs en temps réel directement depuis Dockge, sans passer par le terminal

Ce que j’apprécie au quotidien :

Les logs en temps réel : un clic sur une stack, les logs défilent. Fini le docker logs -f en SSH.
Le déploiement rapide : je copie un compose trouvé sur GitHub, je clique « Deploy », c’est en route.
La cohérence : mes fichiers compose sont sur le disque, versionnables avec Git.

Les limites

Dockge n’est pas parfait. Ses limites sont assumées et documentées :

Pas de gestion multi-nœuds native dans la UI principale : pour gérer plusieurs serveurs, tu ajoutes des agents (voir le tip ci-dessous)
Pas de gestion d’images : impossible de browser un registry ou nettoyer les images inutilisées depuis l’UI
Pas de gestion réseau avancée : les réseaux Docker se gèrent en ligne de commande

Pour un homelab classique avec un ou plusieurs serveurs Proxmox et une trentaine de containers, c’est largement suffisant.

Dockge vs Portainer : le vrai comparatif

	Dockge	Portainer CE
Complexité	Minimale	Élevée
Fichiers compose	Sur le disque, éditables librement	Internes, conflits possibles
Base de données	Aucune	SQLite interne
Multi-nœuds	Via agents	Natif (Swarm)
RAM	~30 Mo	~200 Mo
Pour qui	Homelab, usage perso	Enterprise, Swarm/K8s

Si tu as un homelab avec un ou plusieurs serveurs et que tu veux garder le contrôle sur tes fichiers compose, Dockge est le bon choix. Si tu gères une infra multi-serveurs en production avec Swarm, Portainer reste pertinent.

Conclusion

Dockge a simplifié ma gestion Docker de façon radicale. Plus de conflits de fichiers, plus de base de données mystérieuse, plus d’interface surchargée. Juste des fichiers compose, une UI propre, et du contrôle total.

C’est l’outil que j’aurais voulu avoir dès le début de mon aventure homelab. L’infra reste stable, les mises à jour sont rares — et c’est exactement ce que je recherche.

💡 Le petit truc en plus

Dockge supporte le mode agent multi-serveur : tu installes un container louislam/dockge:agent sur chaque serveur secondaire, et tu connectes les agents depuis l’interface principale. Résultat : tu gères les stacks de tes 3 nœuds Proxmox depuis une seule interface, sans SSH.

Sur mon cluster, j’ai un agent sur chaque NUC et sur le MS-01 — tout est visible depuis le Dockge du nœud 1. C’est probablement la fonctionnalité la moins connue de Dockge, et c’est celle qui m’a convaincu d’y rester quand le cluster a grandi.

services:
  dockge-agent:
    image: louislam/dockge:agent
    container_name: dockge-agent
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /opt/stacks:/opt/stacks
    environment:
      - DOCKGE_STACKS_DIR=/opt/stacks

👉 Pour aller plus loin : installe Uptime Kuma pour surveiller que tes containers sont bien up, et Beszel pour les métriques CPU/RAM de chaque nœud. Le trio Dockge + Uptime Kuma + Beszel couvre 90% de tes besoins de gestion et monitoring.