What’s Up Docker (WUD) est une alternative à Watchtower qui a la même finalité : vous permettre de suivre et d’appliquer facilement les mises à jour de vos conteneurs Docker. Cet article explique comment installer et utiliser la solution open source What’s Up Docker.

Remarque : le projet Watchtower, pourtant populaire, a été abandonné le 17 décembre 2025. Le dépôt officiel et historique est désormais une archive publique sur GitHub. Pour autant, il existe plusieurs forks de Watchtower, dont celui porté par Nicholas Fedor qui semble le plus sérieux à ce jour : github.com/nicholas-fedor/watchtower/

Si vous avez l’habitude d’exécuter des applications au sein de conteneurs Docker, vous avez surement constaté que la gestion du cycle de vie des conteneurs n’est pas évidente. Le contexte suivant va sûrement parler à certains d’entre vous : vous administrez un Homelab avec des dizaines de services exécutés via Docker. Devoir vérifier manuellement la disponibilité d’une nouvelle image sur le Docker Hub (ou un autre registre), pour ensuite arrêter le service, supprimer l’ancienne image et relancer le conteneur, est une tâche chronophage, surtout à cause du nombre de conteneurs à gérer.

C’est ici qu’intervient What’s Up Docker, un outil open source, auto-hébergeable (self-hosted), conçu pour simplifier la maintenance des conteneurs Docker. Son principe est simple : il scanne vos conteneurs locaux (ou ceux de serveurs distants), interroge les registres (comme Docker Hub, GHCR, etc.) pour détecter de nouvelles images en s’appuyant sur les tags, et déclenche des actions en conséquence.

Il peut uniquement vous notifier par e-mail ou sur un autre canal (Telegram, Discord, via un Webhook, etc…) et même aller jusqu’à effectuer la mise à jour automatiquement, selon certains critères. What’s Up Docker peut aller jusqu’à mettre à jour directement vos fichiers pour refléter les nouvelles versions, garantissant que votre configuration reste cohérente (ce qui est surtout intéressant si vous utilisez une version statique dans le fichier Docker Compose).

Le plus en comparaison de Watchtower : What’s Up Docker dispose d’une interface web simple et pratique pour disposer d’un suivi visuel.

Fonctionnement de What’s Up Docker

Le fonctionnement de WUD repose sur trois éléments principaux :

• WATCHERS : les hôtes Docker à analyser, il peut s’agir de l’hôte Docker local et/ou d’hôtes Docker distants.
• REGISTRIES : WUD consulte les registres distants pour surveiller la disponibilité d’une mise à jour.
• TRIGGERS : ils déterminent les actions à effectuer lorsqu’une mise à jour est détectée (notification, application de la mise à jour, etc.).

Ce qui donne le schéma de fonctionnement suivant que j’ai récupéré dans la documentation officielle :

Installation de What’s Up Docker avec Docker Compose

Pour effectuer l’installation de WUD, vous devez disposer de Docker (et Docker Compose). Pour ma part, le projet What’s Up Docker sera stocké à cet emplacement :

C’est dans ce répertoire que je vous invite à créer un fichier au sein duquel vous allez ajouter ce contenu :

En réalité, ce fichier Docker Compose est un bon départ, mais il ne suffira pas à profiter pleinement de WUD. Néanmoins, nous allons commencer avec cette configuration basique. Cette configuration permet de :

• Lancer le conteneur avec l’image disponible sur le Docker Hub
• Donner accès au socket Docker à l’outil WUD
• Exposer l’application sur le port 3030 (par défaut 3000, mais déjà occupé dans mon cas)
• Vérifier tous les jours à 1h du matin s’il y a des mises à jour disponibles. La variable d’environnement utilise la syntaxe standard d’une tâche cron.
• Protéger l’accès à l’interface par un identifiant et un mot de passe.

Au sujet du dernier point évoqué ci-dessus, vous devez définir le nom de l’utilisateur au niveau du paramètre . Pour le mot de passe, générez-le en ligne de commande avec OpenSSL (et la fonction de hachage APR1). Vous devez saisir votre mot de passe 2 fois, de façon interactive. Ici, le mot de passe déterminé à des fins de test est , ce qui donne . Mais attention, au niveau du paramètre , vous devez doubler chaque , sinon ce sera mal interprété par Docker.

Enregistrez et fermez le fichier.

Lancez la construction du projet :

Connectez-vous sur l’interface depuis votre navigateur préféré : . Vous arrivez sur une page de connexion semblable à celle ci-dessous. Utilisez le compte défini précédemment.

Prise en main de What’s Up Docker

L’interface de What’s Up Docker est minimaliste, mais elle contient les informations essentielles. Nous pouvons constater que 20 conteneurs ont été détectés et 14 d’entre eux utilisent une image dont une mise à jour est disponible. On constate aussi :

