Durante un tiempo usé Watchtower para mantener los containers actualizados. Lo configuré en modo auto-update y durante unos meses fue perfecto. Luego un día me encontré con que un container había actualizado automáticamente a una versión que tenía un breaking change y me rompió el servicio.
Desde ese día tengo una política diferente: quiero saber que hay una actualización antes de aplicarla, no que se aplique sola. What’s Up Docker (WUD) cubre exactamente ese caso. Monitoriza tus containers, detecta cuando hay nuevas versiones, y te avisa. Tú decides cuándo y si actualizar.
El problema con Watchtower en modo automático#
Watchtower es una herramienta genial y la sigo usando, pero en modo “notify only”. El problema de auto-actualizar todo es que confías en que todas las actualizaciones son compatibles con tu configuración. A veces no lo son.
Algunos containers cambian variables de entorno entre versiones. Otros reorganizan los volúmenes. Los proyectos activos sacan versiones menores con cambios que técnicamente deberían ser compatibles pero en la práctica a veces no lo son.
WUD te da el control. Sabes qué hay disponible y actualizas cuando quieres.
Qué hace What’s Up Docker exactamente#
WUD se conecta a Docker (o Kubernetes, si tienes un cluster) y compara las versiones de las imágenes que tienes instaladas con las que están disponibles en los registries. Por defecto usa Docker Hub pero soporta otros registries privados también.
Cuando detecta una versión más nueva, puede avisarte por múltiples canales: Telegram, Slack, email, ntfy, webhook, Discord, y otros. Yo uso Telegram y funciona perfectamente.
También tiene una interfaz web donde ves el estado de todos tus containers, qué versión tienes y qué versión está disponible. Es útil para tener una visión rápida de cuánto de desactualizado está tu stack.
Lo que NO hace WUD por defecto es actualizar automáticamente. Puedes configurarlo para que lo haga, pero no es su función principal y yo no lo activo.
Instalación#
La instalación es con Docker Compose como siempre. Crea un directorio y el archivo de configuración:
| |
Necesitas montar el socket de Docker para que WUD pueda ver los containers. El volumen ./store es donde guarda el estado entre reinicios, para que no te spamee con notificaciones de cosas que ya sabías.
Para el bot de Telegram, si no tienes uno ya, lo creas con BotFather en Telegram en dos minutos. El chat ID lo consigues hablando con tu bot y consultando https://api.telegram.org/bot<TU-TOKEN>/getUpdates.
| |
La interfaz web queda en http://tu-servidor:3000.
Configurar qué containers monitoriza#
Por defecto WUD monitoriza todos los containers del sistema. Si tienes containers que prefieres ignorar, puedes excluirlos con una etiqueta en su configuración:
| |
También puedes hacer lo contrario: configurar WUD para que solo monitorice los que tienen la etiqueta activada explícitamente, cambiando WATCHBYDEFAULT a false y poniendo wud.watch=true solo en los que te interesen.
Yo lo tengo configurado con WATCHBYDEFAULT=true y excluyo manualmente los pocos containers que no quiero monitorizar.
Filtrar qué actualizaciones te interesan#
Aquí está la parte que más me gusta de WUD: puedes definir exactamente qué tipo de actualizaciones quieres que te notifiquen.
El parámetro THRESHOLD acepta estos valores:
major- solo cambios de versión mayor (1.x.x -> 2.x.x)minor- cambios menores (1.1.x -> 1.2.x)patch- parches (1.1.1 -> 1.1.2)
Si pones major,minor,patch, te notifica todo. Si pones solo major, solo te avisa cuando hay cambios de versión mayor.
Para la mayoría de containers yo quiero saber de todos los cambios, pero hay algunos donde me conformo con seguir solo los parches. Por ejemplo, bases de datos como PostgreSQL o MariaDB, donde prefiero no actualizar a versiones mayores sin haberlo probado antes.
Puedes configurarlo a nivel de container individual con etiquetas:
| |
Las etiquetas soportan expresiones regulares para filtrar qué versiones te interesan. Útil para containers que tienen ramas de versiones como latest, stable, v3, y solo quieres seguir las etiquetas de versión semántica.
Cómo se ven las notificaciones#
Las notificaciones de Telegram que manda WUD son claras y útiles. Te llega un mensaje con el nombre del container, la versión que tienes instalada y la versión nueva disponible. También incluye un enlace a la imagen en Docker Hub para que puedas revisar el changelog antes de actualizar.
Ejemplo de lo que recibirías:
| |
No te bombardea. Manda una notificación por container cuando detecta la actualización y luego no vuelve a molestarte con lo mismo hasta que cambies de versión. El estado se guarda en el volumen ./store.
La interfaz web#
La interfaz web de WUD es funcional. No es la más bonita del mundo, pero cumple. Tienes una tabla con todos tus containers, la versión instalada, la versión disponible y el estado.
Lo que más uso de la interfaz es el filtro por “has update”, que te muestra solo los containers que tienen actualizaciones pendientes. De un vistazo ves cuántas cosas tienes por actualizar y cuánto tiempo llevan pendientes.
También muestra información sobre las actualizaciones detectadas en los últimos días, útil para tener un historial de qué ha ido cambiando en tu stack.
Comparativa con Watchtower#
No es que WUD reemplace completamente a Watchtower. Son herramientas con enfoques diferentes.
Watchtower es simple y efectivo. Si lo que quieres es que tus containers se actualicen solos sin pensar en ello, Watchtower en modo auto-update es lo más sencillo. También tiene un modo de solo notificación que funciona bien.
WUD es más configurable. Tiene mejor interfaz web, más opciones de notificación, soporte para más tipos de registry, y las reglas de filtrado por versión son más potentes. Si quieres control fino sobre qué te notifica y cuándo, WUD es mejor.
Mi setup actual usa los dos:
- WUD para monitorizar y notificar
- Watchtower en modo “notify only” como capa adicional (por si WUD no detecta algo)
Es redundante pero los dos consumen tan pocos recursos que no hay motivo para elegir uno y desactivar el otro.
Configuración con múltiples registries#
Si tienes containers que vienen de repositorios privados o de registries que no son Docker Hub, WUD los soporta. Ghcr.io (GitHub Container Registry), quay.io, registries privados de Gitea, o tu propio registry privado.
Para un registry privado:
| |
Sustituyendo MYREGISTRY por el nombre que quieras darle. Después WUD usará ese registry para los containers que vengan de esa URL.
Para GitHub Container Registry:
| |
El token de GitHub necesita el permiso read:packages como mínimo.
Troubleshooting: versiones que no detecta#
WUD depende de que las imágenes tengan las etiquetas de versión correctas en el registry. Si el mantenedor solo publica con la etiqueta latest y no con versiones específicas, WUD no puede saber qué versión tienes instalada ni si hay algo más reciente.
Esto pasa con algunos proyectos más pequeños o de desarrollo activo que solo mantienen latest. En esos casos la opción es vigilarlos manualmente o dejar que Watchtower los actualice automáticamente.
Para containers con etiquetas no estándar, WUD tiene opciones de configuración para definir el patrón de versión que debe seguir:
| |
Esto le dice a WUD que solo considere como versiones válidas las etiquetas que empiecen por v seguido de tres números separados por puntos.
Cuando veo un container que WUD no monitoriza bien, generalmente es por esto. La solución es añadir la etiqueta correcta al container en el compose file.
Recursos que consume#
WUD es muy ligero. En reposo consume menos de 100 MB de RAM y prácticamente nada de CPU. Solo hace peticiones a los registries periódicamente para comprobar versiones, lo cual no consume mucho.
Puedes configurar el intervalo de comprobación con la variable WUD_WATCHER_LOCAL_CRON. Por defecto comprueba cada 5 minutos, que me parece excesivo. Yo lo tengo a 0 */4 * * * para que compruebe cada 4 horas:
| |
Para un homelab no necesitas saber de actualizaciones con menos de 4-6 horas de retraso.
Integración con ntfy y otros canales#
Si tienes ntfy instalado en tu homelab (lo expliqué en un post reciente: ntfy: notificaciones push self-hosted), WUD tiene soporte nativo para él:
| |
También funciona con Discord, Slack, Home Assistant webhooks, y un webhook genérico para integrarlo con n8n o cualquier otra herramienta.
Por qué lo recomiendo#
WUD resuelve un problema concreto de forma limpia. Antes de tenerlo, mi rutina era revisar manualmente cada cierto tiempo si había actualizaciones, o confiar en Watchtower para que lo hiciera solo. Las dos opciones tienen sus problemas.
Con WUD me llega una notificación a Telegram cuando hay algo disponible, veo en un segundo qué es, y decido si actualizo ahora o lo dejo para el finde semana. Ese control es lo que me faltaba.
No es un proyecto enorme ni tiene una comunidad masiva, pero está bien mantenido y hace lo que dice que hace. Para el homelab, con eso es suficiente.
Si ya tienes Watchtower o haces actualizaciones manuales, WUD complementa ambos enfoques sin reemplazarlos.