La necesidad real de un desplegador PaaS en VPS
Un VPS en bruto le da acceso root a una máquina virtual: usted tiene que gestionar Docker, las actualizaciones, el reverse proxy, los certificados TLS, las variables de entorno, las copias de seguridad y los rollbacks por su cuenta. Un PaaS self-hosted se hace cargo de esa capa operativa. Expone un flujo de trabajo comparable al de Render o Railway — usted conecta un repositorio Git, el despliegue se ejecuta automáticamente, los certificados llegan solos — pero sobre su propia infraestructura. La pregunta no es si hace falta un PaaS, sino cuál elegir en función de su VPS y de su perfil.
Criterios de selección para un PaaS self-hosted
- RAM en reposo — memoria que consume la plataforma cuando no hay ningún despliegue en curso, determinante en un VPS de 1 a 2 GB
- Interfaz y facilidad de uso — calidad de la UI, claridad del onboarding, curva de aprendizaje hasta el primer despliegue
- Multiservidor — posibilidad de gestionar varios VPS desde una sola instancia de la plataforma
- Preview deployments — creación automática de un entorno por pull request, para revisar en condiciones reales antes del merge
- Rollback — facilidad para volver a una versión anterior en caso de regresión
- Observabilidad integrada — logs en tiempo real, métricas y alertas disponibles sin plugin externo
- Licencia y modelo open source — Apache 2.0, MIT o BSL, y lo que eso cambia para un uso comercial
- Madurez y comunidad — antigüedad del proyecto, frecuencia de las releases, experiencias en producción
Coolify: cobertura funcional completa, huella de memoria considerable
Coolify es el PaaS self-hosted con más estrellas en GitHub. Su principal baza es la cobertura funcional: gestiona aplicaciones con Dockerfile, los builders Nixpacks y Docker Compose, las bases de datos (PostgreSQL, MySQL, Redis, MongoDB), los servicios de un clic (Plausible, Umami, Gitea, n8n), los crons y los preview deployments por pull request. La interfaz está muy cuidada, con un onboarding guiado y una documentación abundante. La contrapartida es la RAM: la instancia de Coolify, con sus dependencias internas (Redis, Soketi para los WebSockets en tiempo real, PostgreSQL), es la que más memoria consume en reposo de las tres: en un VPS de 2 GB, el margen que queda para sus aplicaciones es escaso. El mínimo oficial es de 2 GB de RAM, 2 núcleos y 10 GB de disco; 4 GB dan un margen holgado. La gestión multiservidor se hace conectando servidores remotos por SSH, sin agente que instalar, y el modelo de licencia es Apache 2.0 para el autoalojamiento.
Coolify en cifras
- RAM en reposo: la más alta de las tres (aplicación, PostgreSQL, Redis y Soketi)
- Requisitos mínimos: 2 GB de RAM, 2 núcleos de CPU, 10 GB de disco
- Licencia: Apache 2.0
- Multiservidor: sí, servidores remotos conectados por SSH
- Preview deployments: sí, nativos
- Rollback: sí, con historial de despliegues
Dokploy: huella ligera, puesta en marcha rápida
Dokploy se presenta explícitamente como una alternativa ligera a Coolify y a los PaaS cloud. Se dirige a los desarrolladores que consideran Coolify demasiado pesado para un VPS de gama de entrada. Su interfaz es minimalista, construida con Next.js, y el primer despliegue es rápido — un solo comando lo instala todo. La RAM en reposo es su principal argumento: su pila se limita a la aplicación, una base PostgreSQL interna y Traefik, sin Redis ni servidor WebSocket aparte. En un VPS de 2 GB, Dokploy deja más sitio a sus aplicaciones que Coolify. Dokploy admite Dockerfiles, ficheros Compose, imágenes de Docker Hub, bases de datos gestionadas y certificados TLS mediante Traefik como reverse proxy interno. Sus límites actuales: los preview deployments están menos desarrollados que en Coolify, la biblioteca de servicios de un clic es más reducida y el proyecto es más joven, por lo que está menos probado con cargas importantes. Dokploy se distribuye bajo licencia Apache 2.0, salvo el código situado en una carpeta /proprietary, sujeto a una licencia source-available (DSAL).
Dokploy en cifras
- RAM en reposo: intermedia (aplicación, PostgreSQL y Traefik)
- Requisitos mínimos: 2 GB de RAM, 30 GB de disco
- Licencia: Apache 2.0 (salvo la carpeta /proprietary, bajo DSAL)
- Multiservidor: sí (gestión multinodo)
- Preview deployments: parcial
- Rollback: sí
CapRover: madurez, ligereza y clúster Docker Swarm
CapRover existe desde 2017 y fue, hasta la aparición de Coolify, la referencia del PaaS self-hosted open source. Destaca por su madurez, su ligereza y una CLI muy completa. La interfaz web es funcional, aunque más austera que la de sus competidores modernos; sigue siendo perfectamente legible para perfiles DevOps familiarizados con Docker. La RAM en reposo es la más baja de las tres, con una arquitectura basada en Docker Swarm que permite la escalabilidad horizontal en clúster. CapRover gestiona los Dockerfiles, las imágenes de Docker Hub y los Captain Definition files, además de una biblioteca de más de 100 aplicaciones desplegables con un clic. Los preview deployments no son nativos: hay que implementarlos mediante la CLI y scripts. El clúster multinodo con Docker Swarm, en cambio, es nativo y está probado. CapRover se distribuye bajo licencia Apache 2.0. Su principal límite: los preview deployments automáticos por PR exigen scripts adicionales, y la interfaz es menos moderna que la de sus dos competidores.
CapRover en cifras
- RAM en reposo: la más baja de las tres (Docker Swarm + CapRover)
- Requisitos mínimos: 1 GB de RAM, 5 GB de disco libre
- Licencia: Apache 2.0
- Multiservidor: sí, nativo mediante Docker Swarm
- Preview deployments: no nativo (scripts de CLI)
- Rollback: sí, mediante versiones de imagen
Tabla comparativa Coolify vs Dokploy vs CapRover
Desplace la tabla
| Criterio | Coolify | Dokploy | CapRover |
|---|---|---|---|
| RAM en reposo | Alta | Intermedia | Baja |
| Interfaz | Moderna, cuidada | Minimalista, rápida | Funcional, austera |
| Multiservidor | Sí (servidores remotos por SSH) | Sí (multinodo) | Sí (Docker Swarm nativo) |
| Preview deployments | Nativos | Parcial | No nativo (scripts de CLI) |
| Rollback | Historial de despliegues | Sí | Mediante versiones de imagen |
| Observabilidad integrada | Logs, métricas, alertas | Logs en tiempo real | Logs, métricas básicas |
| Curva de aprendizaje | Moderada | Baja | De moderada a alta |
| Licencia | Apache 2.0 | Apache 2.0 (+ DSAL) | Apache 2.0 |
Recomendación por perfil
La elección de un PaaS self-hosted depende menos de las funcionalidades que de la situación concreta: tamaño del VPS disponible, tamaño del equipo y necesidades de automatización CI/CD.
Qué herramienta para qué perfil
- Desarrollador en solitario o proyecto que arranca — Dokploy en un VPS de 2 GB: la escasa huella de memoria deja la mayoría de los recursos a sus aplicaciones, y el manejo es inmediato
- Agencia o equipo de 3 a 10 personas — Coolify en un VPS de 4 GB como mínimo: la cobertura funcional, los preview deployments nativos y la biblioteca de servicios de un clic justifican la huella de memoria
- DevOps con experiencia, infraestructura multiservidor — CapRover si está familiarizado con Docker Swarm y busca una solución probada y ligera; Coolify v4 si prefiere una interfaz moderna con servidores remotos gestionados por SSH
- Restricción severa de RAM (VPS de 1 GB) — CapRover: es el único de los tres cuyo mínimo oficial es de 1 GB, Coolify y Dokploy exigen 2
- Pipeline CI/CD con revisión por PR — Coolify por sus preview deployments nativos, o Dokploy si la funcionalidad parcial le basta
La trampa común a todos los PaaS self-hosted
Las tres plataformas se apoyan en Docker y en una red interna para conectar el reverse proxy con los contenedores de las aplicaciones. Si su aplicación no está conectada a la red del proxy interno — y sí expuesta directamente en el host —, el proxy no puede alcanzarla: síntoma clásico, una aplicación marcada como «desplegada» en el dashboard pero con error 502 desde el exterior. Segunda trampa compartida: el wildcard DNS. Si configura *.su-dominio.com → IP del VPS, las tres plataformas asignan automáticamente un subdominio a cada app y emiten el certificado TLS sin intervención. Sin ese wildcard, tendrá que crear un registro DNS manualmente antes de cada despliegue.
Su VPS, base de su PaaS
Las tres plataformas funcionan en cualquier VPS Linux con Docker instalado. La RAM disponible tras instalar la plataforma es la variable decisiva: CapRover exige 1 GB como mínimo, Dokploy y Coolify 2 GB, y Coolify se despliega con holgura sobre 4 GB. En todos los casos, se recomienda un almacenamiento SSD de al menos 30 GB para alojar las imágenes Docker y los volúmenes de datos. La elección de la plataforma no determina el nivel de servicio: define el margen que usted deja a sus aplicaciones.
