Dokploy: un despliegue ligero sobre Docker Swarm

Actualizado: 2026-05-03

Dokploy lleva poco más de un año en desarrollo serio y este verano de 2025 ha alcanzado una versión 0.16 que empieza a parecer madura. La propuesta es clara: dar una experiencia tipo Vercel o Render, pero sobre tu propia infraestructura y sin depender de un Kubernetes completo. La base es Docker Swarm, la interfaz es una aplicación web que orquesta stacks, y la curva de aprendizaje se mide en horas, no en semanas.

Puntos clave

• Dokploy es un panel web que instala sobre Docker Swarm en Debian/Ubuntu y gestiona el ciclo de vida completo de aplicaciones: Git, TLS, backups y secretos.
• Se diferencia de Coolify en que apuesta por hacer Swarm bien y poco más — esa simplicidad es fortaleza y limitación a la vez.
• La integración con Nixpacks detecta el lenguaje y el entorno sin Dockerfile, lo que reduce la fricción de empaquetado en proyectos Node.js, Python y Go.
• El 5 % problemático: si ya tienes Traefik personalizado (CrowdSec, forward-auth con Authentik), el conflicto de configuración no está bien documentado.
• No está pensado para entornos multi-inquilino con aislamiento estricto: los permisos por usuario operan sobre la capa de aplicación del panel, no sobre las primitivas de Swarm.

Qué es Dokploy en una frase

Dokploy es un panel de control web que se instala en un nodo Debian o Ubuntu con Docker Swarm y permite desplegar aplicaciones desde repos Git, imágenes de contenedor o archivos compose sin tocar la línea de comandos. Incluye:

• Traefik integrado para terminación TLS automática con Let’s Encrypt
• Gestión de dominios
• Copias de seguridad de bases de datos
• Plantillas para servicios comunes como WordPress o Ghost
• Capa de colaboración básica con equipos y permisos

La instalación es un script de una línea que levanta la propia aplicación Dokploy como una pila en el mismo Swarm que gestiona. Esto tiene una propiedad interesante: Dokploy se despliega a sí mismo con sus propias primitivas, de forma que las actualizaciones del panel pasan por el mismo camino que las de cualquier aplicación que gestione.

Dónde encaja entre los competidores

El mercado de PaaS autoalojado está bastante poblado:

• Coolify: el competidor más directo, con un modelo conceptualmente similar pero con diferencias clave. Coolify apuesta por soportar todo — Docker, Swarm, Kubernetes, servicios externos, mil plantillas. Dokploy apuesta por hacer Swarm bien y poco más.
• CapRover: lleva más años pero tiene comunidad más pequeña y menos soporte para Swarm multinodo.
• Portainer: potente pero enfocado a operadores, no a desarrolladores.
• Plataformas Kubernetes (Kubero, Ketches): requieren más inversión inicial.

La diferencia de Dokploy con Coolify es filosófica. Esta simplicidad es a la vez fortaleza y limitación. Si tu caso encaja en Swarm, la experiencia es más pulida que en Coolify. Si necesitas algo fuera de ese modelo, te quedas corto.

Para equipos pequeños que no quieren operar un cluster Kubernetes pero necesitan más que un servidor con docker compose, Dokploy ocupa un hueco real. Tres nodos Swarm, un panel web, TLS automático, y aplicaciones que se redespiegan solas cuando hay un push a main — eso es el 80 % del valor de un Vercel autoalojado a una fracción de la complejidad operativa.

La integración con Traefik

Dokploy incluye Traefik como proxy inverso y lo configura automáticamente para cada aplicación que despliegues. Cuando creas una aplicación y le asignas un dominio, Dokploy genera las etiquetas Traefik correspondientes, solicita el certificado Let’s Encrypt y deja la aplicación accesible por HTTPS sin más intervención. Esto funciona bien en el 95 % de los casos.

