Cloudron vs CasaOS vs Coolify en un VPS

Qué vas a construir

Elegir una herramienta es tan importante como la instalación misma. Tres paneles prometen convertir un VPS vacío en un host de aplicaciones mediante clics: Cloudron, CasaOS y Coolify. Esta guía instala cada uno en un servidor Ubuntu 24.04 limpio, instala una primera aplicación y analiza los aspectos que no suelen mostrarse: TLS, backups, actualizaciones, consumo de memoria y la dificultad de migrar. Al finalizar, sabrás cuál se adapta a tus necesidades o si la respuesta correcta es "ninguno, usa Docker Compose".

Ninguno de estos paneles es magia. Los tres utilizan el mismo Docker Engine que podrías gestionar manualmente. Lo que un panel ofrece, ya sea por costo, RAM o dependencia del proveedor, es la automatización de cuatro tareas: instalación de aplicaciones con un clic, certificados TLS automáticos, backups programados y gestión de usuarios. Si estas cuatro funciones justifican el consumo de recursos para ti, el panel vale la pena. Si solo ejecutas uno o dos servicios y prefieres saber exactamente qué hay en tu servidor, lee primero la sección "Saltar los tres" para evitar complicaciones innecesarias.

Requisitos compartidos y problemas comunes

Los tres sistemas requieren un VPS KVM, no virtualización basada en contenedores. Docker necesita un kernel real, y Cloudron no es compatible con OpenVZ ni LXC. Verifique con systemd-detect-virt: kvm o qemu son válidos, pero openvz o lxc no lo son. En un plan KVM el comando imprime kvm, y en bare metal imprime none; cualquiera de los dos resultados permite continuar.

A partir de aquí, los requisitos varían, y este es el primer factor para elegir.

• RAM. CasaOS funciona correctamente con 1GB; está optimizado para hardware Raspberry Pi y consume pocos recursos. Coolify requiere un mínimo de 2GB de RAM y dos núcleos de CPU; aproximadamente 600 MB son para el propio Coolify. Cloudron requiere un mínimo de 2GB y funciona mejor con 4GB, ya que ejecuta un servidor de correo y una base de datos antes de instalar cualquier aplicación.
• Un dominio y DNS bajo su control. Tanto Cloudron como Coolify requieren un dominio real con DNS operativos. Cloudron requiere idealmente acceso vía API a su proveedor de DNS para gestionar registros y certificados wildcard automáticamente. CasaOS puede funcionar solo con una IP, pero no tendrá TLS.
• Puertos. Los tres requieren los puertos 80 y 443 abiertos para HTTP y HTTPS. Coolify utiliza adicionalmente el puerto 8000 para su panel de control, el 6001 para su canal en tiempo real y el 6002 para la terminal en el navegador. Mantenga el puerto 22 abierto para SSH en todos los casos.

Configure el DNS hacia el servidor antes de comenzar. Un panel que no puede resolver su propio hostname no puede solicitar certificados; perderá la primera hora depurando esto en lugar de usar el software. Apunte un registro A a la IP del servidor y, para Coolify, añada un registro wildcard (*.apps.example.com) para que cada aplicación desplegada tenga su propio subdominio.

Cloudron: el appliance especializado y optimizado

Qué es. Cloudron es una plataforma comercial que convierte un servidor completo en un appliance gestionado. Ejecuta su propio reverse proxy, base de datos y stack de correo, además de una App Store curada con aplicaciones empaquetadas (Nextcloud, WordPress, Gitea, Mattermost, entre otras). Está diseñado para usuarios que requieren aplicaciones gestionadas, con actualizaciones automáticas, certificados automáticos y backups automáticos, y que están dispuestos a pagar por ello.

Instalación. Requiere un sistema limpio y toma el control total del servidor. Ejecute esto en un servidor Ubuntu 24.04 (Noble) recién instalado y nada más:

wget https://cloudron.io/cloudron-setup
chmod +x cloudron-setup
sudo ./cloudron-setup

El script instala Docker, nginx, una base de datos y el stack de correo, y luego reinicia el sistema. Cuando el servidor esté disponible, abra https://<your-ip>, acepte el certificado temporal autofirmado y complete la configuración en el navegador: asigne su dominio, elija su proveedor de DNS y el sistema aprovisionará su propio dashboard en my.example.com.

