Cloudron vs CasaOS vs Coolify: comparativa para 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 comunes y problemas importantes

Los tres asumen un VPS con KVM, no una virtualización basada en 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 aquí, los requisitos numéricos divergen. Este es el primer factor que orienta 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 claramente 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 requiere idealmente acceso a la API de su proveedor DNS para crear registros y certificados comodín por sí mismo. CasaOS funciona con una IP sin dominio, pero en ese caso no tendrá TLS.
• Puertos. Cloudron y Coolify necesitan que 80 y 443 estén abiertos para HTTP y HTTPS. CasaOS sirve su panel mediante HTTP sin cifrar, por lo que sólo necesita el puerto 80. Además, Coolify sirve su panel en 8000 y usa 6001 para su canal en tiempo real y 6002 para la terminal del navegador. Mantenga abierto el puerto 22 para SSH en los tres casos.

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 el caso de Coolify, añada un registro comodín (*.apps.example.com) para que cada aplicación desplegada obtenga su propio subdominio.

Cloudron: el appliance gestionado y con opiniones definidas

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 pila de correo, además de una App Store seleccionada con aplicaciones empaquetadas (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. Ejecute esto en un servidor Ubuntu 24.04 (Noble) recién instalado y no haga 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 la pila de correo, y después reinicia el sistema. Cuando el servidor vuelva a estar disponible, abra https://<your-ip>, acepte el certificado autofirmado temporal y termine 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 la 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, todo sin que tenga que modificar un archivo de configuración. Esa es la propuesta principal del producto y cumple con ella.

TLS y copias de seguridad. Es la opción más completa de las tres. Cada subdominio de aplicación obtiene un certificado de Let's Encrypt automático, que Cloudron renueva por usted. Las copias de seguridad están integradas y se programan para almacenarse en un directorio local, S3 u otro almacenamiento remoto. También permiten restaurar cada aplicación por separado e incluso clonar una aplicación con un clic en un subdominio nuevo.

Coste y licencias: lea esto antes de decidirse. Cloudron es un producto de pago con un nivel gratuito limitado: el plan gratuito permite dos aplicaciones. Al instalar una tercera aplicación, aparece un bloqueo 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á tan 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 vaya a crecer.

Modo de fallo, la regla del sistema limpio. Si intenta instalar Cloudron en un servidor que ya ejecuta otros servicios, 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 its installation.
Please start with a fresh Ubuntu install and run this script again.

La causa no es una exigencia arbitraria. Cloudron fija versiones concretas de nginx, Docker y Node, y los integra profundamente, por lo que 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 sistema con la imagen incorrecta, la configuración también rechaza cualquier sistema que no sea una versión Ubuntu LTS compatible (22.04, 24.04 o 26.04) en x86-64; ARM, LXC y OpenVZ no son compatibles. Desde Cloudron 10 (septiembre de 2026), Ubuntu 26.04 es la versión predeterminada para las instalaciones nuevas, por lo que debe elegir esa imagen si va a empezar desde cero hoy.

Segundo modo de fallo, los certificados wildcard necesitan la API DNS. Si durante la configuración elige la opción DNS "Manual" en lugar de proporcionar a Cloudron un token de API, no podrá crear registros ni obtener un certificado wildcard por usted. Para cada aplicación nueva tendrá que añadir manualmente un registro DNS antes de que se pueda emitir el certificado, y el panel permanecerá a la espera de ese registro. Proporcione a Cloudron acceso mediante API a un proveedor DNS compatible (Cloudflare, Route 53, DigitalOcean y otros) y todo el proceso se reducirá a 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 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 y lo implementa. Después, vuelve a implementarlo con cada push. También ofrece bases de datos y servicios con implementación en un clic. Está dirigido a desarrolladores que implementan su propio código y quieren implementar mediante push sin alquilar un PaaS.

Instalación.

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

El script instala Docker y pone en marcha la propia pila de contenedores de Coolify. Compruebe que estén saludables antes de continuar:

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

Debería ver coolify, coolify-db, coolify-redis, coolify-realtime y coolify-proxy, todos con el estado Up. El panel está en http://<your-ip>:8000. Cree inmediatamente la cuenta de administrador, porque la página de registro queda abierta hasta que se crea la primera cuenta y la primera persona que acceda a ella controlará el servidor. Después, configure 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, configure el dominio e impleméntela. El proxy Traefik integrado de Coolify enruta el subdominio y solicita el certificado. Para el 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. Traefik, incluido en Coolify, gestiona automáticamente un certificado de Let's Encrypt para cada aplicación, por lo que cada subdominio implementado obtiene su 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 (la propia configuración de Coolify, que se encuentra en /data/coolify) requiere más trabajo manual, así que expórtela y almacénela por su cuenta.

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 (de pago), que aloja el plano de control por usted mientras las aplicaciones siguen ejecutándose en sus propios servidores. Es práctico, pero no es obligatorio.

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. Primero, 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

Segundo, el nombre de host no resuelve al servidor: la aplicación puede usar un subdominio generado mediante un registro comodín y dicho registro DNS puede faltar, o puede usar un dominio personalizado sin un registro DNS propio que apunte al servidor. En ese caso, Traefik nunca recibe una petición 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 está dañada. Consulte el motivo real en los registros antes de hacer suposiciones:

docker logs coolify-proxy --tail 100

Corríjalo desde la página Proxy: pulse Restart Proxy o restablezca la configuración del proxy a los valores predeterminados y vuelva a iniciarlo. 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 cuando el proxy falle) en lugar de dejarlo expuesto a Internet. Ese puerto sirve el panel mediante HTTP sin cifrar, y la documentación de Coolify 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

¿Necesito realmente 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 básico detrás de Traefik hace el mismo trabajo de TLS con mucha menos sobrecarga y sin dependencia del proveedor. Los paneles resultan rentables cuando ejecuta muchas aplicaciones y su tiempo vale más que la RAM que consumen.

¿Qué panel es mejor para principiantes?

En un laboratorio doméstico donde nada está expuesto a Internet hostil, CasaOS ofrece el inicio más sencillo: un comando y una interfaz amigable, sin costes. Pero debe colocar delante un reverse proxy con terminación TLS antes de exponer cualquier servicio, porque utiliza HTTP sin cifrar. Si quiere que el TLS administrado y las copias de seguridad se gestionen automáticamente y está dispuesto a pagar, Cloudron es la opción que más guí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 es una suscripción de pago, con facturación mensual o anual, y aplicaciones ilimitadas en los niveles de pago. 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 existentes?

Cloudron: no. Requiere un sistema Ubuntu limpio y se cancela si nginx, Docker o Node ya están instalados, porque administra toda la máquina. CasaOS y Coolify son más flexibles, ya que instalan su propio stack de Docker y, en principio, pueden compartir un sistema, pero CasaOS necesita el puerto 80 para su panel y el proxy de Coolify necesita los puertos 80 y 443. Por tanto, cada uno entra en conflicto con cualquier servidor web o proxy que ya utilice esos puertos. En un sistema que ya aloja servicios, un panel suele ser la herramienta equivocada; use Traefik y Compose.

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

Planifique la migración antes de necesitarla. Desde CasaOS, copie docker-compose.yaml de la aplicación y sus volúmenes /DATA al nuevo host y vuelva a iniciarlos. Desde Coolify, exporte la configuración de cada proyecto y haga que apunte a los mismos repositorios en el destino. Desde Cloudron, restaure los datos de 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 sistema desechable antes de retirar el antiguo.