Cloudron vs CasaOS vs Coolify: comparativa en un VPS

Qué está construyendo

Está eligiendo una herramienta además de instalarla. Tres paneles prometen convertir un VPS vacío en un host de aplicaciones con interfaz gráfica: Cloudron, CasaOS y Coolify. Esta guía instala cada uno en el mismo sistema Ubuntu 24.04 recién preparado, instala una primera aplicación y examina los aspectos que rara vez aparecen en las capturas de pantalla: TLS, copias de seguridad, actualizaciones, consumo de memoria y dificultad para migrar a otra solución. Al final sabrá cuál se adapta mejor a sus necesidades o si la respuesta correcta es «ninguno; use Docker Compose».

Ninguna de estas herramientas es mágica. Las tres usan el mismo Docker Engine que podría administrar manualmente. Lo que un panel le ofrece, a cambio de dinero, RAM o dependencia del proveedor, son cuatro tareas automatizadas: instalación de aplicaciones con un clic, certificados TLS automáticos, copias de seguridad programadas y gestión de usuarios. Si esas cuatro funciones justifican la sobrecarga en su caso, el panel resulta útil. Si ejecuta uno o dos servicios y quiere saber exactamente qué hay en su sistema, lea primero la sección «Omitir los tres» y ahórrese el trabajo.

Requisitos compartidos y problemas importantes

Las tres opciones presuponen un VPS con KVM, no virtualización mediante contenedores. Docker necesita un kernel real, y Cloudron rechaza directamente OpenVZ y LXC. Compruébelo con systemd-detect-virt: kvm o qemu es correcto; openvz o lxc no lo es. En un plan KVM, el comando muestra kvm, y en un servidor físico muestra none; cualquiera de los dos valores permite continuar.

A partir de ahí, los requisitos difieren. Este es el primer factor que determina la elección.

• RAM. CasaOS funciona correctamente con 1GB; se desarrolló para hardware Raspberry Pi y sigue siendo ligero. Coolify necesita 2GB y dos núcleos de CPU como mínimo, y aproximadamente 600 MB corresponden al propio Coolify. Cloudron necesita 2GB como mínimo y funciona mejor con 4GB, porque ejecuta un servidor de correo y una base de datos antes de instalar una sola aplicación.
• Un dominio y control sobre su DNS. Cloudron y Coolify necesitan un dominio real con DNS operativo. Cloudron necesita idealmente acceso mediante API a su proveedor de DNS para crear registros y certificados wildcard por sí mismo. CasaOS funciona con una IP pública sin dominio, pero en ese caso no tendrá TLS.
• Puertos. Las tres opciones necesitan que 80 y 443 estén abiertos para HTTP y HTTPS. Coolify también publica su panel en 8000 y usa 6001 para el canal en tiempo real y 6002 para el terminal en el navegador. Mantenga abierto el puerto 22 para SSH en todas ellas.

Configure el DNS para que apunte al servidor antes de empezar. Un panel que no puede resolver su propio nombre de host no puede solicitar un certificado, y dedicará la primera hora a solucionar ese problema en lugar de configurar el software. Apunte un registro A a la IP del servidor y, en Coolify, añada un registro wildcard (*.apps.example.com) para que cada aplicación desplegada tenga su propio subdominio.

Cloudron: el appliance gestionado y opinado

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 un App Store seleccionado con aplicaciones empaquetadas como Nextcloud, WordPress, Gitea, Mattermost y otras. Está dirigido a quienes quieren que sus aplicaciones estén gestionadas, con actualizaciones automáticas, certificados automáticos y copias de seguridad automáticas, y están dispuestos a pagar por ello.

Instalación. Requiere un sistema limpio y asume el control completo del servidor. Ejecute esto en un servidor Ubuntu 24.04 (Noble) recién instalado y no instale 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 después reinicia el servidor. Cuando vuelva a estar disponible, abra https://<your-ip>, acepte el certificado temporal autofirmado y complete la configuración en el navegador: indique su dominio, elija su proveedor DNS y Cloudron aprovisionará su propio panel en my.example.com.

Añadir la primera aplicación. En el panel, abra el App Store, haga clic en Nextcloud, por ejemplo, elija el subdominio files.example.com y pulse Install. Cloudron crea el registro DNS, solicita el certificado de Let's Encrypt, aprovisiona la base de datos, configura el inicio de sesión único y programa una copia de seguridad, sin que tenga que modificar ningún archivo de configuración. Esta es toda la propuesta de Cloudron, y la cumple.