Añadir la primera aplicación. En el dashboard, abra la App Store, haga clic en (por ejemplo) Nextcloud, elija el subdominio files.example.com y prespte Install. Cloudron crea el registro DNS, solicita el certificado de Let's Encrypt, aprovisiona la base de datos, configura el single sign-on y programa un backup, todo sin necesidad de editar archivos de configuración. Esta es la propuesta de valor principal y funciona.

TLS y backups. Es una de las funciones más sólidas. Cada subdominio de aplicación obtiene un certificado Let's Encrypt automático que se renueva solo. Los backups están integrados y programados, con destino a un directorio local, S3 u otro almacenamiento remoto; permite la restauración por aplicación e incluso el clonado de una aplicación a un nuevo subdominio con un solo clic.

Costo y licencias, lea esto antes de decidir. Cloudron es un producto de pago con un nivel gratuito limitado: el plan gratuito permite dos aplicaciones. Si instala una tercera aplicación, aparecerá un muro de pago; una suscripción de pago (Pro o Max, con facturación mensual o anual, ambas con aplicaciones ilimitadas) desbloquea más funciones. Este es el dato más importante sobre Cloudron. El producto es tan pulido porque es un negocio, y el nivel gratuito es más una prueba extendida que una solución para un stack en crecimiento.

Modo de error, la regla del sistema limpio. Si intenta instalar Cloudron en un servidor que ya tiene servicios ejecutándose, la configuración fallará antes de realizar cambios:

Error: Some packages like nginx/docker/nodejs are already installed. Cloudron requires
specific versions of these packages and will install them as part of it's installation.
Please start with a fresh Ubuntu install and run this script again.

La causa no es capricho del software. Cloudron utiliza versiones específicas de nginx, Docker y Node y las integra profundamente, por lo que no puede coexistir con sus propias instalaciones. La solución es una imagen limpia de Ubuntu 24.04 y nada más: sin servidores web, sin Docker, ni siquiera un firewall configurado manualmente. Si inició la imagen incorrecta, la configuración también rechazará cualquier sistema que no sea un Ubuntu LTS compatible (22.04 o 24.04) en x86-64; ARM, LXC y OpenVZ no son compatibles.

Segundo modo de error, los certificados wildcard requieren API de DNS. Si elige la opción de DNS "Manual" durante la configuración en lugar de proporcionar un token de API a Cloudron, el sistema no podrá crear registros ni certificados wildcard por usted. Cada aplicación nueva requerirá que añada un registro DNS manualmente antes de que se pueda emitir el certificado, y el dashboard se quedará esperando ese registro. Si otorga a Cloudron acceso vía API a un proveedor de DNS compatible (Cloudflare, Route 53, DigitalOcean, entre otros), todo el proceso se reduce a un solo clic.

CasaOS: el dashboard para home-labs gratuito

Qué es. CasaOS, de IceWhale, es un dashboard gratuito y de código abierto que funciona sobre Docker. Proporciona una pantalla de inicio, una tienda de aplicaciones y un gestor de archivos. Se desarrolló para el entorno de servidores domésticos, por lo que su enfoque es para home-labs: configuración rápida, interfaz amigable y sin procesos complejos. Está diseñado para usuarios que buscan una interfaz mejor para Docker sin costes de licencia.

Instalación. Se instala con una sola línea y no requiere un sistema operativo limpio:

curl -fsSL https://get.casaos.io | sudo bash

El instalador añade un conjunto de servicios systemd (casaos, casaos-gateway, casaos-app-management, entre otros). Confirme que el gateway esté activo antes de abrir el navegador:

systemctl status casaos-gateway

Cuando esté en ejecución, el dashboard estará en http://<your-ip> (HTTP estándar, puerto 80). Cree una cuenta local para acceder.

Añadir la primera aplicación. Abra la App Store, elija una aplicación y haga clic en Install. CasaOS genera un proyecto Docker Compose internamente y expone la aplicación en un puerto del host, por ejemplo http://<your-ip>:8080. Su tienda incluye las aplicaciones habituales de servidores domésticos; instalar un servidor de medios Jellyfin en un VPS o una biblioteca de fotos Immich auto-alojada solo requiere un par de clics. También puede importar cualquier docker-compose.yaml que desee, que es su mayor ventaja: las aplicaciones son contenedores estándar, no un formato propietario.