El 5 % restante es interesante. Si ya tienes un Traefik corriendo para otros servicios fuera de Dokploy, hay un conflicto de configuración que no está bien documentado. La solución oficial es dejar que Dokploy gestione Traefik también, lo que obliga a migrar la configuración existente. En mi caso, con un Traefik muy personalizado para CrowdSec y forward-auth con Authentik, esto no era aceptable. Terminé configurando Dokploy en modo sin Traefik y enchufando manualmente las aplicaciones al Traefik existente mediante redes compartidas — funciona pero pierde parte de la magia de la plataforma.

La experiencia de desarrollador

La parte que más me ha gustado es la integración con Git. Conectas un repo de GitHub, Gitea o GitLab, eliges la rama, defines si es una aplicación Docker, Nixpacks o Buildpacks, y cada push al repo dispara un redespliegue. El historial de despliegues queda visible, con logs de construcción accesibles en el navegador y la posibilidad de revertir a una versión anterior con un clic.

El soporte de Nixpacks es el que más me sorprende positivamente. Nixpacks detecta el lenguaje y el entorno de la aplicación sin necesidad de escribir un Dockerfile. Para una aplicación Node.js, Python o Go, esto significa que no tienes que pensar en empaquetado. Empujas código, Nixpacks construye una imagen sensata y Dokploy la despliega. La imagen resultante no es la más eficiente posible, pero para iterar en desarrollo es muy práctico.

La gestión de secretos tiene margen de mejora. Los valores se almacenan cifrados en la base de datos del panel, pero no hay integración con Vault, Infisical u otros gestores externos. Para un homelab esto es suficiente. Para un entorno corporativo donde los secretos deben rotarse, auditarse o segregarse por entorno, hay que añadir una capa externa.

Limitaciones reales que encontré

Primera limitación: Dokploy asume que tienes control total del cluster Swarm. No está pensado para entornos multi-inquilino donde diferentes equipos comparten el mismo cluster con aislamiento estricto. Los permisos por usuario existen pero operan sobre la capa de aplicación del panel, no sobre las primitivas de Swarm. Un usuario con acceso al panel tiene visibilidad de todos los stacks del cluster.

Segunda limitación: la escala. Swarm funciona bien hasta unas decenas de nodos, pero más allá empieza a mostrar sus costuras. Dokploy hereda esas costuras. No es una plataforma para cargas masivas con cientos de microservicios. Para esos casos Kubernetes 1.34 sigue siendo la respuesta correcta, con toda su complejidad asociada.

Tercera limitación: el estado de la documentación. Cubre bien los casos felices y se queda corta en los casos de borde. Cuando surgen problemas de red, DNS interno, o conflictos con servicios externos, hay que ir a issues de GitHub o al Discord de la comunidad. Esto es normal en un proyecto joven, pero hay que saberlo antes de adoptarlo para algo crítico.

Mi lectura

Dokploy me parece una herramienta bien enfocada para un perfil concreto: un equipo pequeño que quiere autoalojarse por razones de coste, privacidad o control, que ya conoce Docker pero no quiere aprender Kubernetes, y cuyas cargas encajan en Docker Swarm. Para ese perfil la ganancia respecto a scripts ad hoc sobre compose es clara: todo el ciclo de vida de la aplicación está en un sitio, el TLS se gestiona solo, y el equipo puede autoservirse sin pedir acceso SSH para cada cambio.

Para equipos que ya operan Kubernetes, Dokploy no aporta suficiente para justificar la migración. Swarm sigue siendo menos potente que K8s en gestión de recursos, políticas de red, observabilidad y ecosistema de operadores.

El punto donde me quedo con Dokploy es en proyectos nuevos donde la incertidumbre de carga es alta y el equipo es de menos de cinco personas. En ese escenario, arrancar con Swarm y Dokploy da un tiempo de desarrollo mucho más corto que arrancar con Kubernetes, y la migración a K8s llegado el caso no es trivial pero tampoco imposible. El coste de oportunidad de empezar pesado por si acaso casi nunca merece la pena.