TLS y copias de seguridad. Es la opción más completa de las tres. Cada subdominio de aplicación recibe un certificado automático de Let's Encrypt, que se renueva automáticamente. Las copias de seguridad se programan y forman parte de la plataforma. Pueden dirigirse a un directorio local, S3 u otro almacenamiento remoto. También permiten restaurar cada aplicación por separado e incluso clonarla con un clic en un subdominio nuevo.

Coste y licencias: lea esto antes de decidir. Cloudron es un producto de pago con un nivel gratuito limitado: el plan gratuito permite dos aplicaciones. Al instalar una tercera aplicación, se alcanza el límite de pago; una suscripción de pago (Pro o Max, con facturación mensual o anual y aplicaciones ilimitadas en ambos casos) desbloquea más funciones. Este es el dato más importante sobre Cloudron. Está pulido precisamente porque es un negocio, y el nivel gratuito se parece más a una prueba ampliada que a una plataforma para una instalación que crece.

Modo de fallo: la regla del sistema limpio. Si intenta instalar Cloudron en un servidor que ya ejecuta algún servicio, la configuración se cancela antes de modificar nada:

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 una exigencia arbitraria. Cloudron fija versiones específicas de nginx, Docker y Node, y se integra profundamente con ellas. Por eso no puede coexistir con sus propias copias. La solución es una imagen nueva de Ubuntu 24.04 y nada más: sin servidor web, sin Docker y ni siquiera un firewall configurado manualmente. Si inició el servidor con la imagen incorrecta, la configuración también rechaza cualquier sistema que no sea una versión Ubuntu LTS compatible (22.04 o 24.04) en x86-64. ARM, LXC y OpenVZ no son compatibles.

Segundo modo de fallo: los certificados wildcard necesitan la API de DNS. Si elige la opción de DNS "Manual" durante la configuración en lugar de proporcionar a Cloudron un token de API, Cloudron no puede crear registros ni solicitar un certificado wildcard. Después, cada nueva aplicación requiere que añada manualmente un registro DNS antes de emitir el certificado, y el panel queda esperando ese registro. Proporcione a Cloudron acceso mediante API a un proveedor DNS compatible, como Cloudflare, Route 53, DigitalOcean u otros, y todo el proceso se completará con un clic.

CasaOS: el panel gratuito para laboratorios domésticos

Qué es. CasaOS, de IceWhale, es un panel gratuito y de código abierto que funciona sobre Docker y ofrece una pantalla de inicio, una tienda de aplicaciones y un gestor de archivos. Surgió en el entorno de los servidores domésticos, por lo que está orientado a laboratorios domésticos: se configura rápido, tiene una interfaz sencilla y requiere poca administración. Está dirigido a quienes quieren una interfaz más cómoda para Docker sin pagar por ella.

Instalación. Una sola línea, y no exige un sistema limpio:

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

El instalador añade varios servicios de systemd (casaos, casaos-gateway, casaos-app-management y otros). Confirme que la puerta de enlace se haya iniciado antes de abrir un navegador:

systemctl status casaos-gateway

Cuando esté en ejecución, el panel estará disponible en http://<your-ip> (HTTP sin cifrar, puerto 80). Cree una cuenta local y podrá acceder.

Añadir la primera aplicación. Abra la App Store, elija una aplicación y haga clic en Install. CasaOS escribe un proyecto de Docker Compose en segundo plano y expone la aplicación en un puerto del host, por ejemplo http://<your-ip>:8080. Su tienda incluye las aplicaciones habituales para servidores domésticos, por lo que un servidor multimedia Jellyfin en un VPS o una biblioteca de fotos Immich autohospedada se instalan con un par de clics. Si todavía no ha elegido un servidor de fotos, conviene leer primero los requisitos de RAM y las aplicaciones móviles que diferencian PhotoPrism de Immich, porque en un equipo con CasaOS y 1GB esa elección determina si la aplicación llegará a ejecutarse. También puede importar cualquier docker-compose.yaml que quiera, y esa es su principal ventaja: las aplicaciones son contenedores normales, no un formato propietario.