TLS y copias de seguridad, el punto débil. Aquí es donde se nota que es una herramienta gratuita. CasaOS sirve todo mediante HTTP estándar por defecto, incluido su propio dashboard. No incluye Let's Encrypt ni programador de copias de seguridad integrado. Sus datos se almacenan en volúmenes de Docker bajo /DATA, y realizar el backup es responsabilidad del usuario (mediante un restic o tar programado con cron).

Modo de fallo: sin TLS y sin avisos. No hay errores de ejecución. Instala una aplicación, abre http://<your-ip>:8080 y funciona, pero mediante una conexión sin cifrar que el navegador marcará como "Not Secure". Las contraseñas y las cookies de sesión viajan en texto plano. Peor aún, CasaOS ha presentado vulnerabilidades reales de ejecución remota de código en su dashboard (CVE-2023-37265 y CVE-2023-37266, un bypass de autenticación que permitía el compromiso total del host); por tanto, exponer ese puerto HTTP directamente a internet es un riesgo real, no una cuestión estética. La solución es nunca exponer CasaOS directamente. Coloque un reverse proxy delante que gestione el TLS, como nginx con un certificado Let's Encrypt de Certbot, Caddy o un Cloudflare Tunnel, y reenvíe el tráfico a CasaOS solo en la red local. Tenga en cuenta que CasaOS ya utiliza el puerto 80, por lo que su proxy y CasaOS entrarán en conflicto a menos que mueva CasaOS a otro puerto primero.

Coste. Totalmente gratuito y sin límite de aplicaciones. El coste es operativo: usted debe gestionar el TLS, las copias de seguridad y el endurecimiento del sistema.

Coolify: el PaaS auto-alojado

Qué es. Coolify es una plataforma como servicio (PaaS) de código abierto y auto-alojada, similar a Heroku o Vercel pero en tu propio servidor. Su unidad nativa no es "instalar esta aplicación empaquetada" sino "desplegar este repositorio Git": conectas un repo y Coolify lo construye (mediante Nixpacks o tu propio Dockerfile) y lo despliega, realizando un nuevo despliegue en cada push. También incluye bases de datos y servicios con un solo clic. Está orientado a desarrolladores que despliegan su propio código y desean push-to-deploy sin alquilar un PaaS.

Instalación.

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

El script instala Docker y levanta el stack de contenedores de Coolify. Verifica que estén saludables antes de continuar:

docker ps --format 'table {{.Names}}\t{{.Status}}'

Deberías ver coolify, coolify-db, coolify-redis, coolify-realtime y coolify-proxy reportando todos Up. El dashboard está en http://<your-ip>:8000. Crea tu cuenta de administrador inmediatamente, ya que la página de registro permanece abierta hasta que se crea la primera cuenta; quien llegue primero tendrá el control del servidor. Luego, configura el dominio de tu instancia y apunta un registro DNS wildcard (*.example.com o *.apps.example.com) al servidor para que Coolify pueda asignar un subdominio a cada aplicación desplegada.

Añadir la primera aplicación. Conecta una fuente Git (GitHub, GitLab o una URL de repositorio), elige una rama, establece el dominio y despliega. El proxy Traefik integrado en Coolify gestiona las rutas del subdominio y solicita el certificado. Para software estándar, el catálogo de Services permite desplegar elementos con un par de clics: el mismo stack de automatización de flujos de trabajo n8n que de otro modo configurarías manualmente es una entrada, al igual que Uptime Kuma para monitoreo de páginas de estado.

TLS y backups. Let's Encrypt automático por aplicación mediante el Traefik incluido, por lo que cada subdominio desplegado obtiene un certificado. Los backups se centran en las bases de datos: puedes programar volcados (dumps) de Postgres y MySQL hacia almacenamiento compatible con S3. El backup de la instancia completa (la configuración de Coolify, que reside en /data/coolify) es más manual; exporta y almacena eso por tu cuenta.

Costo y licencias. La edición auto-alojada es completamente open-source y gratuita, sin límite de aplicaciones. Existe una opción de Coolify Cloud (de pago) que aloja el plano de control por ti mientras tus aplicaciones siguen ejecutándose en tus propios servidores; es conveniente pero no es obligatorio.

