Actualizar contenedores en un homelab parece una tarea pequeña hasta que deja de serlo. Al principio tienes cuatro servicios, todos dan un poco igual y cualquier actualización se resuelve con bajar una imagen nueva y reiniciar. Luego aparecen Vaultwarden, Home Assistant, Paperless, Immich, el reverse proxy, DNS, monitorización, automatizaciones y algún servicio que alguien de casa ya usa sin saber ni cómo se llama.
Ahí actualizar deja de ser un gesto técnico y pasa a ser mantenimiento real.
He probado varias formas de llevar esto: actualizaciones manuales, Watchtower en modo automático, avisos de nuevas versiones, Dockge para revisar stacks, scripts caseros y la maravillosa estrategia de “ya lo miraré otro día”, que es cómoda hasta que tienes veinte imágenes viejas y una vulnerabilidad con nombre de villano.
Mi conclusión actual es bastante simple: no actualizar todo solo y no actualizar todo a mano. Lo sensato está en medio. Automatizar contenedores de bajo riesgo, avisar en los críticos, tener backups antes de tocar datos y separar servicios domésticos de juguetes.
Porque sí, Watchtower puede ser muy cómodo. También puede romperte una tarde si lo dejas conducir sin cinturón.
El problema de fondo: no todos los contenedores importan igual#
En Docker todo parece parecido. Una imagen, un contenedor, un volumen, unos puertos. Pero en casa no todos tienen el mismo peso.
No es lo mismo actualizar un lector RSS que actualizar el gestor de contraseñas. No es lo mismo romper una app de pruebas que dejar sin DNS a toda la red. No es lo mismo reiniciar un dashboard que migrar una base de datos de fotos familiares.
Esa es la primera clasificación que haría antes de tocar herramientas:
- Servicios críticos de casa.
- Servicios importantes pero no urgentes.
- Servicios personales de bajo impacto.
- Laboratorio y pruebas.
Críticos son los que, si fallan, molestan a más personas o bloquean algo básico. DNS, reverse proxy, VPN, gestor de contraseñas, Home Assistant si la casa depende de él, backups y almacenamiento.
Importantes son servicios con datos valiosos, pero que pueden esperar. Paperless, Immich, Gitea, notas, recetas, automatizaciones no urgentes.
Bajo impacto es lo que puedo romper sin drama: dashboards, lectores RSS, herramientas internas, paneles de estadísticas.
Laboratorio es todo lo que existe para romperse. Ahí no pondría protecciones excesivas. Si algo explota, era parte del contrato.
Esta clasificación vale más que cualquier herramienta. Sin ella, Watchtower actualiza lo que pilla y Dockge se convierte en una lista bonita sin criterio.
Watchtower: útil, pero no como piloto automático total#
Watchtower hace una cosa muy tentadora: mira si hay imágenes nuevas y recrea contenedores con la versión actualizada. Para un homelab, eso suena perfecto. Menos mantenimiento, menos imágenes viejas, menos entrar por SSH.
El problema es que “hay imagen nueva” no significa “deberías desplegarla ahora”.
Una actualización puede traer:
- Cambio de configuración.
- Migración de base de datos.
- Cambio en variables de entorno.
- Imagen rota durante unas horas.
- Cambio de permisos en volúmenes.
- Nuevo requisito de versión de PostgreSQL, Redis o similar.
- Incompatibilidad con plugins o integraciones.
En servicios simples, da igual. En servicios con datos, no tanto.
Por eso no usaría Watchtower en modo automático para todo. Lo usaría por etiquetas. Algo así a nivel conceptual:
- Autoactualizar servicios sin datos críticos.
- Solo notificar en servicios importantes.
- Ignorar contenedores delicados.
- Programar ejecución en una ventana tranquila.
La idea no es tener miedo a actualizar. Es evitar que una imagen nueva decida por ti a las tres de la mañana.
Dockge: menos magia, más control#
Dockge me gusta para homelab porque trabaja cerca de Docker Compose y no intenta esconder demasiado. Ves los stacks, editas compose, levantas, paras, revisas logs y mantienes cierta estructura. No es tan mágico como otros paneles y eso, en mantenimiento, es una virtud.
Para actualizaciones, Dockge encaja mejor como centro de control manual. No sustituye una política, pero ayuda a ejecutarla.
Mi flujo ideal sería:
- Recibir aviso de imagen nueva.
- Revisar changelog si el servicio importa.
- Comprobar backup reciente.
- Actualizar stack desde Dockge o desde terminal.
- Revisar logs.
- Abrir el servicio y probar lo básico.
- Anotar si hubo cambio raro.
Esto suena más lento que Watchtower automático porque lo es. Pero no hace falta aplicarlo a todo. Lo aplicaría a los servicios donde una actualización fallida cuesta más que cinco minutos de revisión.
Dockge también tiene una ventaja práctica: deja los compose visibles. Para mí, eso es importante. En cuanto una herramienta guarda demasiada configuración en una base de datos propia, me pongo nervioso. Prefiero que los stacks puedan vivir en Git o al menos copiarse como ficheros normales.
Un homelab mantenible no depende de recordar dónde pulsaste un botón hace seis meses.
Mi política de actualizaciones#
La política que usaría en casa cabe en pocas líneas:
- Críticos: actualizar manualmente, con backup reciente y revisión rápida de changelog.
- Importantes: aviso automático, actualización manual semanal o quincenal.
- Bajo impacto: actualización automática en ventana nocturna o de baja actividad.
- Laboratorio: automático o manual según apetezca.
No hace falta más ceremonia. Lo importante es que exista una regla antes del susto.
Ejemplos concretos:
Vaultwarden: manual. Backup antes. Revisar release notes. Probar login y 2FA después.
Home Assistant: manual. Leer cambios relevantes. Hacer snapshot o backup. Actualizar cuando puedas arreglarlo si algo rompe.
Immich: manual y con calma. Es un proyecto que se mueve rápido y toca fotos familiares. No lo pondría en actualización automática alegremente.
Paperless-ngx: manual o semimanual. Backup de base de datos y media. Probar subida y OCR después.
Uptime Kuma: puede ser semiautomático, pero si depende de él tu alerta principal, mejor no romperlo sin mirar.
Dashboards, lectores RSS o herramientas pequeñas: automático si los volúmenes están respaldados y no hay drama si caen un rato.
Esta política no es perfecta. Es práctica. Y en casa, práctico gana.
El papel de los backups#
No hay política de actualizaciones seria sin backups. Da igual que uses Watchtower, Dockge, Portainer o terminal. Si actualizas un servicio con base de datos y no puedes volver atrás, estás apostando.
Yo quiero tres cosas antes de tocar un servicio importante:
- Backup de la base de datos.
- Backup de los volúmenes relevantes.
- Saber cómo restaurarlo.
La tercera es la que suele faltar. Todo el mundo tiene backups. Mucha menos gente tiene restauraciones probadas.
Para contenedores, me gusta separar datos de configuración:
compose.ymly.envbajo control claro.- Volúmenes persistentes identificados.
- Dumps de bases de datos para PostgreSQL, MariaDB o SQLite si aplica.
- Copia externa o al menos fuera de la misma VM.
No hace falta montar una plataforma enorme. Pero si un servicio importa, el backup tiene que existir antes de la actualización, no después del primer grito.
Un detalle tonto pero útil: antes de actualizar, miro si el backup reciente es de verdad reciente. “Hay un cron” no significa “ha funcionado”. Ya he aprendido esa lección en suficientes formatos.
Versiones fijas o latest#
La etiqueta latest es cómoda y traicionera. Para servicios de laboratorio no me importa. Para servicios importantes, prefiero fijar versiones o al menos controlar cuándo se mueve la imagen.
Usar latest con Watchtower automático es básicamente decir: “confío en que cualquier cambio publicado por este proyecto encaje con mi instalación ahora mismo”. A veces es verdad. A veces no.
Mi criterio:
- Laboratorio:
latestsin demasiada culpa. - Bajo impacto:
latestcon backups y autoactualización razonable. - Importantes: versión fijada o actualización manual desde una versión conocida.
- Críticos: versión fijada y cambio deliberado.
Fijar versiones añade trabajo, claro. También evita sorpresas. La clave está en no aplicarlo a todo con la misma intensidad. Si fijas versiones de veinte servicios que no importan, te creas una tarea mensual aburrida. Si no fijas nada crítico, te compras un susto futuro.
Ventanas de mantenimiento domésticas#
En empresa se habla de ventanas de mantenimiento con seriedad. En casa la ventana es más simple: cuando nadie va a necesitarlo y tú tienes energía para arreglarlo.
No actualizaría servicios críticos:
- Antes de salir de casa.
- Antes de dormir.
- Mientras alguien está usando el servicio.
- En medio de una semana especialmente caótica.
- Desde el móvil por impaciencia.
Sí actualizaría:
- Por la mañana o tarde con margen.
- Después de comprobar backup.
- Cuando puedo mirar logs.
- En lotes pequeños.
Lo de lotes pequeños es importante. Actualizar doce servicios a la vez y descubrir que algo se rompió es una forma excelente de perder tiempo. Mejor tres cambios, prueba básica y seguir. Menos épico, más recuperable.
Qué automatizaría de verdad#
Automatizar no significa dejar que todo se actualice solo. Hay automatizaciones más útiles:
- Avisar de imágenes nuevas.
- Comprobar si los backups recientes existen.
- Listar servicios con versiones antiguas.
- Recordar mantenimiento semanal.
- Revisar contenedores reiniciándose.
- Comprobar espacio en disco antes de tirar imágenes.
- Mandar una alerta si una actualización automática falla.
Esto me interesa más que el auto-update total. La automatización buena reduce ceguera. La mala ejecuta cambios que no entiendes.
Watchtower puede usarse en modo notificación. También hay herramientas como What’s Up Docker para avisar de updates disponibles. Dockge ayuda a ejecutar. Uptime Kuma valida que lo básico responde. Ninguna de estas piezas, por separado, arregla la falta de criterio.
Un flujo semanal razonable#
Para un homelab familiar, haría algo así una vez por semana:
- Revisar avisos de imágenes nuevas.
- Separar bajo impacto de importante.
- Confirmar backups de servicios importantes.
- Actualizar primero bajo impacto.
- Probar que siguen vivos.
- Actualizar uno o dos importantes.
- Revisar logs.
- Limpiar imágenes antiguas solo si todo está estable.
Esto no debería llevar una tarde entera. Si lleva demasiado, tienes demasiados servicios, demasiada complejidad o una política demasiado ambiciosa.
También dejaría algunas actualizaciones para más adelante sin culpa. No todo update tiene que entrar el mismo día. Si un servicio funciona, no está expuesto y el changelog no trae nada relevante, puede esperar a una ventana mejor.
La urgencia real viene de seguridad, bugs importantes o compatibilidad. El resto muchas veces es jardinería.
Señales de que te estás pasando#
Hay señales claras de que la política de contenedores se ha ido de las manos:
- Tienes más herramientas para actualizar que servicios importantes.
- Nadie sabe qué se actualiza solo.
- El backup depende de acordarte a mano.
- Usas
latesten servicios con datos valiosos. - Watchtower actualiza cosas críticas sin avisar.
- No hay forma rápida de volver a una versión anterior.
- Tienes miedo de tocar cualquier stack.
Ese último punto suele decir bastante. Si te da miedo actualizar, no necesitas más automatización. Necesitas entender dependencias, backups y recuperación.
El objetivo no es tener todo siempre a la última. El objetivo es tener servicios seguros, mantenibles y recuperables. Hay una diferencia.
Mi recomendación final#
Si tuviera que dejarlo en una configuración sensata para casa, sería esta:
- Dockge como panel de stacks Docker Compose.
- Watchtower solo para autoactualizar servicios de bajo riesgo o para notificar.
- Versiones fijadas en servicios críticos.
- Backups diarios para datos importantes.
- Mantenimiento semanal corto.
- Nada de actualizaciones críticas sin margen para arreglar.
Y sobre todo, una lista clara de qué servicios importan. Sin esa lista, todo parece igual hasta que algo rompe.
Actualizar contenedores no debería ser una ruleta. Tampoco debería ser una tarea manual infinita. La gracia está en saber dónde puedes confiar en la automatización y dónde conviene seguir mirando con ojos humanos.
En mi casa, la regla sería sencilla: si lo usa la familia o guarda datos importantes, no se toca solo. Si es un juguete o una herramienta menor, que se actualice y ya veremos. El homelab tiene que trabajar para nosotros, no convertirse en otro jefe pequeño con icono de ballena.