Watchtower: actualizar contenedores Docker automáticamente
Watchtower monitoriza tus contenedores Docker y los actualiza cuando detecta una imagen nueva. Te cuento cómo configurarlo, qué puedes ajustar y cuándo conviene más no usarlo.
Si ya tienes contenedores corriendo, esto es para ti
Tienes Jellyfin, Nextcloud, Home Assistant y tres servicios más levantados en casa. Funcionan. Tocas lo mínimo posible porque cada vez que actualizas algo manualmente hay un momento de tensión: ¿va a seguir arrancando? ¿Ha cambiado algo en la configuración? ¿Tengo un backup de lo que había antes?
Watchtower nació exactamente para ese perfil. No es una herramienta de devops enterprise ni necesitas entender CI/CD para usarla: es un contenedor más que vigila los demás y los actualiza cuando hay imagen nueva, con los mismos parámetros que ya tenían. En este post te cuento cómo lo tengo configurado, qué opciones merece la pena activar y — igual de importante — qué no hace Watchtower para que no te lleves una sorpresa.
Si alguna vez has pensado «debería mantener esto más al día pero no tengo ganas de hacerlo a mano cada semana», aquí tienes una respuesta concreta y sin magia negra.
Por qué importa
Polling cada 24 horas
Por defecto comprueba actualizaciones cada 86400 segundos. Ajústalo con –interval según tu tolerancia al riesgo.
Excluye lo que no quieras
Pon la etiqueta com.centurylinklabs.watchtower.enable=false en cualquier contenedor que prefieras actualizar tú manualmente.
Rollback es manual
Watchtower no revierte fallos. Si la nueva imagen rompe algo, tocas docker pull con la versión anterior tú mismo.
Limpia imágenes viejas
El flag –cleanup elimina las imágenes anteriores tras actualizar, evitando que el disco se llene silenciosamente.
Cómo funciona Watchtower por dentro
Watchtower es en sí mismo un contenedor Docker. Se lanza una vez y se queda corriendo en segundo plano, con acceso al socket Unix de Docker (/var/run/docker.sock). Desde ahí puede ver todos los contenedores que tienes en marcha, igual que hace docker ps.
Cada cierto tiempo —por defecto, cada 24 horas— Watchtower pregunta al registro de imágenes (Docker Hub u otro) si hay una versión más nueva. Lo hace comparando el digest SHA256 de la imagen local con el del registro. Si coinciden, no hace nada. Si hay diferencia, descarga la nueva imagen y reinicia el contenedor con exactamente los mismos parámetros: volúmenes, puertos, variables de entorno, todo.
Ojo: no es un sistema push. Watchtower hace polling periódico, así que hay una ventana de tiempo entre que sale una actualización y que tu servidor la recoge. Para un homelab esto no suele importar, pero conviene saberlo.
Instalación con docker-compose
La forma más cómoda de lanzar Watchtower es con un docker-compose.yml dedicado. Así tienes la configuración en un fichero versionado y puedes tocarlo cuando quieras sin recordar flags de memoria.
services:
watchtower:
image: containrrr/watchtower
container_name: watchtower
restart: unless-stopped
volumes:
- /var/run/docker.sock:/var/run/docker.sock
environment:
- WATCHTOWER_POLL_INTERVAL=43200
- WATCHTOWER_CLEANUP=true
- TZ=Europe/Madrid
Con WATCHTOWER_CLEANUP=true las imágenes viejas se eliminan tras actualizar. Si tienes poco espacio en disco —un NAS compacto, una Raspberry Pi— esto ayuda bastante. Si prefieres conservar la imagen anterior para volver atrás a mano en caso de problema, quítalo.
Arranca el servicio con:
docker compose up -dY para ver qué está haciendo en tiempo real:
docker logs -f watchtowerControlar qué se actualiza y cuándo
Ajustar el intervalo de comprobación
El valor por defecto (86400 segundos = 24 horas) es razonable para la mayoría de homelabs. Si quieres actualizaciones más frecuentes, bajas el número. Si prefieres un ritmo más lento, lo subes. El intervalo se configura como variable de entorno o como argumento directo al contenedor:
# Como variable de entorno
WATCHTOWER_POLL_INTERVAL=21600 # 6 horas
# Como argumento al contenedor
command: --interval 21600
Recuerda que es polling, no push: cada tick Watchtower consulta el registro. El consumo de recursos es mínimo, pero existe. Intervalos muy cortos (menos de una hora) rara vez tienen sentido salvo casos muy concretos.
Excluir contenedores de las actualizaciones
Hay servicios que es mejor no tocar con Watchtower: bases de datos con migraciones en curso, servicios que usas con una versión fija por compatibilidad, o cosas que prefieres actualizar a mano revisando el changelog antes. Para excluirlos, añades una etiqueta al contenedor:
services:
mi-base-de-datos:
image: postgres:15
labels:
- "com.centurylinklabs.watchtower.enable=false"
Con esa etiqueta, Watchtower ignora ese contenedor completamente. Si prefieres el enfoque contrario —opt-in en lugar de opt-out—, arranca Watchtower con --label-enable y solo actualizará los contenedores que tengan watchtower.enable=true de forma explícita.
Notificaciones cuando algo cambia
Watchtower puede avisarte cada vez que actualiza un contenedor. Soporta Slack, email, y mediante Shoutrrr también Gotify, Telegram, Ntfy y otros. Si ya tienes Gotify en tu homelab, la configuración es directa:
environment:
- WATCHTOWER_NOTIFICATIONS=shoutrrr
- WATCHTOWER_NOTIFICATION_URL=gotify://tu-servidor-gotify/TOKEN_APP
Para Telegram el formato de URL de Shoutrrr es:
telegram://TOKEN_BOT@telegram?chats=CHAT_ID
Si no quieres actualizaciones automáticas todavía pero sí quieres saber qué hay desactualizado, activa el modo monitor-only:
environment:
- WATCHTOWER_MONITOR_ONLY=true
En este modo Watchtower detecta imágenes nuevas y notifica, pero no toca nada. Es una buena forma de empezar: llevas una semana viendo qué se actualiza y con qué frecuencia antes de soltar el freno de mano.
El rollback no es automático: qué hacer si algo falla
Aquí hay que ser claro: Watchtower no hace rollback. Si un contenedor falla después de actualizarse, no vuelve solo a la versión anterior. Tendrás que hacerlo a mano.
El procedimiento habitual es bajar la versión concreta que funcionaba y relanzar el contenedor con ella:
# Bajar una versión concreta
docker pull mi-app:1.23.0
# Parar y eliminar el contenedor fallido
docker stop mi-contenedor
docker rm mi-contenedor
# Relanzar con la versión buena
docker run ... mi-app:1.23.0
Precisamente por esto, si tienes servicios que no puedes permitirte que fallen —un Vaultwarden con tus contraseñas, un Home Assistant que controla la calefacción— lo más sensato es usar tags de versión fija en lugar de latest. Así decides tú cuándo actualizar, y puedes revisar el changelog antes:
image: vaultwarden/server:1.31.0 # en lugar de :latest
Watchtower actualiza comparando digests: si la etiqueta es un número de versión fijo, solo actualizará si el mantenedor mueve esa etiqueta a otro digest. Con versiones numeradas eso no pasa por sorpresa. Además, usar latest en proyectos que no siguen semver de forma estricta es una invitación a breaking changes inesperados.
Cuándo usar Watchtower y cuándo mejor no
Watchtower encaja bien en un homelab donde tienes servicios de bajo riesgo: Jellyfin, Uptime Kuma, Portainer, dashboards de monitorización, bots de Telegram. Servicios que si se caen diez minutos no pasa nada grave y que preferirías tener siempre en la última versión sin acordarte de actualizarlos manualmente.
- Sí tiene sentido usarlo con: servicios stateless o con datos bien separados en volúmenes, imágenes de proyectos activos con buenas prácticas de versionado, entornos donde las actualizaciones de seguridad importan más que la estabilidad puntual.
- Tiene más riesgo con: bases de datos (una actualización puede requerir migración de esquema), servicios con historial de breaking changes frecuentes, imágenes que usas con
latestde proyectos que no siguen semver de forma estricta.
En entornos de producción real lo habitual es lo contrario: tags de versión fija, pipelines de CI que actualizan de forma controlada y con tests previos. Watchtower es una herramienta pensada para uso personal y homelab, y eso no es ningún defecto.
Mi configuración actual en casa: Watchtower con intervalo de 12 horas, cleanup activado, notificaciones a Gotify, y un par de contenedores con watchtower.enable=false —Vaultwarden y Home Assistant, que prefiero actualizar revisando el changelog—. El resto, en modo automático. Llevas días sin acordarte de que existe y tus contenedores van actualizados. No es glamuroso, pero funciona.
Javier — Maker, sysadmin y trastero serial
Preguntas frecuentes
Q: ¿Qué pasa si la nueva imagen rompe mi servicio?
A: Watchtower no hace rollback automático: si la imagen actualizada falla, tienes que volver manualmente con 'docker pull imagen:versión-anterior' o reetiquetando la imagen anterior. Por eso en servicios críticos conviene fijar tags explícitos (v2.3.1 en vez de latest) y dejar Watchtower solo para servicios donde un fallo temporal es asumible.
Q: ¿Cada cuánto comprueba Watchtower si hay actualizaciones?
A: Por defecto cada 86400 segundos (24 horas). Puedes cambiarlo con '--interval N' o la variable WATCHTOWER_POLL_INTERVAL. Es polling periódico, no push: cada ciclo hace una consulta al registro, lo que consume recursos mínimos pero no es instantáneo.
Q: ¿Cómo excluyo un contenedor concreto de las actualizaciones?
A: Añade la etiqueta 'com.centurylinklabs.watchtower.enable=false' al contenedor que quieres proteger. Watchtower la lee al arrancar y lo ignora en cada ciclo de actualización, sin necesidad de cambiar nada en la configuración global.
Q: ¿Vale Watchtower para un entorno de producción real?
A: Depende del nivel de criticidad. Para homelab o servicios personales funciona bien. En producción con usuarios reales se recomienda fijar tags de versión explícitos y un pipeline de CI/CD con tests antes de actualizar: actualizar a 'latest' puede introducir breaking changes si el mantenedor no sigue semver correctamente.
Q: ¿Puedo usarlo solo para monitorizar sin que actualice nada?
A: Sí, con '--monitor-only' Watchtower detecta nuevas imágenes disponibles y lanza notificaciones (Slack, Telegram vía Shoutrrr, email...) pero no toca ningún contenedor. Es útil para auditar qué está desactualizado antes de decidir si actualizas manualmente o dejas que lo haga solo.
Deja una respuesta