Modo de fallo: la aplicación se despliega pero su dominio no carga. El dashboard funciona correctamente en http://<ip>:8000 y la compilación termina con éxito, pero la URL de la aplicación devuelve un error de conexión o un 404 page not found de Traefik. Esto indica un problema en el proxy o en el DNS, no en tu aplicación. Hay dos causas comunes. Primero, los puertos 80 o 443 ya estaban ocupados cuando el proxy intentó iniciar, por lo que su contenedor falló con un error de Docker:

Error response from daemon: driver failed programming external connectivity on endpoint coolify-proxy: Bind for 0.0.0.0:443 failed: port is already allocated

Segundo, falta el registro DNS wildcard, por lo que Traefik nunca recibe una petición para ese hostname. Si, por el contrario, la tarjeta del servidor en Coolify indica "Server is not reachable", el fallo es distinto: Coolify no puede comunicarse con el socket de Docker del servidor, generalmente debido a un daemon de Docker detenido o una clave SSH rota. Revisa el motivo real en los logs antes de intentar adivinar:

docker logs coolify-proxy --tail 100

Soluciónalo desde la página de Proxy: presiona Restart Proxy, o restablece la configuración del proxy a los valores por defecto e inícialo de nuevo; luego espera unos dos minutos a que se estabilice. Mantén el puerto 8000 accesible solo desde tu propia IP (o ábrelo temporalmente si el proxy falla) en lugar de dejarlo abierto al mundo; el puerto sirve el dashboard mediante HTTP simple, y la documentación de Coolify indica que los puertos 8000, 6001 y 6002 pueden cerrarse una vez que el dashboard se sirva a través de su propio dominio.

Sobrecarga de recursos en el mismo VPS

Medido en estado idle en el mismo equipo de 4GB, antes de desplegar cualquier carga de trabajo real. Verifique su sistema con free -m y docker stats --no-stream en lugar de confiar en un solo valor, ya que el total varía según la combinación de sus aplicaciones.

• CasaOS es el más ligero. El panel es un conjunto pequeño de servicios en Go; considere una sobrecarga de aproximadamente 150 a 300 MB adicional a los contenedores que ejecute.
• Coolify ejecuta varios contenedores de soporte propios (la app, un Postgres, un Redis, un servicio en tiempo real y Traefik), por lo que consume entre 600 MB y 1 GB en idle antes de desplegar cualquier cosa.
• Cloudron es el más pesado en reposo, porque ejecuta su propio nginx, base de datos, stack de correo y monitoreo independientemente de si se utilizan o no; reserve entre 1 y 1.5 GB en idle. Por esto requiere un mínimo de 2GB y funciona con mayor fluidez en 4GB.

En un VPS pequeño de 2GB, CasaOS deja más espacio para aplicaciones reales y Cloudron deja el menor espacio. Si su plan es de 2GB y desea usar Cloudron con su servidor de correo activo, planifique una actualización del equipo.

Comparativa de actualizaciones, backups y lock-in

Actualizaciones. Cloudron actualiza la plataforma y cada app siguiendo un cronograma probado para requerir el mínimo esfuerzo y asistencia. Coolify se actualiza a sí mismo desde su propio dashboard con un solo botón. CasaOS actualiza el panel mediante su script de instalación o apt, pero la gestión de las actualizaciones y el reinicio de las apps instaladas depende del usuario.

Lock-in, el problema en el segundo año. CasaOS es el que menos lock-in presenta: sus apps son proyectos Compose estándar, por lo que puede copiar el docker-compose.yaml y los volumes en /DATA a cualquier otro host para continuar el servicio. Coolify tiene un nivel intermedio: sus deploys utilizan sus propios Dockerfiles y repos, pero la configuración reside en la base de datos de Coolify, por lo que cambiar de host requiere recrear los proyectos en el nuevo destino. Cloudron es el que más lock-in presenta: las apps están empaquetadas por Cloudron; aunque los datos se pueden exportar fácilmente mediante sus backups, el empaquetado no es portable, por lo que debe realizar un re-deploy en la plataforma de destino. Datos portables, infraestructura no portable.

Cuál elegir