TLS y copias de seguridad, el punto débil. Aquí es donde se notan las limitaciones de que sea «gratuito». CasaOS sirve todo mediante HTTP sin cifrar de forma predeterminada, incluido su propio panel. No incorpora Let's Encrypt ni copias de seguridad programadas. Los datos se almacenan en volúmenes de Docker bajo /DATA, y usted debe encargarse de las copias de seguridad (un restic o tar ejecutado mediante cron).

Modo de fallo, sin TLS y sin indicaciones. No se muestra ningún error. Instala una aplicación, abre http://<your-ip>:8080 y funciona, mediante una conexión sin cifrar que el navegador marca como «No seguro». Las contraseñas y las cookies de sesión atraviesan la red en texto claro. Además, CasaOS ha tenido vulnerabilidades reales de ejecución remota de código en su panel (CVE-2023-37265 y CVE-2023-37266, un bypass de autenticación que podía encadenarse hasta comprometer por completo el host), por lo que exponer directamente ese puerto HTTP a Internet supone un riesgo real, no una cuestión de estilo. La solución es no exponer nunca CasaOS directamente. Coloque delante un reverse proxy que termine TLS, como nginx con un certificado de Let's Encrypt obtenido mediante Certbot, Caddy o un Cloudflare Tunnel, y reenvíe las peticiones a CasaOS sólo dentro de la red local. Tenga en cuenta que CasaOS ya utiliza el puerto 80, por lo que el proxy y CasaOS entrarán en conflicto por ese puerto a menos que cambie primero CasaOS a otro puerto.

Coste. Es realmente gratuito para siempre y no limita el número de aplicaciones. El coste está en la operación: usted debe gestionar TLS, las copias de seguridad y el bastionado.

Coolify: el PaaS autohospedado

Qué es. Coolify es una plataforma como servicio de código abierto y autohospedada, similar a Heroku o Vercel, pero ejecutada en su propio servidor. Su unidad nativa no es «instalar esta aplicación empaquetada», sino «implementar este repositorio de Git»: conecte un repositorio y Coolify lo compila mediante Nixpacks o su propio Dockerfile, lo implementa y vuelve a implementarlo con cada push. También ofrece bases de datos y servicios con instalación en un clic. Está dirigida a desarrolladores que implementan su propio código y quieren implementar mediante push sin contratar un PaaS.

Instalación.

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

El script instala Docker e inicia la propia pila de contenedores de Coolify. Compruebe que estén en buen estado antes de continuar:

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

Debe ver que coolify, coolify-db, coolify-redis, coolify-realtime y coolify-proxy indican Up. El panel está en http://<your-ip>:8000. Cree inmediatamente la cuenta de administrador, porque la página de registro permanece abierta hasta que se crea la primera cuenta, y quien acceda primero controlará el servidor. Después, establezca el dominio de la instancia y apunte un registro DNS comodín (*.example.com o *.apps.example.com) al servidor para que Coolify pueda asignar a cada aplicación implementada su propio subdominio.

Añadir la primera aplicación. Conecte una fuente de Git (GitHub, GitLab o una URL de repositorio normal), seleccione una rama, establezca el dominio e implemente la aplicación. El proxy Traefik integrado en Coolify enruta el subdominio y solicita el certificado. Para software ya preparado, el catálogo de Services permite implementar servicios con un par de clics: la misma pila de automatización de flujos de trabajo n8n que de otro modo tendría que configurar manualmente aparece como una entrada, al igual que Uptime Kuma para monitorizar páginas de estado.

TLS y copias de seguridad. Coolify obtiene automáticamente certificados de Let's Encrypt para cada aplicación mediante Traefik, incluido en la instalación, por lo que cada subdominio implementado recibe un certificado. Las copias de seguridad se centran en las bases de datos: puede programar volcados de Postgres y MySQL en almacenamiento compatible con S3. La copia de seguridad de toda la instancia, incluida la configuración de Coolify almacenada en /data/coolify, requiere más trabajo manual. Exporte esa configuración y guárdela por separado.

Coste y licencia. La edición autohospedada es completamente de código abierto y gratuita y no limita el número de aplicaciones. También existe Coolify Cloud, una opción de pago que aloja el plano de control mientras las aplicaciones siguen ejecutándose en sus propios servidores. Es práctica, pero no necesaria.