• 0 Triggers : WUD ne fera rien en l’état, c’est-à-dire aucune notification, aucune action de mise à jour.
• 1 Watchers : WUD a une routine de configurée pour surveiller l’hôte Docker local (ligne ).
• 5 Registries : WUD vérifie les mises à jour sur les registres auprès desquels ont été obtenues vos images Docker.

Si vous cliquez sur la vignette “Containers“, la liste de tous vos conteneurs Docker s’affichera. Vous pouvez activer l’option “Update available” pour afficher uniquement ceux qui ont besoin d’une mise à jour. D’une façon générale, les filtres disponibles dans le haut de l’interface permettent d’affiner les résultats.

De la même façon, si vous cliquez sur un conteneur, vous obtenez des précisions sur la mise à jour disponible. WUD surveille les évolutions au niveau des tags et il indique s’il s’agit d’une mise à jour mineure ou majeure.

En l’état, What’s Up Docker n’apporte pas grand-chose, si ce n’est vous offrir un aperçu visuel sur l’état des mises à jour sur vos conteneurs. Pour aller plus loin, vous devez configurer des déclencheurs (triggers).

Configuration d’un trigger

Pour l’instant, l’outil tourne, mais il ne fait rien de concret. WUD est modulaire : il faut configurer des Triggers (déclencheurs) pour définir comment réagir aux mises à jour détectées.

Il existe de nombreuses façons de recevoir des notifications de la part de WUD, que ce soit par e-mail, sur Discord, sur Telegram, via une notification mobile (via Gotify, Ntfy, Apprise) ou encore pour lancer une interaction sur une autre application (via les webhooks, mais pas uniquement).

Gardez à l’esprit ceci :

• Vous pouvez définir plusieurs déclencheurs du même type,
• Chaque déclencheur a sa propre configuration,
• Par défaut, tous les déclencheurs s’appliquent à tous les conteneurs (il y a un système de labels Docker pour affiner)

La syntaxe à respecter est la suivante :

Par exemple, pour configurer un nouveau déclencheur pour envoyer des e-mails via Gmail (avec un mot de passe d’application), nous pouvons utiliser cette structure :

Ci-dessous, une configuration complète pour envoyer les notifications via Gmail, en précisant aussi le titre de l’e-mail et le texte du corps de l’e-mail. Vous devez insérer ces lignes dans la section de votre fichier Docker Compose, à la suite des variables actuelles.

Enregistrez et relancez le conteneur.

Dans l’interface Web, allez dans Configuration > Triggers, sélectionnez le trigger SMTP/Gmail et cliquez sur “Test” sur la droite afin de lancer un test. Vous devriez recevoir un e-mail de test permettant de confirmer le bon fonctionnement de votre configuration.

Voici un exemple :

La configuration des triggers est décrite sur cette page :

• What’s Up Docker – Configuration Trigger

Désormais, vous devez toujours effectuer les mises à jour manuellement, mais vous serez averti lorsqu’une mise à jour est disponible. Cela change déjà beaucoup de choses !

Automatiser la mise à jour des conteneurs Docker

Par défaut, WUD est en mode “observation” : il se contente de notifier. Si vous souhaitez aller encore plus loin, vous pouvez lui déléguer la mise à jour des conteneurs : pull de la nouvelle image, suppression de l’ancienne, redémarrage… WUD s’occupe de tout ! Personnellement, je pense que c’est tout de même risqué de le laisser en “pilotage automatique”, mais sur une infrastructure de test, pourquoi pas. Nous verrons par la suite qu’il y a une certaine flexibilité, car WUD peut ignorer certains conteneurs. Dans tous les cas, cette décision vous appartient.

Pour que What’s Up Docker effectue lui-même la mise à jour des conteneurs, vous devez utiliser un trigger de type . Le fait d’activer l’option permet de le déclarer, et en même temps de nettoyer la base d’images.

Ajoutez cette variable à votre configuration Docker Compose :

Nous sommes sur la configuration d’un trigger, donc nous pouvons utiliser le nom personnalisé que l’on souhaite. Ici, j’ai spécifié car cela me semble judicieux, puisque cette instance surveille le socket Docker de l’hôte local. Avec cette simple ligne, WUD passe d’un outil de monitoring à un outil d’automatisation des mises à jour Docker. Si une mise à jour est détectée lors du prochain scan (défini par votre CRON), l’opération sera lancée.

• What’s Up Docker – Documentation – Trigger Docker

La gestion des mises à jour avec Docker Compose

Le problème, c’est que vous utilisez probablement Docker Compose pour le déploiement de vos stacks Docker. Et, parfois, vous indiquez peut-être des versions statiques (tags) au niveau des images déclarées dans vos conteneurs…. C’est une contrainte spécifique à laquelle WUD peut aussi apporter une réponse.

Par exemple : vous déployez un conteneur MariaDB avec la ligne afin de fixer la version 10.11. Si WUD met à jour le conteneur vers une version plus récente en arrière-plan, votre fichier , lui, indiquera toujours . Donc, si vous êtes amené à relancer manuellement la stack Docker correspondante (via ), Docker réinstallera l’ancienne version, soit la . Ce qui aura été fait avec WUD n’aura donc servi à rien.

