Vaultwarden en rade après une mise à jour : comment Claude Code m’a fait gagner une soirée
Vendredi soir, 19h. Je veux récupérer un mot de passe dans Vaultwarden depuis mon téléphone.…
Estimated reading time: 9 minutes
J’avais Portainer depuis le premier jour où j’ai installé Docker sur heighliner. C’est la réponse évidente à « j’ai besoin d’une interface web pour Docker » – c’est ce que tout le monde recommande, c’est ce qui apparaît en premier dans les listes d’outils homelab. J’ai fini par le remplacer par Dockge après avoir passé 20 minutes à chercher où était le bouton pour éditer un fichier Compose existant. Ce guide explique pourquoi, et quand chaque outil a encore du sens.
Portainer CE 2.x : le Swiss Army Knife
Portainer Community Edition couvre un spectre très large : Docker Engine seul, Docker Swarm, Kubernetes, et la gestion multi-hôtes via un agent léger installé sur chaque machine distante. C’est sa force principale – si tu gères des conteneurs sur plusieurs machines depuis une interface centralisée, Portainer est la solution la plus mature.
L’image Docker fait environ 300 MB, et le daemon Portainer consomme autour de 200 MB de RAM au repos. Ce n’est pas énorme, mais c’est mesurable sur un homelab qui optimise chaque mégaoctet.
L’interface est dense. Les menus sont organisés par contexte (Local, puis les environnements distants) et par ressource (Conteneurs, Images, Volumes, Réseaux, Stacks). Pour quelqu’un qui vient d’un contexte d’entreprise avec plusieurs équipes et plusieurs environnements, cette organisation fait sens. Pour un homelab mono-opérateur avec une douzaine de stacks sur une seule machine, c’est surtout de la surface d’écran qui consomme des clics.
La version CE a des limites volontairement imposées par rapport à la Business Edition : pas de SSO LDAP/SAML, pas de contrôle d’accès granulaire par équipe, pas de journalisation d’audit. Ces limites ne sont pas gênantes en homelab, mais elles rappellent que Portainer CE existe d’abord pour servir de vitrine à Portainer BE.
L’agent Portainer est le composant requis pour gérer des hôtes distants. Il tourne en tant que conteneur avec accès au socket Docker (/var/run/docker.sock) de l’hôte distant. C’est fonctionnel, mais ça étend la surface d’attaque : un agent compromis sur un hôte distant a potentiellement accès à tous les conteneurs de cet hôte. En homelab isolé derrière un firewall strict, c’est un risque théorique. En réseau ouvert, c’est une surface d’attaque réelle.
Dockge 1.x : Compose en premier
Dockge a été créé par Louable (l’auteur d’Uptime Kuma), et son parti pris est clair dès la première utilisation : l’unité de base n’est pas le conteneur, c’est la stack Compose. Si tu travailles principalement avec des fichiers docker-compose.yml, Dockge est pensé pour toi.
L’image fait environ 50 MB, et le daemon tourne avec 25 à 35 MB de RAM. Ça tourne dans un LXC Debian 12 minimal avec 1 vCPU et 128 MB de RAM allouée, avec de la marge.
Le fonctionnement est simple : Dockge surveille un répertoire (par convention /opt/stacks/). Chaque sous-répertoire contenant un fichier docker-compose.yml devient automatiquement une stack visible dans l’interface. Pas besoin d’importer, pas besoin de déclarer. Tu poses ton fichier Compose, Dockge le voit.
L’interface principale affiche toutes les stacks avec leur état (up/down/partial), le nombre de conteneurs, et des raccourcis pour démarrer, arrêter, et redémarrer l’ensemble d’une stack. L’éditeur YAML intégré permet de modifier le docker-compose.yml directement depuis le navigateur, avec coloration syntaxique et validation de base. Les logs sont accessibles par service, en temps réel, dans le même onglet.
Ce que Dockge ne fait pas : gérer plusieurs hôtes Docker depuis une seule interface, gérer des Swarms ou du Kubernetes, et il n’y a pas de dashboard de métriques CPU/RAM/réseau. Pour les métriques, tu délègues à Grafana + Prometheus, ce qui est de toute façon la bonne architecture pour un homelab qui a déjà une stack d’observabilité.
Yacht 0.x : la simplicité avant tout
Yacht est la troisième option, et la moins active des trois depuis 2024. Son orientation est différente : templates d’applications préconfigurés pour déployer des apps courantes en quelques clics. Pense à lui comme à un App Store local pour Docker.
L’image est légère (~80 MB), la consommation RAM similaire à Dockge. L’interface est minimaliste – une liste de templates, un formulaire de configuration pour chaque template, un bouton « Deploy ». Pour quelqu’un qui débute avec Docker et qui veut juste lancer Pi-hole ou Nextcloud sans écrire de fichier Compose, c’est la courbe d’apprentissage la plus courte.
La limite principale : le support de Docker Compose n’est pas natif au sens Dockge. Yacht peut créer des conteneurs depuis des templates Compose, mais l’édition et la gestion des stacks Compose existantes est moins fluide. Si tu as déjà des fichiers Compose écrits à la main, Yacht n’est pas la bonne interface pour les gérer.
L’activité du dépôt GitHub a nettement ralenti depuis début 2024. Ce n’est pas forcément rédhibitoire – Yacht est stable – mais ça signifie moins de correctifs de sécurité et moins de nouvelles fonctionnalités.
Déployer Vaultwarden : comparaison pratique
Pour rendre la comparaison concrète, voici comment déployer une stack Vaultwarden avec chaque outil.
Avec Portainer : Environments > Local > Stacks > Add stack. Nommer la stack, coller le contenu du docker-compose.yml dans l’éditeur web. Les variables d’environnement peuvent être saisies dans un formulaire dédié ou directement dans le YAML. Cliquer « Deploy the stack ». La stack apparaît dans la liste avec ses conteneurs. Fonctionnel, mais l’interface est chargée – il faut naviguer dans plusieurs menus pour arriver à l’éditeur.
Avec Dockge : Créer le répertoire et le fichier :
mkdir -p /opt/stacks/vaultwarden
nano /opt/stacks/vaultwarden/docker-compose.yml
Dockge détecte automatiquement le nouveau répertoire. La stack vaultwarden apparaît dans l’interface avec un état « created but not started ». Cliquer « Start » ou utiliser le bouton dans l’éditeur intégré. C’est tout. Pour modifier un paramètre, cliquer la stack, modifier le YAML dans l’éditeur, cliquer « Save & Deploy ».
Avec Yacht : Rechercher « Vaultwarden » dans la bibliothèque de templates. Si le template existe (il est dans la bibliothèque officielle Yacht), cliquer, configurer les variables (DOMAIN, ADMIN_TOKEN), cliquer « Deploy ». C’est la procédure la plus rapide des trois pour une première installation. Pour des modifications ultérieures ou des configurations avancées, il faut passer par l’interface des variables et les possibilités sont plus limitées.
Pourquoi j’ai migré de Portainer à Dockge
La raison concrète : j’avais 11 stacks Compose sur heighliner. Chaque fois que je voulais modifier un docker-compose.yml, je devais naviguer dans Portainer jusqu’à la stack, trouver l’option « Editor », faire la modification, redéployer. Le problème est que le fichier Compose dans Portainer n’est pas le fichier sur le disque – Portainer stocke sa propre copie en base de données. Si tu modifies le fichier directement sur l’hôte, Portainer ne le voit pas. Si tu modifies dans Portainer, tu as un désynchro potentiel avec le fichier sur disque.
Dockge fait exactement l’inverse : le fichier sur le disque est la source de vérité. L’éditeur web modifie directement le fichier. Si tu modifies le fichier avec nano en SSH, Dockge le voit au prochain rechargement. Cette philosophie correspond mieux à ma façon de travailler – je versionne mes fichiers Compose dans un dépôt Git, et je veux que la source de vérité soit le système de fichiers, pas une base de données interne à l’outil.
Si tu versionnes tes fichiers Compose avec Git, considère un script de déploiement simple : git pull && docker compose -f /opt/stacks/ma-stack/docker-compose.yml up -d. Dockge s’alignera automatiquement puisqu’il surveille les fichiers.
La migration de Portainer vers Dockge
En pratique, la migration a pris 30 minutes et n’a causé aucune interruption de service.
Les stacks Portainer sont des fichiers Compose – Portainer les stocke dans /var/lib/portainer/compose/ (ou dans sa base de données selon la version). J’ai récupéré les fichiers Compose de chaque stack via l’éditeur Portainer (copier/coller) et les ai posés dans les répertoires correspondants sous /opt/stacks/.
mkdir -p /opt/stacks/{vaultwarden,nextcloud,gitea,pihole,uptime-kuma,traefik}
Les conteneurs déjà en cours d’exécution n’ont pas été touchés. Dockge les a détectés comme des stacks existantes et les a affichés avec leur état correct. J’ai arrêté Portainer (un simple docker stop portainer), vérifié que Dockge affichait tout correctement, et c’était terminé.
Avant de désinstaller Portainer, vérifier que toutes tes stacks sont bien visibles dans Dockge et que tu peux les arrêter et redémarrer depuis l’interface Dockge. Portainer stocke des configurations supplémentaires (variables d’environnement non commitées, webhooks) qui ne sont pas dans le fichier Compose – les noter avant de migrer.
Mon verdict
Pour un homelab mono-hôte avec moins de 15 stacks Compose, Dockge est le meilleur choix aujourd’hui. L’interface est directe, le fichier Compose est la source de vérité, et la consommation de ressources est minimale.
Portainer redevient pertinent si tu gères plusieurs hôtes Docker depuis une interface centralisée, ou si tu veux une interface multi-environnement (staging + production sur des machines différentes). La version CE reste capable pour ces cas, même si les limitations de la version Business Edition se font sentir dès qu’on cherche des fonctionnalités d’accès multi-utilisateurs.
Yacht est le point d’entrée idéal pour quelqu’un qui démarre avec Docker et qui veut déployer ses premiers services sans écrire de YAML. La bibliothèque de templates accélère les premières heures. Une fois qu’on commence à personnaliser et à versionner ses configurations, on en sort naturellement.
Je n’ai pas regretté la migration. Ce qui m’a pris le plus de temps, c’est d’attendre que Dockge détecte toutes les stacks – environ 30 secondes après les avoir posées dans /opt/stacks/.
