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 Buildpacks, 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), consume entre 600 MB y 1 GB al arrancar — a veces más. En un VPS de 2 GB, eso deja entre 1 y 1,4 GB para sus aplicaciones. La recomendación oficial es de 2 GB como mínimo y 4 GB para trabajar con holgura. La gestión multiservidor existe desde la v4 mediante agentes remotos, y el modelo de licencia es Apache 2.0 para el autoalojamiento.
Coolify en cifras
- RAM en reposo: 600 MB – 1 GB (solo la instancia, sin las aplicaciones)
- Requisitos mínimos: 2 GB de RAM, 2 vCPU, 30 GB de almacenamiento
- Licencia: Apache 2.0
- Multiservidor: sí, mediante agentes remotos (desde la v4)
- 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: entre 150 MB y 300 MB según la configuración, sin Redis ni base de datos interna obligatoria. En un VPS de 1 GB, Dokploy deja sitio a sus aplicaciones allí donde Coolify iría muy justo. 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 MIT.
Dokploy en cifras
- RAM en reposo: 150 – 300 MB
- Requisitos mínimos: 1 GB de RAM, 1 vCPU (2 GB recomendados)
- Licencia: MIT
- Multiservidor: sí (gestión multinodo)
- Preview deployments: parcial
- Rollback: sí
CapRover: madurez, ligereza y clúster Docker Swarm
CapRover existe desde 2018 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 notablemente baja: entre 100 MB y 200 MB, 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: 100 – 200 MB (Docker Swarm + CapRover)
- Requisitos mínimos: 1 GB de RAM, 1 vCPU
- 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 | 600 MB – 1 GB | 150 – 300 MB | 100 – 200 MB |
| Interfaz | Moderna, cuidada | Minimalista, rápida | Funcional, austera |
| Multiservidor | Sí (agentes remotos) | 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 | MIT | 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 1 a 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 agentes remotos
- Restricción severa de RAM (VPS de 1 GB) — únicamente Dokploy o CapRover: Coolify no puede funcionar en esas condiciones
- 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 *.votre-domaine.com → IP du 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: Dokploy y CapRover sirven ya con 1 GB, mientras que Coolify exige 2 GB como mínimo y se despliega con holgura sobre 4 GB. En todos los casos, se recomienda un almacenamiento SSD de al menos 20 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.
