Coolify vs CapRover: comparativa de PaaS self-hosted

Qué es cada uno

CapRover existe desde 2018. Está construido sobre Docker Swarm, usa Nginx como proxy inverso —el componente que dirige cada dominio al contenedor correcto—, incluye una CLI oficial y un catálogo amplio de aplicaciones instalables con un clic. Su marca de fábrica es el subdominio automático: cada aplicación queda publicada en nombre.tudominio.com sin que toques el DNS.

Coolify apareció en 2022 y supera las 60.000 estrellas en GitHub. Usa Traefik como proxy, construye aplicaciones directamente desde Git con Nixpacks (que detecta si el proyecto es Node, Python, PHP o Go sin necesidad de Dockerfile) y administra servidores remotos independientes desde un panel central. Su ritmo de publicación de versiones es notablemente más alto.

La diferencia de fondo: CapRover se diseñó alrededor de un clúster; Coolify se diseñó alrededor de un flujo de trabajo con Git. Si no sabes todavía si te hace falta un servidor propio para esto, empieza por qué es un VPS y para qué sirve.

Coolify vs CapRover: tabla comparativa

Instalación: dos filosofías desde el primer comando

CapRover se instala como un contenedor de Docker al que le entregas el socket del daemon:

docker run -p 80:80 -p 443:443 -p 3000:3000 \
  -e ACCEPTED_TERMS=true \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /captain:/captain \
  caprover/caprover

Después necesitas crear en tu DNS un registro comodín *.algo.tudominio.com apuntando a la IP del servidor. Ese paso es obligatorio y es donde más gente se atasca: sin wildcard, CapRover no puede asignar subdominios automáticos. Abre los puertos 80/TCP, 443/TCP y UDP, y 3000/TCP para el panel.

Coolify se instala con su script oficial:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

El panel queda en el puerto 8000 y lo primero que debes hacer es crear la cuenta administrativa, antes de que otra persona reclame la instancia. El procedimiento completo, con DNS, certificados y endurecimiento del acceso, está en cómo instalar Coolify en un VPS.

Los dos comandos ejecutan software con privilegios de root sobre el daemon de Docker. Úsalos solo sobre un servidor limpio: si ya tienes Docker instalado por varias vías (paquete, snap, script), lo más rápido es reinstalar el sistema. Si nunca has trabajado con contenedores, conviene entender antes qué está pasando debajo con la guía de Docker en un VPS.

Docker Swarm frente a multi-servidor: la diferencia que decide

Esta sección es la que realmente separa a las dos plataformas.

Docker Swarm, que usa CapRover, convierte varios servidores en uno solo. Designas un nodo manager y le unes nodos worker; declaras que un servicio tenga tres réplicas y Swarm decide en qué máquinas corren, las reprograma si un nodo se cae y reparte el tráfico entre ellas. Para que eso funcione hay que abrir entre nodos el puerto 2377/TCP (gestión del clúster), 7946 en TCP y UDP (descubrimiento entre nodos) y 4789/UDP (red overlay). Añadir un nodo es ejecutar en él el comando docker swarm join con el token que da el manager.

Coolify no forma clúster: administra servidores separados. Conectas cada servidor por SSH desde el panel y despliegas aplicaciones en el que elijas. Si ese servidor se apaga, sus aplicaciones se apagan. No hay reprogramación automática ni réplicas repartidas.

Dicho sin adornos: para una agencia con doce clientes en doce VPS distintos, el modelo de Coolify es el correcto, porque cada cliente queda aislado y la caída o el compromiso de uno no toca a los demás. Para una aplicación con tráfico que ya no cabe en una máquina, el clúster de CapRover es la respuesta.

Ahora la parte que suele omitirse: Swarm no regala alta disponibilidad. Repartir contenedores web entre nodos es la parte fácil. La difícil es el estado: la base de datos y los archivos subidos por los usuarios. Si tus tres réplicas escriben en un volumen que solo existe en un nodo, ese nodo sigue siendo un punto único de fallo. La alta disponibilidad real exige almacenamiento compartido (NFS, Ceph, un servicio de objetos) y una base de datos replicada, y eso es trabajo de ingeniería que ninguna de las dos plataformas hace por ti.