Pour répondre à ce besoin, WUD est capable de dérouler le workflow suivant :

• Mettre à jour le fichier associé à la stack Docker (la version 10.11 serait donc effacée au profit d’une autre plus récente),
• Clonez la spécification du conteneur existant.
• Récupérez la nouvelle image.
• Arrêtez le conteneur existant.
• Supprimez le conteneur existant.
• Créez le nouveau conteneur.
• Démarrez le nouveau conteneur (si le précédent était en cours d’exécution).
• Supprimez l’image précédente (facultatif).

Ce trigger fonctionne uniquement pour l’hôte Docker local et il a une contrainte majeure : le conteneur WUD doit pouvoir lire les fichiers Docker Compose () des conteneurs où il doit gérer les mises à jour automatiques.

Soit l’ajout de ces trois variables d’environnement :

Puis, de cette ligne dans la section pour lui donner accès au fichier :

Ici, WUD va surveiller les mises à jour pour l’application Uptime Kuma donc le fichier YAML est . Il y a donc un trigger spécifique pour Uptime Kuma, avec dans le nom des variables. Avec cette approche, il faut donc autant de triggers qu’il y a de stacks Docker Compose à gérer.

Soit l’ajout suivant dans la configuration si l’on veut gérer 2 fichiers Docker Compose différents :

Enregistrez et redémarrez le conteneur pour appliquer la configuration.

• What’s Up Docker – Documentation – Trigger Docker Compose

Inclure et exclure des triggers sur les conteneurs

Suite à la mise en place de 2 triggers Docker Compose et d’un trigger SMTP Gmail, vous pourrez constater que ces trois triggers apparaissent dans la liste des triggers de tous les conteneurs. C’est embêtant, car le déclencheur pour Ghost n’a rien à faire dans la gestion du conteneur Uptime Kuma…

Pour éviter cela, il faut jouer sur les labels au niveau de chaque conteneur. Actuellement, What’s Up Docker supporte 12 labels différents applicables sur vos conteneurs Docker. Il y a notamment des labels pour exclure ou inclure des triggers.

Je vais donc modifier le fichier Docker Compose du projet Uptime Kuma pour lui appliquer uniquement 2 triggers : la notification par e-mail avec Gmail et le Docker Compose lui correspondant. J’ajoute donc ces deux lignes :

Vous devez reprendre la fin des noms des déclencheurs : type + nom personnalisé.

What’s Up Docker peut aussi déclencher la mise à jour uniquement s’il s’agit d’une mise à jour mineure. Il y a une flexibilité importante grâce aux nombreux paramètres. Pour la gestion des tags et des versions, il est possible d’utiliser des regex : WUD effectue une analyse du versionnage sémantique (SemVer).

Pour cibler uniquement les mises à jour mineures, ajoutez l’indicateur de cette façon :

Après le redémarrage des conteneurs, il n’y a plus que 2 déclencheurs associés à Uptime Kuma. C’est donc une logique à appliquer plus largement pour utiliser cette approche où WUD pilote Docker Compose.

Toujours sur le même principe, vous pouvez aussi exclure certains conteneurs de la surveillance WUD via ce label :

Vous pouvez aussi désactiver la surveillance par défaut avec dans le Docker Compose de WUD et l’activer au cas par cas sur vos conteneurs grâce au label spécifié ci-dessus (avec la valeur ).

• What’s Up Docker – Documentation – Labels

Déclencher manuellement les mises à jour

Vous pouvez mettre en place la configuration telle qu’évoquée jusqu’ici tout en gardant la main sur les mises à jour. En effet, il y a un paramètre nommé , commun à tous les triggers, qui permet d’indiquer si le trigger se déclenche automatiquement ou non.

Si vous positionnez ce paramètre sur (alors que par défaut c’est ), WUD ne fera rien à votre place. Par contre, les triggers seront toujours visibles sur l’interface Web, donc vous pouvez lancer la mise à jour d’un simple clic. C’est un bon compromis !

La documentation mentionne ce paramètre de cette façon :

Si nous reprenons la configuration Docker Compose (ou Docker) précédente, cela donnerait :

Sinon, vous avez toujours le label évoqué précédemment pour exclure certains conteneurs de WUD.

Conclusion

La gestion des mises à jour de conteneurs ne doit pas être une corvée. What’s Up Docker offre une solution – extrêmement – configurable pour répondre à ce besoin. Vous avez le choix entre de la simple notification sur différents canaux, un mode “tout automatique” ou une approche hybride (avec notifications pour la production et des mises à jour automatiques pour vos tests, par exemple).

Enfin, notez que pour un usage en production, il est fortement recommandé de placer WUD derrière un Reverse Proxy (comme Traefik) pour activer le HTTPS.

Pour approfondir la configuration de WUD, je vous encourage à lire la documentation officielle :

• Documentation de What’s Up Docker

FAQ – What’s Up Docker