Modo de fallo: la aplicación se implementa, pero el dominio no carga. El panel funciona correctamente en http://<ip>:8000, la compilación termina correctamente, pero la URL de la aplicación devuelve un error de conexión o un 404 page not found de Traefik. Esto apunta al proxy o al DNS, no a la aplicación. Hay dos causas habituales. En primer lugar, los puertos 80 o 443 ya estaban ocupados cuando el proxy intentó iniciarse, por lo que su contenedor terminó 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

En segundo lugar, falta el registro DNS comodín, por lo que Traefik nunca recibe solicitudes para ese nombre de host. Si, en cambio, toda la tarjeta del servidor en Coolify muestra «Server is not reachable», se trata de otro problema: Coolify no puede comunicarse con el socket de Docker del servidor, normalmente porque el daemon de Docker está detenido o porque una clave SSH no funciona. Consulte los registros para conocer la causa real antes de formular hipótesis:

docker logs coolify-proxy --tail 100

Corrija el problema desde la página Proxy: pulse Restart Proxy, o restablezca la configuración del proxy a los valores predeterminados e inícielo de nuevo. Después, espere unos dos minutos para que se estabilice. Mantenga el puerto 8000 accesible sólo desde su propia IP, o vuelva a abrirlo temporalmente si el proxy presenta problemas, en lugar de dejarlo expuesto a Internet. Ese puerto sirve el panel mediante HTTP sin cifrar. La documentación de Coolify también indica que los puertos 8000, 6001 y 6002 pueden cerrarse cuando el panel se sirve mediante su propio dominio.

Carga de recursos en el mismo VPS

Medida en estado inactivo en el mismo servidor de 4GB, antes de implementar una carga de trabajo real. Comprueba la tuya con free -m y docker stats --no-stream en lugar de confiar en una sola cifra, porque el total cambia según la combinación de aplicaciones.

• CasaOS es el más ligero. El panel consta de un conjunto reducido de servicios Go. Calcula entre 150 y 300 MB de carga adicional, además de los contenedores que ejecutes.
• Coolify ejecuta varios contenedores auxiliares propios (la aplicación, un Postgres, un Redis, un servicio en tiempo real y Traefik), por lo que consume entre 600 MB y 1 GB en estado inactivo antes de implementar nada.
• Cloudron es el que más recursos consume en reposo, porque ejecuta su propio nginx, base de datos, pila de correo y sistema de monitorización, los uses o no. Calcula entre 1 y 1.5 GB en estado inactivo. Por eso exige 2GB como mínimo y funciona con más margen con 4GB.

En un VPS pequeño de 2GB, CasaOS deja más recursos disponibles para las aplicaciones reales y Cloudron deja menos. Si tu plan es de 2GB y quieres ejecutar Cloudron con su servidor de correo, planifica ampliar el servidor.

Comparación de actualizaciones, copias de seguridad y dependencia de la plataforma

Actualizaciones. Cloudron actualiza la plataforma y todas las aplicaciones según un calendario probado por el propio servicio: requiere el menor esfuerzo y ofrece más asistencia guiada. Coolify se actualiza desde su propio panel con un botón. CasaOS actualiza el panel mediante su script de instalación o apt, pero debe descargar y reiniciar las aplicaciones que haya instalado.

Dependencia de la plataforma, el problema que aparece en el segundo año. CasaOS es la opción que menos dependencia crea: sus aplicaciones son proyectos Compose normales, por lo que puede copiar docker-compose.yaml y los volúmenes de /DATA a cualquier otro host y continuar. Coolify queda en un punto intermedio: los despliegues utilizan sus propios Dockerfiles y repositorios, pero su configuración se almacena en la base de datos de Coolify. Por tanto, para cambiar de host debe volver a crear los proyectos en el destino. Cloudron es la opción que más dependencia crea: las aplicaciones están empaquetadas para Cloudron. Aunque los datos se pueden trasladar fácilmente mediante sus excelentes copias de seguridad, el empaquetado no se puede trasladar. Por eso debe volver a desplegar las aplicaciones en la plataforma de destino. Datos portátiles, infraestructura de despliegue no portátil.

Cuál deberías elegir