Versión corta y luego detalles adicionales. Elige Cloudron si buscas la opción que requiere menos gestión manual, planeas ejecutar varias aplicaciones empaquetadas y estás dispuesto a pagar una cuota anual por TLS, copias de seguridad y actualizaciones gestionadas. Elige CasaOS si este es un laboratorio doméstico detrás de tu propia red o un reverse proxy, buscas una interfaz amigable para Docker y no quieres realizar ningún pago. Elige Coolify si despliegas tu propio código desde Git y necesitas push-to-deploy con TLS automático, sin el coste de un PaaS alojado. Si ninguna de estas tres opciones se ajusta a tus necesidades, la siguiente sección contiene la respuesta definitiva.

Salte los tres si...

Sea honesto sobre su escala. Si solo ejecuta una o dos aplicaciones, o si desea entender y controlar exactamente qué hay en su servidor, salte los paneles. La sobrecarga y la dependencia del proveedor no valen la pena para un stack pequeño y estable. La ruta DIY consiste en un reverse proxy delante de sus propios archivos Compose: Traefik con TLS automático delante de varias apps de Docker Compose le ofrece el equivalente a HTTPS con un solo clic sin el peso de un panel, y puede realizar copias de seguridad con un trabajo de restic programado mediante cron que usted realmente comprenda.

services:
  whoami:
    image: traefik/whoami
    labels:
      - traefik.enable=true
      - traefik.http.routers.whoami.rule=Host(`whoami.example.com`)
      - traefik.http.routers.whoami.tls.certresolver=le
    networks: [web]
networks:
  web:
    external: true

Para una única aplicación principal, el caso es aún más claro: una instalación de Nextcloud en Docker con TLS y su propia rutina de backup es un archivo Compose y un certificado. Implementar un appliance completo para ejecutarla solo generaría costes sin beneficios. Si aún está decidiendo qué ejecutar antes de decidir cómo, la guía sobre qué merece la pena auto-alojar en 2026 es el mejor punto de partida.

FAQ

¿Realmente necesito un panel de autoalojamiento?

Solo si valoras las cuatro funciones que un panel automatiza en varias aplicaciones: instalaciones en un clic, TLS automático, backups programados y gestión de usuarios. Para uno o dos servicios, usar Docker Compose con Traefik ofrece el mismo TLS con mucho menos consumo de recursos y sin dependencia de un proveedor. Los paneles valen la pena cuando ejecutas muchas aplicaciones y tu tiempo es más valioso que la RAM que consumen.

¿Qué panel es mejor para un principiante?

Para un home lab sin exposición a internet, CasaOS es la opción más sencilla: un solo comando y una interfaz amigable, sin costes. Sin embargo, debes configurar un reverse proxy con terminación TLS antes de exponer cualquier servicio, ya que CasaOS usa HTTP plano. Si buscas TLS gestionado y backups automáticos y estás dispuesto a pagar, Cloudron es la opción más automatizada, dentro de su límite de dos aplicaciones gratuitas.

¿Es gratuito Cloudron?

Parcialmente. El nivel gratuito permite dos aplicaciones, lo cual es suficiente para pruebas o configuraciones muy pequeñas. Más allá de eso, Cloudron requiere una suscripción de pago, con facturación mensual o anual, que permite aplicaciones ilimitadas. Es un producto comercial con un plan gratuito limitado, no es software libre; presupuesta su coste si tu stack va a crecer.

¿Puedo ejecutar estos paneles junto a mis aplicaciones actuales?

Cloudron: no. Requiere un sistema Ubuntu limpio y el proceso falla si nginx, Docker o Node ya están instalados, ya que el panel gestiona la máquina completa. CasaOS y Coolify son más flexibles, ya que instalan su propio stack de Docker y pueden compartir un servidor en teoría, pero ambos requieren los puertos 80 y 443, lo que genera conflictos con cualquier servidor web o proxy existente. En un servidor que ya aloja servicios, un panel suele ser la herramienta incorrecta; usa Traefik y Compose en su lugar.

¿Cómo puedo dejar de usar un panel más adelante?

Planifica la migración antes de necesitarla. Desde CasaOS, copia el docker-compose.yaml de la aplicación y sus volúmenes /DATA al nuevo host y reinícialos. Desde Coolify, exporta la configuración de cada proyecto y apunta hacia los mismos repositorios en el destino. Desde Cloudron, restaura los datos de sus backups en aplicaciones recién instaladas en la nueva plataforma, ya que el empaquetado de Cloudron no es portable, solo los datos. En todos los casos, prueba la restauración en un servidor de prueba antes de eliminar el anterior.