El problema: imágenes Docker que envejecen en silencio
En un VPS en producción, los contenedores Docker suelen funcionar durante semanas o meses sin actualizarse. No es negligencia — simplemente no hay ninguna señal. La imagen nginx:latest que descargaste en enero sigue ahí en septiembre, con las vulnerabilidades que se han corregido desde entonces.
El coste de no hacer nada está documentado: los CVE no parcheados en las imágenes base son uno de los vectores de entrada más comunes en infraestructuras Docker autoalojadas. La actualización manual — conectarse al VPS, ejecutar docker pull, recrear el contenedor — es la práctica habitual. También es la menos fiable: se pospone, se olvida y solo se actualizan los servicios «importantes».
Han surgido dos herramientas para estructurar este proceso: Watchtower, que automatiza la actualización en sí misma, y Diun (Docker Image Update Notifier), que envía una alerta cuando hay una nueva imagen disponible y deja la acción a tu pipeline. No hacen lo mismo, y confundir las dos filosofías puede provocar una caída en producción.
Watchtower: actualización automática, pero archivado desde finales de 2025
Watchtower monitoriza tus contenedores en ejecución, consulta los registries a intervalos regulares y, en cuanto hay una nueva imagen disponible, descarga el nuevo tag, detiene el contenedor existente y lo recrea con las mismas opciones — volúmenes, variables de entorno, red. Todo sin intervención humana.
Lo que hace en la práctica:
- Polling configurable por duración (cada N segundos) o expresión cron
- Soporte de registries privados con autenticación
- Modo WATCHTOWER_NOTIFICATIONS para recibir alertas sin realizar actualizaciones
- Filtrado por labels de Docker para incluir o excluir contenedores concretos
El riesgo en producción es real. Si una imagen :latest introduce un cambio incompatible de API o un comportamiento que rompe algo, Watchtower recreará tu contenedor con esa imagen — sin pruebas, sin ventana de mantenimiento, potencialmente a las 3 de la madrugada. El contenedor se reinicia con la versión incorrecta, y el descubrimiento llega a través de una alerta de monitorización o una llamada de soporte.
Actualización importante sobre el estado: el repositorio de Watchtower en GitHub fue archivado por sus mantenedores el 17 de finales de 2025. Ahora es de solo lectura. La última versión publicada es la v1.7.1. El proyecto sigue siendo funcional y las imágenes Docker existentes continúan funcionando, pero ya no recibirá correcciones de seguridad, nuevas funcionalidades ni soporte para futuras versiones de Docker. Para una herramienta cuyo rol es actualizar tus imágenes, la ironía no es menor.
Para entornos de desarrollo o homelabs donde la comodidad supera a la estabilidad, Watchtower sigue siendo una opción legítima. Para producción, su archivado refuerza una conclusión que ya existía: las actualizaciones automáticas sin un pipeline de validación son un riesgo operativo.
Watchtower en modo notify-only
Si ya usas Watchtower y quieres desactivar las actualizaciones automáticas manteniendo las notificaciones, establece la variable WATCHTOWER_MONITOR_ONLY=true. El contenedor monitoriza las imágenes y envía alertas, pero no actúa. Es una configuración de transición útil si estás migrando a Diun.
Diun: solo alertas, tú mantienes el control
Diun (Docker Image Update Notifier) aborda el problema desde el otro ángulo: monitoriza tus imágenes en los registries y te envía una notificación cuando hay una nueva versión disponible. No actúa. Tus contenedores siguen funcionando sin cambios — la decisión de actualizar permanece en tu pipeline.
Con licencia MIT, Diun está en desarrollo activo: la versión la version actuelle se publicó el recientemente. El proyecto cubre un amplio espectro de fuentes (Docker, Containerd, Kubernetes, Swarm, Nomad, Dockerfile, archivo de configuración) y canales de notificación.
Canales de notificación soportados:
- Correo electrónico, Slack, Telegram, ntfy, Gotify
- Microsoft Teams, Discord, webhooks genéricos
- Healthchecks.io para monitorizar el propio watcher
Lo que Diun no hace:
- Nunca descarga una imagen
- Nunca reinicia un contenedor
- Nunca modifica ningún archivo de configuración
Esta filosofía es precisamente lo que lo hace adecuado para producción. Cuando Diun señala que hay una nueva imagen disponible, puedes activar tu pipeline de despliegue habitual — con sus pruebas, copia de seguridad previa y ventana de mantenimiento. Te mantienes en una postura controlada.
Diun también es compatible con stacks gestionados por herramientas como Portainer, Coolify o Dokploy: observa las imágenes sin interferir en su orquestación.
Cuándo elegir uno u otro
Desplace la tabla
| Contexto | Watchtower | Diun |
|---|---|---|
| Entorno de dev / staging | Aceptable (comodidad) | Sobredimensionado |
| Prod con tags versionados (no :latest) | Evitar — recrea con el mismo tag | Recomendado |
| Prod con dependencias de API de terceros | Arriesgado sin prueba previa | Recomendado |
| Homelab / servicios personales | Práctico | Correcto si las alertas están activas |
| Stack gestionado por Coolify, Dokploy, Portainer | Posible conflicto con el orquestador | Recomendado |
| Proyecto sin pipeline de despliegue | Aceptable con monitor-only | Recomendado con ntfy/Slack |
Instalar Diun en un VPS: ejemplo práctico
La instalación de Diun se realiza en pocos minutos con Docker Compose. El siguiente ejemplo monitoriza todos los contenedores del socket Docker local y envía notificaciones vía ntfy.
Desplegar Diun en tu VPS
Crear el archivo docker-compose.yml
Crea un directorio dedicado y el archivo Compose:
mkdir -p /opt/diun && cd /opt/diunContenido del archivo
docker-compose.yml:services: diun: image: crazymax/diun:latest restart: unless-stopped volumes: - /var/run/docker.sock:/var/run/docker.sock - ./data:/data environment: - TZ=Europe/Paris - LOG_LEVEL=info - DIUN_WATCH_WORKERS=20 - DIUN_WATCH_SCHEDULE=0 */6 * * * - DIUN_PROVIDERS_DOCKER=true - DIUN_PROVIDERS_DOCKER_WATCHSTOPPED=true - DIUN_NOTIF_NTFY_ENDPOINT=https://ntfy.example.com - DIUN_NOTIF_NTFY_TOPIC=diun-updatesSustituye
ntfy.example.compor la URL de tu instancia de ntfy (autoalojada en el mismo VPS o externa).Activar monitorización por label (opcional)
Por defecto, Diun monitoriza todos los contenedores. Para un control más fino, cambia al modo label:
- DIUN_PROVIDERS_DOCKER_WATCHBYDEFAULT=falseLuego añade el label en los contenedores que quieres monitorizar:
labels: - "diun.enable=true"Este enfoque es útil para excluir los contenedores del sistema (proxies, bases de datos) de las notificaciones, y monitorizar solo los contenedores de aplicación.
Iniciar y verificar
docker compose up -d docker compose logs -f diunDiun realiza un primer pase de descubrimiento al arrancar. Los logs confirman las imágenes detectadas y el próximo ciclo de monitorización. Se puede lanzar una notificación de prueba con:
docker compose exec diun diun notif testActivar la actualización desde tu pipeline
Cuando Diun envía una notificación, la actualización no debe hacerse a mano. El enfoque correcto es activar tu pipeline habitual — un webhook de Gitea, una GitHub Action, o un job de Woodpecker que descargue la nueva imagen, ejecute tus pruebas y recree el contenedor.
Si aún no tienes un pipeline, el mínimo viable es un script llamado desde el webhook de ntfy:
#!/bin/bash # update-container.sh <nombre_contenedor> CONTAINER=$1 docker compose -f /opt/${CONTAINER}/docker-compose.yml pull docker compose -f /opt/${CONTAINER}/docker-compose.yml up -dLo esencial es que la actualización se active de forma intencionada, no en silencio.
Ir más lejos: fijar versiones y mantener el control
Las actualizaciones automáticas sin un tag fijo son el riesgo real — ya sea con Watchtower o con un pipeline activado por Diun. El tag :latest es un alias que puede apuntar a cualquier versión publicada por el mantenedor. Una actualización de :latest puede introducir un cambio incompatible sin que nada en tu configuración cambie.
La práctica recomendada por la comunidad Docker:
Fija las versiones en tus archivos docker-compose.yml en producción:
# Evitar en prod
image: nginx:latest
# Preferir un tag de versión
image: nginx:1.27Reserva :latest para los entornos de desarrollo y staging, donde una regresión es detectable antes de afectar a producción.
Con imágenes versionadas, Diun detecta las nuevas releases (nuevos tags) y te notifica — tú eliges la versión a la que migrar, actualizas tu docker-compose.yml y despliegas con control total. Esto es lo que el checklist de producción de Docker Compose llama «declarar explícitamente tus dependencias».
Si gestionas múltiples contenedores en el mismo VPS, una herramienta de monitorización de logs como Dozzle complementa útilmente a Diun: Diun monitoriza las imágenes en origen, Dozzle observa los logs de los contenedores tras una actualización.
Diun también monitoriza imágenes detenidas
Por defecto, Diun ignora los contenedores detenidos. Activa DIUN_PROVIDERS_DOCKER_WATCHSTOPPED=true para monitorizar también las imágenes de contenedores en pausa o detenidos — útil si gestionas servicios batch o contenedores de mantenimiento que reinicias periódicamente.
Lo que retener de esta comparativa
- Watchtower actúa sin pedirte opinión — útil en desarrollo, arriesgado en producción, y archivado desde el 17 de finales de 2025.
- Diun informa sin actuar — compatible con cualquier pipeline de despliegue existente y mantenido activamente (la version actuelle).
- Para producción, Diun combinado con tu pipeline es la opción más robusta.
- Fijar versiones en docker-compose.yml sigue siendo la base — ni Watchtower ni Diun reemplazan una gestión explícita de tags.
- Si tienes Watchtower instalado, el modo
WATCHTOWER_MONITOR_ONLY=truees una transición inmediata hacia un comportamiento más seguro.
