Si ya has dejado atrás el PaaS gestionado, tu VPS está aprovisionado, la clave SSH está añadida y el cursor de tu terminal parpadea en la línea de instalación. La única pregunta que queda es: ¿ejecutas curl ... | bash para Coolify, o para Dokploy?
Ambas herramientas se instalan con un solo comando. Ambas te ofrecen despliegues por Git-push, SSL automático, una interfaz web y un proxy inverso sobre Docker. Las diferencias interesantes son las que aparecen en producción: cómo gestiona cada una un docker-compose.yml, qué ocurre durante un despliegue y cómo respondió cada proyecto a las noticias que reconfiguraron esta comparación en 2026. Dos noticias concentran aquí la mayor parte del peso: las Divulgaciones de CVE de Coolify de enero de 2026 y la clave Reestructuración de la licencia de Dokploy del mismo mes.
Esta publicación asigna cada herramienta a un caso de uso concreto en lugar de coronar a un ganador. Al final, esperamos que sepas cuál encaja con tu flujo de trabajo.
Resumen rápido
- Coolify es más antigua y con el ecosistema más grande (~55k estrellas en GitHub, más de 300 plantillas de servicios de un clic), más pesada en reposo, con Apache 2.0 en su totalidad y sin nivel de pago en la versión autoalojada.
- Dokploy es más joven (~34k estrellas), más ligera en reposo, con un núcleo Apache 2.0 más una Source Available License independiente que regula futuras funciones de pago (SSO, RBAC, registros de auditoría, marca blanca).
- Coolify no puede realizar hoy despliegues con cero tiempo de inactividad mediante Docker Compose; solo mediante Dockerfile, Nixpacks o despliegues de imagen única. Dokploy incorpora Docker Swarm como un modo de primera clase; el Swarm de Coolify está etiquetado como experimental.
- Los CVE de Coolify de enero de 2026 están parcheados en v4.0.0 (April 27, 2026). Actualiza Coolify y no expongas el panel públicamente.
Cuando ninguna de las dos herramientas es la respuesta correcta
Tanto Coolify como Dokploy tienen la forma equivocada para algunas configuraciones. Tres alternativas que conviene conocer, brevemente:
- Kamal (de 37signals): para equipos con una o dos aplicaciones que quieren cero interfaz; solo
kamal deploydesde tu portátil. Mucho más simple que Coolify o Dokploy y la opción acertada cuando no quieres un panel. - Dokku: el clásico modelo de Git-push y servidor único. Más antiguo, de menor alcance, muy estable. El original del «Heroku en un único VPS».
- GitHub Actions + Docker Compose en un VPS limpio: la pila más pequeña posible. Sin interfaz de orquestación, pero tampoco con sobrecarga de orquestación. Bueno para una sola aplicación cuando el flujo de despliegue se
docker compose pull && docker compose up -dactiva desde CI.
Si tu forma es una aplicación en un servidor, tanto Coolify como Dokploy probablemente sean excesivos; prueba primero una de las opciones anteriores. Si tienes varias aplicaciones, varias bases de datos o un equipo con miembros no técnicos que necesitan una interfaz para operar las cosas, entonces la elección entre Coolify y Dokploy es la adecuada. Para un panorama más amplio de opciones en esta categoría, consulta nuestro repaso de plataformas cloud autoalojadas con interfaz web.
Coolify y Dokploy de un vistazo
Coolify v4.0.0 estable se lanzó el April 27, 2026, tras un largo ciclo de beta. Dokploy está en v0.29.4 a fecha de May 11, 2026. Ambos son proyectos de PaaS autoalojados de código abierto en el espacio de alternativas a Heroku/Render/Vercel, ambos envuelven Docker con una interfaz, un proxy inverso HTTPS por defecto (Traefik) y despliegues basados en Git.
| Característica | Coolify | Dokploy |
|---|---|---|
| Última versión estable | v4.0.0 (April 27, 2026) | v0.29.4 (May 11, 2026) |
| Licencia | Apache 2.0 | Núcleo Apache 2.0 + Source Available para funciones de pago |
| Pila tecnológica | PHP / Laravel | TypeScript / Node.js |
| Estrellas en GitHub | ~55,000 | ~34,000 |
| RAM mínima (oficial) | 2 GB | 2 GB |
| CPU mínima (oficial) | 2 núcleos | no especificado |
| RAM en reposo (reportada por la comunidad) | 500 MB – 1.2 GB | 300 – 400 MB |
| Cero tiempo de inactividad con Docker Compose | No soportado (solo Dockerfile/Nixpacks) | Gestión estándar de Compose |
| Clustering multiservidor | Docker Swarm (experimental) | Docker Swarm (nativo) |
| Soporte ARM64 | Sí (incl. Raspberry Pi OS) | No anunciado en la documentación |
| Sistemas de build | Nixpacks, Dockerfile, imagen Docker | Nixpacks, Dockerfile, imagen Docker, Heroku Buildpacks, Paketo, Railpack |
| Proxy inverso | Traefik | Traefik |
| Alcance de la monitorización autoalojada | Métricas integradas + visor de logs | Métricas básicas de recursos + análisis de errores de logs/build con IA (v0.29.0+) |
Nuestra opinión: elige Dokploy si quieres menos sobrecarga en reposo, soporte multiservidor nativo y gestión estándar de Docker Compose sin ajustes específicos de la plataforma. Elige Coolify si quieres la mayor biblioteca de aplicaciones de un clic, soporte ARM64/Raspberry Pi, o Apache 2.0 puro sin ningún nivel de pago futuro esperando entre bastidores.
Huella de recursos y dimensionamiento del VPS
Un PaaS autoalojado puede ahorrarte el coste de Heroku. Si la capa de orquestación se come 1,5 GB de tu VPS de 2 GB en reposo, no te queda nada sobre lo que desplegar. Así que la primera pregunta práctica en un servidor pequeño es: ¿cuánto te cuesta cada herramienta antes de haber desplegado una sola aplicación?
El uso de RAM en reposo de Coolify depende de la monitorización que tengas activada, con una huella base de CPU del 5–7% que se dispara cuando se ejecuta el scrapeo de métricas. La propia documentación de Coolify usa una carga de trabajo de producción representativa de 8 GB de RAM, 4 núcleos y 150 GB de almacenamiento ejecutando 3 aplicaciones Node.js, 4 sitios estáticos y unas cuantas bases de datos. Es una referencia de dimensionamiento razonable si tu pila se parece.
Dokploy, en cambio, funciona mucho más ligero, muy por debajo del 2% de CPU cuando no se está desplegando nada.
A Artículo de producción de LogRocket ejecutando ambas herramientas en paralelo llegó a la misma conclusión direccional: un docker stop && docker start en una aplicación de Dokploy no dispara una reconstrucción completa, mientras que la misma operación en Coolify sí. Eso por sí solo desplaza el coste en estado estacionario a favor de Dokploy, especialmente en planes de VPS más pequeños donde las tormentas de reconstrucción se comen tu presupuesto de CPU.
Para el dimensionamiento, esta es la configuración de VPS que recomendaría:
- Coolify, carga ligera: 2 vCPU / 4 GB RAM / 120 GB NVMe is the practical starting point for Coolify plus a couple of small apps.
- Coolify, carga de referencia de producción: 4 vCPU / 8 GB RAM / 160 GB NVMe to match Coolify's own documented 3 Node.js + 4 static sites + databases example.
- Dokploy, carga ligera: 1 vCPU / 2 GB RAM / 60 GB NVMe is comfortable for a single small app.
- Dokploy, margen para producción: 2 vCPU / 4 GB RAM / 120 GB NVMe gives you room for a small production stack.
Consejo práctico: la RAM en reposo de Coolify escala con la configuración de monitorización. Si vas justo de memoria, reduce el intervalo de scrapeo de métricas (o desactiva por completo la monitorización integrada si ya ejecutas Prometheus/Grafana en otro sitio) antes de aprovisionar un servidor más grande.
La realidad del despliegue: Docker Compose, Dockerfile y cero tiempo de inactividad
La mayoría de los equipos llegan a una de estas herramientas con un docker-compose.yml existente y una expectativa: pegar el archivo, hacer clic en desplegar y ver cómo se levanta la aplicación. La forma en que cada plataforma gestiona el Compose estándar, y lo que les ocurre a las peticiones en curso durante el siguiente despliegue, es donde aparece la distinción práctica.
Coolify admite Docker Compose, Dockerfile, Nixpacks (autodetección a partir de los archivos del proyecto) y despliegues directos de imagen Docker. Hay, sin embargo, una pega que conviene dejar clara: los despliegues con cero tiempo de inactividad (actualizaciones progresivas, blue/green) funcionan en Coolify solo mediante Dockerfile, Nixpacks o despliegues de imagen única. No funcionan mediante Docker Compose. Un mantenedor de Coolify confirmó en una discusión en GitHub que «en los despliegues basados en compose, todos los contenedores se detienen antes de iniciar los nuevos; actualmente no hay actualización progresiva para los despliegues basados en compose». El soporte progresivo para Compose está en la hoja de ruta de v5; v4 no lo tendrá. La solución alternativa que sugiere el mantenedor es dividir una pila de Compose en servicios individuales de Coolify, lo cual es una migración nada trivial si tu archivo Compose expresa relaciones reales entre servicios.
La consecuencia para el usuario aparece en un hilo de Hacker News sobre Coolify, donde un operador lo expresó sin rodeos: «cualquier petición pendiente cuando actualizas una aplicación simplemente se mata». Eso es cierto hoy para los despliegues de Compose.
La capa de Compose de Coolify también añade lo que el proyecto llama «variables mágicas». Eso significa la inyección automática de imágenes auxiliares, reescrituras de red y sobrescrituras de entorno. La intención es ser más eficiente; el efecto secundario es que un docker-compose.yml que se ejecuta limpiamente en tu portátil a veces necesita ajustes para ejecutarse limpiamente en Coolify. El mismo hilo de Hacker News saca a relucir un caso representativo: «Añadí 8 variables dentro de docker-compose, solo se reconocen 7». Si tu pila de Compose es pequeña y estándar, puede que no te topes con esto. Si es grande o inusual, sí.
La postura de Dokploy es diferente. El artículo práctico de LogRocket descubrió que Dokploy «puede desplegar un docker-compose.yml existente con pocas o ninguna modificación» y se mantiene cerca del modelo de enrutamiento nativo de Docker basado en etiquetas. El mismo artículo señala que detener/iniciar un contenedor en Dokploy no dispara una reconstrucción completa, mientras que la misma acción en Coolify sí. Esto es una señal direccional sobre el comportamiento en tiempo de ejecución más que una «garantía de cero tiempo de inactividad» formal de la documentación de Dokploy, pero coincide con lo que reportan quienes autoalojan en instancias de VPS más pequeñas.
Dokploy también admite Heroku Buildpacks, Paketo Buildpacks y Railpack, además de Nixpacks y Dockerfile. Para los equipos que llegan desde Heroku con heroku.yml o flujos de trabajo basados en buildpacks, ese es el camino de menor resistencia.
Conclusión clave de la sección: si tus servicios existentes son una pila real de Docker Compose, Coolify te obligará a reestructurar tu estrategia de despliegue o a aceptar un breve tiempo de inactividad en cada push. Dokploy no.
Seguridad: las divulgaciones de CVE de Coolify de enero de 2026
Leo la historia general así: Coolify es seguro de ejecutar hoy si lo mantienes actualizado y no expones el panel a la internet pública. La divulgación no descalifica al proyecto. Se siguió la divulgación responsable y los parches salieron. Lo que sí revela es que la superficie de ataque disponible para un usuario autenticado con pocos privilegios era más amplia de lo que debería. Es una lección de diseño para el proyecto y una lección operativa para el operador: ajusta ya el modelo de exposición.
Consejo práctico: incluso después de parchear, trata tu panel de Coolify como SSH. Vincúlalo a una red privada, ponlo detrás de una VPN o ponle delante un Tailscale. No expongas el puerto 8000 a la internet pública solo porque el script de instalación lo ponga fácil.
Dokploy tampoco está exento de este tipo de problema. Las notas de la versión v0.29.3 reconocen una vulnerabilidad de seguridad identificada en Dokploy e incluyen un script de parche de seguridad que se espera que ejecutes junto con la actualización. Superficie más pequeña, historia del proyecto más corta, pero se aplica la misma disciplina operativa: actualiza el día que salgan los parches y no dejes el panel en la internet pública.
Conclusión clave de la sección: la historia de los CVE es una bandera amarilla para la práctica operativa de Coolify, no una bandera roja contra el proyecto, pero eleva el listón en cuanto a disciplina de actualización y a cómo expones el panel.
Licencias: qué es gratis y qué no
La licencia de Dokploy se reestructuró el January 21, 2026. Esto es lo que cambió y lo que significa para quienes autoalojan.
Dokploy es ahora Apache 2.0 estándar para el núcleo, reemplazando la anterior Apache 2.0 adaptada no estándar que confundía a los usuarios sobre qué era código abierto y qué no. Una Dokploy Source Available License independiente rige ahora el código en proprietary/ los directorios: código fuente visible, de pago para uso en producción. Las funciones que Dokploy dice que vivirán tras esa licencia:
- Inicio de sesión único (SSO/SAML) y controles de acceso avanzados
- Marca personalizada y marca blanca
- Alta disponibilidad, autoescalado y recuperación ante desastres
- Monitorización avanzada, integraciones y funciones de cumplimiento normativo
El proyecto se ha comprometido explícitamente a no mover nunca una función de código abierto existente al nivel de pago; la futura funcionalidad de pago está dirigida a las organizaciones que necesitan ese pegamento empresarial. Hoy 2FA ya está tras el nivel Startup en la página de precios de Dokploy.
La situación de Coolify es sencilla. El proyecto es Apache 2.0 en GitHub; todas las funciones de la versión autoalojada son gratuitas. Existe una oferta de Coolify Cloud para equipos que quieren que el mantenedor lo aloje, pero la versión autoalojada es un producto completo sin restricciones de funciones ni ruta de actualización hacia un nivel de pago que hoy no tienes.
Mi lectura: para desarrolladores en solitario y equipos pequeños que autoalojan en su propio VPS, Dokploy es funcionalmente gratuito y seguirá siéndolo. Para una organización que con el tiempo necesite SSO, RBAC granular, registros de auditoría o marca blanca, Dokploy acabará empujándote hacia un nivel de pago. Coolify no, porque Coolify no tiene ese nivel en la hoja de ruta.
Una aclaración entre fuentes que merece la pena hacer: la build autoalojada de Dokploy sí incluye métricas básicas de recursos (CPU, memoria, almacenamiento, red), y v0.29.0 añadió análisis de errores de logs y build con IA. El sistema de monitorización de Dokploy es solo en la nube para las funciones de monitorización más avanzadas. La monitorización, no obstante, sigue ejecutándose localmente en una instalación autoalojada para las métricas básicas de recursos previas a los contenedores.
Multiservidor y clustering: realidad frente a marketing
Tarde o temprano un solo VPS no basta, y ambos proyectos promocionan de forma destacada el soporte multiservidor en sus páginas de inicio. La realidad sobre el terreno no es la misma.
La documentación oficial de escalabilidad de Coolify es directa al respecto: el soporte de Docker Swarm está etiquetado como experimental. El patrón multiservidor estándar usa servidores remotos validados conectados por SSH con un Docker Registry compartido entre ellos, e instancias de Traefik ejecutándose por servidor. El modo Swarm requiere un mínimo de tres servidores con la misma arquitectura (todos ARM, o todos AMD64). ¿Kubernetes? «Solo planificado, pero todavía no en la hoja de ruta, así que sin fecha estimada». Si lees la propia página de Coolify sobre esto, la versión corta es: el multiservidor funciona, Swarm es una beta y Kubernetes es una visión.
Dokploy incorpora Docker Swarm como un modo de primera clase sin marca experimental. Traefik gestiona el enrutamiento tanto en configuraciones de servidor único como de Swarm. La versión v0.29.0 añadió soporte multiservidor sin root, lo que cierra una brecha real (se acabó el SSH solo para root al añadir nodos remotos).
Si el clustering multinodo es algo que vas a necesitar en los próximos seis meses, y no «algún día en una diapositiva», Dokploy es hoy la opción de menor riesgo.
Conclusión clave de la sección: si el clustering está en tu hoja de ruta a corto plazo, la diferencia de Swarm inclina la recomendación hacia Dokploy con independencia de los demás ejes.
Sistemas de build y soporte de lenguajes
A los equipos que llegan desde Heroku les importarán sobre todo qué ecosistemas de buildpacks admite cada herramienta, porque eso decide cuánta reescritura necesita tu proyecto antes de su primer despliegue.
La vía de build de Coolify es Nixpacks (por defecto, autodetectado a partir de los archivos de tu proyecto), Dockerfile o una imagen Docker preconstruida. Nixpacks es sólido para los casos comunes (Node, Python, PHP, Go, Rust), pero la autodetección tiene asperezas. Conviene verificarlo para tu pila: una incidencia de Nixpacks de enero de 2026 que afectaba a proyectos Laravel con ambos composer.json y package.json producía bloques de ubicación de Nginx duplicados, lo que rompía una clase de despliegues hasta que se corrigió aguas arriba.
Dokploy admite Nixpacks, Dockerfile e imagen Docker, y añade Heroku Buildpacks, Paketo Buildpacks y Railpack por encima. Si tu proyecto ya se construye limpiamente con heroku.yml o un buildpack, Dokploy te deja conservar ese flujo de trabajo. Coolify te pedirá que lo conviertas.
En la superficie ambas herramientas parecen iguales: despliegues por Git-push desde GitHub, GitLab, Bitbucket, SSL automático de Let's Encrypt, una interfaz web para variables de entorno y gestión de bases de datos. La amplitud de sistemas de build es uno de los pocos lugares donde Dokploy claramente se estira más.
Catálogos de aplicaciones de un clic
Para operadores no técnicos que quieren desplegar servicios de código abierto conocidos (n8n, Plausible, Supabase, Ghost, Listmonk, el habitual elenco de autoalojados), el tamaño de la biblioteca de plantillas de un clic es un diferenciador real. Para algunos usuarios, eso es más importante que otros aspectos como el rendimiento o ser ligero.
Coolify ofrece más de 300 servicios de un clic en aproximadamente 40 categorías: IA, analítica, automatización, bases de datos, seguridad, almacenamiento y demás. Es la biblioteca más grande con diferencia y la respuesta práctica para no desarrolladores que quieren desplegar un servicio sin escribir un archivo Compose.
La biblioteca de plantillas de Dokploy es más pequeña. La documentación actual de Dokploy no publica un recuento claro, así que no voy a darte un número.
La respuesta práctica: si tu flujo de trabajo es «desplegar n8n, Supabase y Plausible con dos clics cada uno», Coolify gana este eje con claridad. Si escribes tus propias aplicaciones y solo quieres desplegarlas, el tamaño del catálogo no importa y los demás ejes sí.
Cómo elegir: recomendaciones por caso de uso
Aquí no hay un único ganador. Hay correspondencias entre una herramienta y una forma de despliegue:
- Equipo no técnico que quiere una biblioteca de servicios: Coolify. El catálogo de más de 300 plantillas es una ventaja significativa.
- Desarrollador nativo de Docker que quiere ligereza + gestión estándar de Compose: Dokploy.
- Hardware ARM64 (Raspberry Pi, VPS basado en ARM): Coolify. Dokploy no anuncia soporte ARM64 en la documentación actual; si estás en ARM, opta por Coolify por defecto hasta que confirmes lo contrario.
- Clustering multinodo que usarás este trimestre: Dokploy. Swarm nativo frente a Swarm experimental es el factor decisivo.
- Apache 2.0 puro, sin posible nivel de pago futuro: Coolify.
- Migrando desde Heroku y querer conservar los Heroku Buildpacks: Dokploy.
- Preocupado por los CVE de enero de 2026: un Coolify actualizado (v4.0.0+) está bien. La verdadera pregunta es tu modelo de exposición. Si no puedes vincular el panel a una red privada o VPN, Dokploy es la opción menos estresante: superficie más pequeña y una historia más corta de divulgaciones de alta severidad.
Una nota sobre cómo desplegar cualquiera de las dos herramientas
Una vez que has elegido, la instalación en sí es un comando en cualquiera de los dos proyectos, pero hay un atajo que conviene conocer. Tanto Coolify como Dokploy están disponibles como despliegues de un clic en nuestro marketplace, con Ubuntu 24.04 y Docker preinstalados y el panel ya accesible. Si quieres saltarte la configuración manual, los listados del marketplace para Coolify y Dokploy son el camino más rápido. Si prefieres partir de un sistema operativo limpio y ejecutar tú mismo el instalador oficial, ambos proyectos publican un script de una línea; elige el que encaje con tu flujo de aprovisionamiento.
Preguntas frecuentes
¿Sigue siendo Dokploy de código abierto tras el cambio de licencia de 2026?
Sí para la plataforma central. A partir del January 21, 2026, el núcleo de Dokploy es Apache 2.0 estándar. Una Dokploy Source Available License independiente rige ahora el código en proprietary/ los directorios, actualmente acotada a futuras funciones empresariales (SSO/SAML, RBAC granular, registros de auditoría, marca blanca). Para uso autoalojado en solitario y en equipos pequeños, Dokploy es funcionalmente de código abierto.
¿Siguen siendo motivo de preocupación las vulnerabilidades de seguridad de Coolify de enero de 2026?
Los 11 CVE divulgados están parcheados en Coolify v4.0.0 (lanzado el April 27, 2026). Si ejecutas v4.0.0 o una versión más reciente, las vulnerabilidades divulgadas están resueltas. Lo que queda es la exposición: mantén Coolify actualizado y no expongas el panel a la internet pública. Vincúlalo a una red privada o ponlo detrás de una VPN.