Si tu alternativa a CapRover era Dokploy —que también trae Swarm nativo pero con desarrollo mucho más activo— la comparación está en Coolify vs Dokploy.

La CLI de CapRover y los builds automáticos de Coolify

La CLI es el argumento más sólido de CapRover para desarrolladores:

npm install -g caprover
caprover login
caprover deploy

Con un archivo captain-definition en el repositorio despliegas desde la terminal, sin abrir el navegador. Encaja muy bien en flujos donde el desarrollador controla el momento exacto del despliegue y en scripts de CI propios.

Coolify apuesta por el camino contrario: conectas el repositorio de GitHub, GitLab, Gitea o Forgejo, y cada push a la rama configurada dispara la construcción y el despliegue. Nixpacks detecta el lenguaje y genera la imagen sin que escribas nada; si prefieres control, usa tu propio Dockerfile. Para equipos que despliegan varias veces al día, esto elimina el paso manual por completo. Si además quieres alojar tu propio Git en el mismo servidor, es sencillo con Gitea o Forgejo en un VPS.

Consumo de recursos y qué VPS necesita cada uno

CapRover arranca en servidores más pequeños que Coolify. Su documentación asume una instancia típica de 1 GB de RAM y advierte que 512 MB probablemente no basten en cuanto haya compilaciones. Coolify pide oficialmente 2 núcleos, 2 GB de RAM y 30 GB de disco libre. Las dos soportan procesadores x86-64 y ARM64; CapRover ya no publica imágenes para ARMv7 de 32 bits, así que una placa antigua queda fuera.

Ese mínimo cubre el panel, no tu trabajo. La memoria se va en tres sitios: la plataforma, los contenedores en ejecución y las compilaciones. Un npm install de un proyecto Next.js supera con facilidad 1 GB por sí solo, y cuando el servidor se queda sin memoria el kernel empieza a matar procesos, normalmente los de las aplicaciones que ya estaban funcionando. Es el fallo más común en servidores pequeños con un PaaS encima, y se manifiesta como "la web se cayó sola mientras desplegaba".

Hay dos remedios reales y las dos plataformas los admiten. El primero es configurar swap, útil como colchón puntual aunque no sustituye a la RAM. El segundo, mejor si despliegas a menudo, es construir las imágenes fuera del servidor de producción y llevar solo la imagen ya lista.

El disco también se llena más rápido de lo que la gente espera: imágenes antiguas, caché de builds y logs se acumulan sin que nadie los mire. Conviene limpiar imágenes huérfanas con docker image prune de forma periódica y vigilar el espacio libre antes de que un despliegue falle por disco lleno.

Cómo migrar entre las dos plataformas

No existe importador automático en ninguna dirección. Lo que sí existe es un procedimiento repetible, porque debajo las dos ejecutan contenedores Docker:

1. 1 Inventaria antes de tocar nada: lista cada aplicación, su origen (repositorio o imagen), sus variables de entorno, sus volúmenes y sus dominios. Las variables son lo que más se olvida y lo que más rompe.
2. 2 Levanta la plataforma nueva en un servidor aparte. Migrar en caliente sobre el mismo servidor es la receta para quedarte sin panel y sin sitio a la vez.
3. 3 Recrea las aplicaciones sin estado primero: frontends y APIs que no guardan datos. Pruébalas con un subdominio temporal.
4. 4 Migra los datos con el servicio detenido. Un volcado con pg_dump o mysqldump con la aplicación parada, o un rsync del volumen con el contenedor apagado. Copiar un volumen de base de datos en caliente produce copias corruptas.
5. 5 Cambia el DNS al final y baja el TTL a 300 segundos un día antes, para poder revertir en minutos.
6. 6 Deja el servidor antiguo encendido una semana. Es la copia de seguridad más rápida que vas a tener.

Un detalle práctico si vas de CapRover a Coolify: los subdominios automáticos desaparecen. Cada aplicación necesitará su propio registro A. En sentido contrario, de Coolify a CapRover, tendrás que escribir un captain-definition por proyecto.