Cómo Actualizar Stacks de Docker Compose en Dokploy (2026)
Aprende a actualizar stacks de Docker Compose en Dokploy en 2026: el nuevo toggle pull-latest-images, el fallback por SSH, automatización con CLI y auto-actualizaciones con Tugtainer.
20 min de lectura
Actualizar stacks de Docker Compose en Dokploy solía significar entrar por SSH al servidor y ejecutar docker compose pull a mano. Ya no. Las versiones actuales de Dokploy v0.30.x incluyen un toggle nativo “Pull latest images on deploy”, así que un Rebuild descarga la imagen más reciente para cada tag latest del stack. Esta guía cubre el flujo completo de actualización en Dokploy: el toggle nativo, el fallback por SSH, la automatización con la CLI de Dokploy, Schedules o Tugtainer, además de stacks con versiones fijadas, limpieza y rollback. Si leíste la versión anterior de este artículo: el botón que antes se llamaba Reload ahora es Rebuild.
¿Nuevo en Dokploy? Empieza con la guía de instalación de Dokploy. Para desplegar tu primera app, consulta Cómo desplegar una app de Docker Compose en Dokploy.
¿Por qué actualizar tus stacks de Docker Compose?
Las imágenes de contenedor antiguas se quedan en tu VPS con vulnerabilidades conocidas. Actualizar un stack de Docker Compose en Dokploy con una cadencia regular te da:
- Parches de seguridad - Correcciones de CVE para vulnerabilidades descubiertas
- Correcciones de errores - Problemas que los mantenedores por fin resolvieron
- Nuevas funciones - Capacidades añadidas desde tu último despliegue
- Compatibilidad - Mantenerse al día con cambios de API y dependencias
La misma lógica aplica al propio panel. Dokploy corrigió problemas graves en v0.29.13 (correcciones de inyección de comandos e IDOR entre organizaciones, 2026-07-21) y v0.30.0 (inyección de comandos en serviceName de compose, además de una subida de Traefik de v3.6.7 a v3.6.25). Si tu panel lleva meses desactualizado, las herramientas de actualización son el menor de tus problemas.
Copia de seguridad antes de actualizar
Ten copias de seguridad listas antes de empezar. La guía de backups de Dokploy muestra cómo enviar backups de volúmenes a Cloudflare R2. Una salvedad: Dokploy Volume Backups solo cubre volúmenes nombrados. Los datos en bind mounts son tu responsabilidad.
Requisitos previos
Para que cualquiera de los métodos siguientes funcione, necesitas:
- Un panel de Dokploy funcionando en una versión v0.30.x actual (ahí es donde vive el toggle pull-latest)
- Un VPS Linux dimensionado para Docker - yo ejecuto Dokploy en un Hetzner Cloud CX22 (unos 4-5 €/mes), y un VPS de Hostinger económico funciona bien para un par de stacks. 2 GB de RAM es el mínimo práctico; 4 GB si ejecutas varias apps
- Acceso SSH a ese VPS (solo necesario para el método alternativo)
- Al menos una app ya desplegada como proyecto de Docker Compose en Dokploy
- Copias de seguridad configuradas para todo lo que tenga estado (bases de datos, archivos subidos)
¿Aún sin Dokploy? Sigue primero la guía de instalación de Dokploy.
Dónde viven los archivos compose
Dokploy guarda los proyectos compose en /etc/dokploy/compose/<app-name>/code. El nombre de la app es tu nombre de proyecto limpio más un sufijo aleatorio de 6 caracteres, por ejemplo myapp-a1b2c3. Artículos antiguos muestran 7 caracteres; el sufijo lleva siendo de 6 desde hace tiempo.
Opción A: Actualizar stacks con el tag latest
Cuando tu archivo compose usa tags mutables como image: nginx:latest, necesitas un paso de pull explícito para obtener imágenes nuevas. Un simple docker compose up -d no vuelve a descargar una imagen que ya tiene en local, así que un redespliegue sin pull seguirá ejecutando alegremente la build del año pasado. Hay tres formas de meter imágenes frescas en un stack con tag latest, y desde v0.30.x la primera es la opción por defecto.
Método 1: Pull latest images on deploy (nativo, recomendado)
Dokploy añadió una opción de pull de primera clase en el PR #5410 (fusionado el 2026-09-09, publicado en la serie v0.30.x). La activas una vez por proyecto compose y cada despliegue descarga la imagen más reciente de cada tag.
Paso 1: Activa el toggle
- Abre tu proyecto compose en la UI de Dokploy
- Ve a la pestaña Advanced
- Busca la tarjeta Run Command
- Activa Pull latest images on deploy
Vale la pena citar el texto de la UI porque contiene la salvedad principal:
Añade
--pull alwaysal comando por defecto para que cada despliegue descargue la imagen más reciente de cada tag. No tiene efecto cuando hay un comando personalizado configurado.
Paso 2: Rebuild (o Deploy)
Vuelve a la pestaña General y haz clic en Rebuild. Ese es el botón que este artículo antes llamaba Reload.
| Botón | Qué hace | Cuándo usarlo |
|---|---|---|
| Deploy | Despliegue completo. Vuelve a descargar el código fuente (git clone o escritura raw) y ejecuta el comando compose | El repositorio git o la fuente raw cambió |
| Rebuild | Llama a compose.redeploy. Omite la descarga del código y vuelve a ejecutar el comando compose |
Solo hay que actualizar imágenes (este es el que quieres) |
Paso 3: Qué se ejecuta
Con el toggle activado, el comando efectivo queda así:
docker compose -p <appName> -f <compose-file> up -d --build --remove-orphans --pull alwaysDocker Compose descarga primero cada imagen (por el --pull always), y luego recrea solo los servicios cuya imagen o configuración cambió. Los servicios que no tocaste siguen en pie.
Verifica que funcionó:
- El Docker dashboard de v0.30 (barra lateral izquierda, Docker) tiene una pestaña Events que muestra eventos de pull y arranque en tiempo real. Ábrela mientras pulsas Rebuild y deberías ver eventos
pullpara cada servicio actualizado - O revisa los Logs del servicio en Dokploy y busca la cadena de la nueva versión al arrancar
- O por SSH:
cd /etc/dokploy/compose/myapp-a1b2c3/code && docker compose images
Si nada cambió, probablemente el tag nunca se movió en upstream, o el toggle está siendo ignorado (siguiente punto).
¿Comando personalizado? El toggle se ignora
Si configuraste un Run Command personalizado para el proyecto, “Pull latest images on deploy” no tiene efecto. El toggle solo modifica el comando por defecto. O eliminas el comando personalizado y usas el predeterminado, o añades --pull always a tu propio comando.
Ten en cuenta también que el comando por defecto incluye --build. Si algún servicio de tu archivo compose tiene una sección build:, cada Rebuild reconstruye esa imagen desde el código. Es comportamiento esperado, no un bug, pero puede sorprenderte en VPS más lentos.
Nota sobre rollback: con tags latest no hay un tag anterior al que volver. Antes de una actualización mayor arriesgada de un servicio crítico, fíjalo por digest (image: nginx@sha256:...) o cámbialo a una versión fijada (Opción B) para tener algo a lo que volver.
Método 2: SSH y docker compose pull (alternativa)
A veces quieres un pull puntual, o usas un comando personalizado y el toggle no te sirve. Entonces hazlo a mano.
Paso 1: Entra por SSH a tu servidor
ssh user@your-vps-ipPaso 2: Localiza el directorio del proyecto compose
cd /etc/dokploy/compose/myapp-a1b2c3/codePaso 3: Pull y recreación
docker compose -p myapp-a1b2c3 pull
docker compose -p myapp-a1b2c3 up -d --remove-orphansO simplemente pulsa Rebuild en la UI de Dokploy después del pull; ejecuta la misma recreación contra las imágenes que ya están en la caché local de Docker.
Haz coincidir el nombre del proyecto con -p
Dokploy genera un COMPOSE_PROJECT_NAME en el archivo .env del proyecto. Pasar -p myapp-a1b2c3 mantiene tus comandos manuales apuntando al mismo proyecto que gestiona Dokploy. Ejecutar docker compose pull a secas desde dentro del directorio code también funciona, porque compose deriva el nombre del proyecto de la carpeta y del .env.
¿Por qué hace falta el pull explícito? docker compose up -d solo descarga las imágenes que faltan en local. Todo lo que ya está en caché se queda en caché. Esa es toda la razón de existir del Método 1: --pull always fuerza el pull que up -d se salta.
Verifica que funcionó:
docker compose -p myapp-a1b2c3 images
docker compose -p myapp-a1b2c3 psLos IDs de imagen deberían diferir de los de antes del pull, y ps debería mostrar los contenedores healthy. Los Logs del servicio en la UI de Dokploy deberían mostrar la cadena de la nueva versión al arrancar.
¿Imágenes de registro privado? Los pulls manuales pueden dar 401
Dokploy inyecta las credenciales del registro en el momento del despliegue mediante una configuración temporal de Docker, así que una shell SSH pelada puede no tener el mismo contexto de autenticación. Si docker compose pull falla con 401 unauthorized en una imagen privada, activa el toggle del Método 1 y deja que Dokploy haga el pull, o ejecuta docker login primero en el host. Este comportamiento se infiere del código fuente de despliegue de Dokploy y no se ha probado en vivo, así que verifícalo en tu configuración antes de confiar en él.
Método 3: Automatizar las actualizaciones de Docker Compose
Las actualizaciones manuales no escalan más allá de un puñado de stacks. Antes de elegir un auto-actualizador, una comprobación de realidad:
Watchtower está archivado
containrrr/watchtower está archivado y el README dice “This project is no longer maintained” (24,6k estrellas, último push en diciembre de 2025). No inicies despliegues nuevos con él. Si solo necesitas notificaciones de actualizaciones, Diun está activo y hace exactamente eso. Para auto-actualizaciones de verdad, usa una de las opciones siguientes.
Hay tres vías de automatización sensatas dentro de Dokploy o a su lado, y la correcta depende de dónde quieras que se ejecute el disparador. Si quieres una gestión de contenedores más amplia que las actualizaciones, compara Arcane y Dockhand.
Dokploy Schedules (Server Job)
Dokploy tiene un sistema cron integrado: Schedules. Crea un Server Job (ejecuta bash directamente en el host) con una programación como 0 4 * * *:
#!/bin/bash
cd /etc/dokploy/compose/myapp-a1b2c3/code
docker compose pull && docker compose up -d --remove-orphans
docker image prune -afEso actualiza el stack cada noche a las 04:00 y recupera las imágenes antiguas en la misma ejecución. Cero herramientas extra, y el trabajo vive en el mismo panel que todo lo demás.
Server Job vs Compose Job
Schedules ofrece varios tipos de trabajos. Los Server Jobs se ejecutan en el host y pueden hacer pulls y actualizaciones. Los Compose Jobs se ejecutan dentro de un contenedor de servicio vía docker exec - esa es la herramienta equivocada para pulls de imágenes. Elige Server Job para cualquier cosa que toque docker compose o docker image.
Dokploy CLI / API
Dokploy v0.29.0 (2026-04-17) lanzó una CLI autogenerada a partir de la especificación OpenAPI, con 449 comandos (paquete npm @dokploy/cli). Es la forma limpia de scriptar actualizaciones sin llaves SSH en el VPS.
npm install -g @dokploy/cli
# auth once, or use DOKPLOY_URL / DOKPLOY_API_KEY env vars
dokploy auth -u https://panel.example.com -t YOUR_API_KEY
# trigger an update from anywhere
dokploy compose redeploy --composeId abc123La API de compose también expone compose.deploy, compose.stop y compose.start, así que un cron job en tu portátil o en CI puede manejar todo el ciclo de vida. Combina dokploy compose redeploy con el toggle pull-latest del Método 1; si no, el redeploy no descargará imágenes nuevas.
Las API keys viven en la UI de Dokploy (Settings, API). Trátalas como credenciales de root: acceso total al panel, así que guárdalas en un gestor de secretos o archivo env y rótalas si se filtran. Si quieres ir más lejos y que un asistente de IA despliegue apps Docker por ti, la CLI es la superficie sobre la que scriptar.
Tugtainer (multi-host, notificaciones, Swarm)
Tugtainer es la alternativa autoalojada a Watchtower que recomiendo: una UI web que vigila contenedores y ejecuta las actualizaciones. A fecha de v1.44.1 (2026-10-05) va mucho más allá de simples bumps de imagen.
Lo que Tugtainer te da:
- Interfaz web - Gestiona actualizaciones desde un navegador en lugar de sesiones SSH
- Comprobaciones programadas - Consulta los registros en busca de imágenes nuevas con tu cadencia
- Ordenación inteligente - Actualiza los contenedores en orden de dependencias
- Notificaciones - Discord, Telegram, Slack o email cuando las actualizaciones llegan o fallan
- Multi-servidor - Una interfaz para varios hosts
- Monitorización de healthchecks - Reinicios automáticos y alertas cuando un contenedor pasa a unhealthy
- Poda de imágenes - Limpieza automática o manual de imágenes antiguas
- Soporte de Docker Swarm - Detecta managers automáticamente y hace rolling updates (según el README; pruébalo antes de confiar en un swarm real)
- Control por contenedor - Modo solo-comprobación o auto-actualización completa, además de hooks y etiquetas personalizadas
Configúralo una vez y se encarga del resto. Mejor que entrar por SSH cada vez que sale una actualización.
Comparado con el toggle nativo: el toggle es gratis y por stack, y solo hace pull en el momento del despliegue. Tugtainer es para toda la flota, se ejecuta según un horario y te cuenta lo que hizo. Usa el toggle para un puñado de stacks; usa Tugtainer cuando quieras un panel de control para actualizaciones en varios hosts.
Guía de configuración de TugtainerOpción B: Actualizar stacks con versiones fijadas
Si fijas versiones exactas (image: postgres:16-alpine en lugar de latest), el flujo es diferente. No hay nada más nuevo que descargar hasta que cambies el tag tú mismo. Esa es la idea.
Paso 1: Edita el tag de la imagen en Dokploy
- Abre el proyecto en la UI de Dokploy
- Haz clic en la pestaña General
- Busca la sección Raw con el archivo compose
- Cambia el tag de la versión
Por ejemplo, cambia:
image: flowiseai/flowise:1.0.0a:
image: flowiseai/flowise:1.1.0Paso 2: Guarda, luego Paso 3: Rebuild (o Deploy). Dokploy descarga el nuevo tag y recrea el contenedor.
Verifica que funcionó: los Logs del servicio deberían mostrar la nueva versión al arrancar, y docker compose images por SSH debería mostrar el ID de imagen del nuevo tag. El editor Raw debería mostrar la versión que acabas de guardar.
Rollback: revierte el tag en el editor Raw, guarda y haz Rebuild. Mantén el tag anterior a una línea de distancia - un commit de git, o simplemente una línea de comentario encima de la imagen. Para un control más estricto, fija por digest en lugar de por tag:
image: nginx@sha256:3f1b2c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2bUn digest nunca se mueve bajo tus pies, así que “volver atrás” significa apuntar al digest anterior que guardaste.
¿Por qué fijar versiones?
Las versiones fijadas deciden exactamente qué se ejecuta en producción. Tú eliges cuándo actualizar y sabes qué cambió entre despliegues. Los tags latest pueden sorprenderte con breaking changes un martes cualquiera. Para cualquier cosa con datos, prefiero tags fijados por defecto y reservo latest para servicios desechables. Fijar por digest va un paso más allá: el tag no puede mutar en upstream a tus espaldas.
El toggle pull-latest es irrelevante para tags fijados inmutables (no hay nada más nuevo que descargar), pero inofensivo si lo dejas activado. La parte --build del comando por defecto sigue aplicando: los archivos compose con secciones build: se reconstruyen en cada Rebuild de todos modos.
Las rutas bind absolutas se limpian en el despliegue
Los volúmenes nombrados y los binds relativos como ../files sobreviven a las recreaciones de contenedores. Las rutas bind absolutas del host son otra historia: según la documentación oficial de Dokploy, se limpian durante los despliegues. Si montas algo como /var/lib/mydata, verifica que la ruta sigue conteniendo tus datos después de un Rebuild antes de confiar en el flujo. Esta es exactamente la razón por la que los backups van primero.
Después de la actualización: verifica y limpia
Una actualización no termina cuando el botón Rebuild acaba. Quedan dos cosas: confirmar que la nueva versión está sirviendo, y deshacerse de las imágenes antiguas.
Checklist de verificación:
- El ID de imagen cambió (
docker compose imageso el Docker dashboard) - El stream de Events del Docker dashboard muestra el pull de cada servicio actualizado
- Los contenedores están healthy (
docker compose ps, o el estado del servicio en Dokploy) - La propia app sirve la nueva versión - llama a un endpoint de versión o a la UI y compruébalo
Luego limpia. Cada actualización deja imágenes antiguas colgando, y en un VPS pequeño eso llena el disco en cuestión de meses. Un disco de 40 GB con actualizaciones semanales y sin poda es una bomba de relojería, no un plan.
El disco se llena en silencio en VPS pequeños
Docker se comerá encantado un disco con imágenes huérfanas y caché de build. No recibirás aviso hasta que las escrituras empiecen a fallar. Poda según un horario o activa la limpieza integrada.
Ajuste Docker Cleanup
La opción de cero esfuerzo. En Settings / Server, activa Docker Cleanup. Dokploy elimina entonces las imágenes sin usar automáticamente según su propio horario. Ideal cuando quieres que se encargue y no pensar en podar.
Docker dashboard
v0.30.0 añadió un Docker dashboard en /dashboard/docker con tres pestañas: Images (tamaño y antigüedad por imagen, detecta lo que se puede podar), Disk Usage (espacio recuperable desglosado por imágenes, volúmenes y caché de build) y Events (stream en vivo de pull/start/stop - útil para verificar que la actualización llegó). Usa esto cuando quieras ver qué está comiendo el disco antes de borrar nada.
Poda manual
Para cron o un Server Job de Dokploy Schedules:
docker image prune -afEso elimina todas las imágenes colgantes y sin usar. Si necesitas ir más hondo (volúmenes, caché de build), mira cómo recuperar espacio en disco de imágenes Docker antiguas antes de ejecutar nada irreversible. docker image prune -af no toca los volúmenes, pero docker system prune -a --volumes sí, absolutamente.
Las actualizaciones también cambian lo que tu servidor ejecuta, que es exactamente cuando quieres monitorización. Monitoriza tu servidor Dokploy con Beszel y Uptime Kuma para que una mala actualización te despierte a ti en lugar de a tus usuarios.
Buenas prácticas para actualizar stacks
Prueba antes de producción
Nunca mandes actualizaciones directamente a producción sin comprobarlas primero:
- Usa un entorno de staging - Replica tu configuración de producción en algún lugar seguro
- Lee los changelogs - Sabe a qué te enfrentas, sobre todo en versiones mayores
- Verifica la compatibilidad - Asegúrate de que tu configuración y variables de entorno siguen funcionando con la nueva imagen
Cuándo actualizar
- Parches de seguridad - Aplícalos en cuanto los hayas probado. No te sientes sobre CVEs
- Actualizaciones de funciones - Prográmalas en tu ventana de mantenimiento
- Versiones mayores - Planifícalas con cuidado. Lee las notas de migración, haz un backup y ten listo el tag de rollback antes de empezar
Cómo revertir
Cuando una actualización rompe algo:
- Revierte el cambio - Para versiones fijadas, vuelve a poner el tag o digest anterior en el editor Raw. Para stacks
latest, vuelve a descargar la imagen antigua por digest si guardaste uno, o restaura desde el backup - Haz clic en Rebuild en Dokploy para recrear los contenedores con la imagen antigua
- Revisa los Logs para ver qué falló antes de intentarlo de nuevo
Una salvedad: la función Rollback de un clic de Dokploy es solo para aplicaciones. No existe un endpoint compose.rollback. Los rollbacks de compose son manuales, otra razón por la que los tags fijados (o digests) ganan a latest para cualquier cosa que te importe. Si la actualización corrompió datos y no solo el contenedor, restaura desde los backups de Dokploy con Cloudflare R2 que hiciste antes.
Mantén Dokploy actualizado
Tus herramientas de actualización solo son tan seguras como el panel que las ejecuta. v0.29.13 y v0.29.14 portaron docenas de correcciones de seguridad (inyección de comandos, IDOR), y v0.30.0 corrigió una inyección en serviceName de compose y movió Traefik de v3.6.7 a v3.6.25. Actualiza el panel con la misma cadencia que tus stacks.
Isolated Deployments está obsoleto
v0.30.0 marcó como obsoleto el ajuste Isolated Deployments (aún presente en los ajustes avanzados de compose). El reemplazo es la asociación de redes por servicio: los servicios se unen a dokploy-network por defecto y tú asocias o desasocias redes por servicio, aplicado en el siguiente despliegue. Si activaste el aislamiento desde las plantillas open source, sigue funcionando hoy, pero planifica la migración.
Preguntas frecuentes
¿Rebuild descarga imágenes nuevas sin el toggle?
No. Rebuild ejecuta up -d --build --remove-orphans contra las imágenes que ya están en la caché local de Docker, y up -d no vuelve a descargar tags que ya tiene. Sin el toggle “Pull latest images on deploy” (o un docker compose pull manual primero), seguirás ejecutando la imagen antigua. Esa es toda la razón de existir del toggle.
¿Cuál es la diferencia entre Deploy y Rebuild en Dokploy?
Deploy es un despliegue completo: vuelve a descargar el código fuente (git clone o escritura de archivo raw) y luego ejecuta el comando compose. Rebuild llama a compose.redeploy y omite la descarga del código, re-ejecutando solo el comando compose. Para actualizaciones solo de imágenes, Rebuild es más rápido y suficiente. Para cambios de código, usa Deploy.
¿Puedo auto-actualizar servicios de Docker Compose en Dokploy?
Sí. Tres opciones: Dokploy Schedules con un Server Job que ejecuta un script de pull-and-up en un cron; la CLI de Dokploy (dokploy compose redeploy) desde un cron en tu portátil o CI; o Tugtainer para actualizaciones de toda la flota con notificaciones y UI web. El toggle pull-latest por sí solo solo descarga en el momento del despliegue - no es un planificador.
¿Watchtower sigue mantenido en 2026?
No. containrrr/watchtower está archivado y su README indica que el proyecto ya no se mantiene. No lo despliegues en configuraciones nuevas. Tugtainer es el reemplazo autoalojado más cercano para auto-actualizaciones; Diun es la opción activa si solo necesitas notificaciones cuando aparecen imágenes nuevas.
¿Cómo revierto un stack de Docker Compose en Dokploy?
Revierte el tag o digest de la imagen en el editor Raw y pulsa Rebuild. No hay rollback de un clic para proyectos compose - esa función es solo para aplicaciones. Guarda el tag anterior en git o en un comentario, y haz backups de volúmenes antes de actualizaciones arriesgadas por si los datos se ven afectados, no solo el contenedor.
Conclusión
Actualizar stacks de Docker Compose en Dokploy en 2026 se reduce a una decisión por stack:
- Tags
latest: activa “Pull latest images on deploy” una vez y haz Rebuild cuando quieras imágenes frescas. Ese es todo el flujo - SSH +
docker compose pull: guárdalo en la recámara para casos puntuales y comandos personalizados - Automatización: Dokploy Schedules para un solo host sin herramientas extra, la CLI de Dokploy para cron desde un portátil o CI, Tugtainer cuando quieras notificaciones y control multi-host. Watchtower, nunca
- Versiones fijadas: cuando la estabilidad importa, edita el tag (o digest) tú mismo y vuelve atrás revirtiendo una línea
Dokploy lanzó mucho en 2026: el toggle de pull, la CLI y el Docker dashboard llegaron todos en la línea v0.29/v0.30. Este artículo está actualizado a 2026-10-24 contra Dokploy v0.30.10. Mantén los backups por delante de cada actualización, poda las imágenes que ya no uses y vigila el servidor después de un despliegue. Si aún estás eligiendo panel, mira cómo se compara Dokploy en nuestra guía de los mejores paneles de servidor autoalojados, o compara Coolify, Dokploy y Kamal si la lista corta sigue abierta.