Versión corta, seguida de una alternativa. Elige Cloudron si quieres que el servidor requiera la menor intervención posible de las tres opciones, vas a ejecutar varias aplicaciones empaquetadas y pagarás una cuota anual por TLS administrado, copias de seguridad y actualizaciones. Elige CasaOS si se trata de un laboratorio doméstico detrás de tu propia red o de un reverse proxy, quieres una interfaz sencilla para Docker y no estás dispuesto a pagar nada. Elige Coolify si despliegas tu propio código desde Git y quieres implementar con cada push y TLS automático, sin pagar el precio de una PaaS alojada. Si ninguna de estas tres opciones encaja contigo, la sección siguiente ofrece la respuesta sincera.

Omita los tres si...

Sea realista con su escala. Si sólo ejecuta una o dos aplicaciones o quiere saber y controlar exactamente qué hay en su servidor, omita los paneles. La sobrecarga y la dependencia del proveedor no compensan en una pila pequeña y estable. La opción autogestionada consiste en colocar un reverse proxy delante de sus propios archivos Compose: Traefik con TLS automático delante de varias aplicaciones Docker Compose le proporciona HTTPS equivalente a una configuración con un clic, sin la sobrecarga del panel, y puede hacer copias de seguridad con un trabajo de restic ejecutado mediante cron que realmente entiende.

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 argumento es aún más claro: una instalación de Nextcloud en Docker con TLS y su propia rutina de copias de seguridad requiere un archivo Compose y un certificado. Implementar un appliance completo para ejecutarla sólo añadiría costes, sin aportar beneficios. Si todavía está decidiendo qué ejecutar antes de decidir cómo, la guía sobre qué merece la pena autohospedar en 2026 es un mejor punto de partida.

FAQ

¿Realmente necesito un panel de self-hosting?

Sólo si valora las cuatro tareas que un panel automatiza en varias aplicaciones: instalaciones con un clic, TLS automático, copias de seguridad programadas y gestión de usuarios. Para uno o dos servicios, Docker Compose sin más detrás de Traefik hace el mismo trabajo con TLS, pero con mucha menos sobrecarga y sin dependencia del proveedor. Los paneles resultan útiles cuando ejecuta muchas aplicaciones y su tiempo vale más que la RAM que consumen.

¿Qué panel es mejor para principiantes?

Para un laboratorio doméstico en el que nada está expuesto a Internet hostil, CasaOS es el comienzo más sencillo: un comando y una interfaz amigable, sin costes. Sin embargo, antes de exponer cualquier servicio debe colocar delante un reverse proxy con terminación TLS, porque CasaOS utiliza HTTP sin cifrar. Si quiere que TLS y las copias de seguridad se gestionen automáticamente y está dispuesto a pagar, Cloudron es la opción que más acompaña al usuario, dentro de su límite gratuito de dos aplicaciones.

¿Cloudron es gratuito?

En parte. El nivel gratuito permite dos aplicaciones, lo que resulta suficiente para probarlo o para una instalación muy pequeña. A partir de ahí, Cloudron requiere una suscripción de pago, con facturación mensual o anual, y las modalidades de pago permiten aplicaciones ilimitadas. Es un producto comercial con un plan gratuito limitado, no software libre, así que debe incluir su coste en el presupuesto si su stack va a crecer.

¿Puedo ejecutar estos paneles junto a mis aplicaciones actuales?

Cloudron: no. Requiere un equipo Ubuntu limpio y aborta la instalación si nginx, Docker o Node ya están instalados, porque administra todo el equipo. CasaOS y Coolify son más flexibles, ya que instalan su propia pila de Docker y, en principio, pueden compartir un equipo. Sin embargo, ambos necesitan los puertos 80 y 443, por lo que entran en conflicto con cualquier servidor web o proxy que ya esté en ejecución. En un equipo que ya aloja otros servicios, un panel suele ser la herramienta equivocada; use Traefik y Compose en su lugar.

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

Planifique la migración antes de necesitarla. En CasaOS, copie el docker-compose.yaml de la aplicación y sus volúmenes /DATA al nuevo host y vuelva a iniciarlos. En Coolify, exporte la configuración de cada proyecto y apúntelo a los mismos repositorios en el destino. En Cloudron, restaure los datos desde sus copias de seguridad en aplicaciones recién instaladas en la nueva plataforma, porque el empaquetado de Cloudron no se puede trasladar; sólo se trasladan los datos. En todos los casos, pruebe la restauración en un equipo desechable antes de retirar el equipo antiguo.