SSD Nodes Learn 🎉 VPS desde $5.50/mes
Guías Matt ConnorPor Matt Connor · Actualizado 2026-08-07

Cómo instalar Cloudron en un VPS con Ubuntu

Instala Cloudron en un VPS Ubuntu nuevo con DNS comodín, script de instalación y primer arranque. Incluye requisitos, recursos para 2 a 10 apps, correo y copias.

Instalar Cloudron en un VPS: versión breve

Para instalar Cloudron en un VPS necesita un servidor Ubuntu nuevo, al menos 2 GB de RAM y un dominio cuyos registros DNS pueda editar. La instalación se realiza con tres comandos y un reinicio. Casi todos los problemas aparecen antes de ese paso (imagen base incorrecta o tipo de virtualización incorrecto) o después (DNS, correo y copias de seguridad).

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

Cloudron instala, actualiza y realiza copias de seguridad de aplicaciones autoalojadas. También emite certificados TLS (seguridad de la capa de transporte). Cada aplicación se ejecuta en Docker y nginx se sitúa delante de todas ellas. Cada aplicación obtiene su propio subdominio del dominio. Por eso la configuración de DNS es el primer paso.

Por qué Cloudron es exigente con el sistema operativo base

El script de instalación comprueba el servidor antes de instalar nada. Si una comprobación falla, tendrá que solicitar un servidor nuevo. Lea estos requisitos antes de elegir una imagen.

  • Sólo Ubuntu y sólo tres versiones. Con cualquier otra opción, el proceso termina con Cloudron requires Ubuntu 20.04, 22.04, 24.04. Debian, Rocky y Alpine no son compatibles. Ubuntu 24.04 necesita Cloudron 8 o una versión posterior, y el script lo comprueba automáticamente.
  • Sólo Intel o AMD de 64 bits: Error: Cloudron only supports amd64/x86_64. Un VPS con ARM no puede ejecutarlo.
  • Sólo virtualización completa del hardware. En un VPS basado en contenedores, el script se detiene con Error: Cloudron does not support lxc, only runs on bare metal or with full hardware virtualization porque detecta el contenedor mediante systemd-detect-virt --container. KVM es compatible. OpenVZ y LXC no lo son.
  • El sistema de archivos raíz debe ser ext4 o xfs. Con cualquier otra opción se obtiene Error: Cloudron requires '/' to be ext4 or xfs. Así es como fallan las imágenes btrfs y zfs.
  • Se necesitan al menos 941 MB de RAM y 20 GB en /. El script mide estos valores con free -m y mediante el tamaño del sistema de archivos raíz.
  • Un servidor realmente nuevo. Si nginx, docker o node ya está instalado, el script lo rechaza con Error: Some packages like nginx/docker/nodejs are already installed..

Esta última comprobación suele generar dudas. La razón es la siguiente. Cloudron instala versiones fijadas de Docker, nginx, Node.js y MySQL, escribe la configuración de nginx para cada aplicación que aloja y administra por sí mismo las reglas del firewall de iptables. Un Docker que instaló ayer tiene la versión incorrecta y los archivos existentes de sitios de nginx se reemplazan. Cloudron administra todo el equipo, por lo que debe asignarle un VPS dedicado.

Hay otra comprobación que es fácil pasar por alto. En una CPU antigua sin AVX (extensiones vectoriales avanzadas), el script muestra CPU has no AVX support. MongoDB will be disabled y todas las aplicaciones que necesitan MongoDB pasan a no estar disponibles para su instalación. Compruebe la CPU antes de comprometerse con grep -m1 -o avx /proc/cpuinfo. En un host compatible, este comando muestra avx; en uno antiguo, no muestra nada.

¿Cuánta RAM necesita Cloudron?

El script no se ejecuta con menos de 941 MB, con Error: Cloudron requires atleast 1GB physical memory, y la documentación solicita 2 GB de RAM y 20 GB de disco. Ambas cifras son el mínimo para la plataforma, no para la plataforma más sus aplicaciones. Antes de instalar una sola aplicación, Cloudron ya ejecuta Docker, nginx, su propio servicio box, los contenedores de bases de datos que proporciona a las aplicaciones (MySQL, PostgreSQL, MongoDB), Redis y la pila de correo. Ejecute docker ps en una instalación nueva y cuéntelos.

Los límites de memoria de las aplicaciones se suman a esa base. Cada paquete de aplicación se distribuye con un límite bajo predeterminado. Puede aumentarlo con el control deslizante de la vista Resources de la aplicación. Cuando una aplicación supera su límite, se reinicia y envía una notificación OOM (sin memoria). Por eso, un servidor que reinicia continuamente una aplicación suele tener un problema de límites y no un error del software.

Esta es la configuración que recomendaría. Son recomendaciones para un servidor que no tendrá que reconstruir el próximo mes. No son resultados de pruebas comparativas.

ChartCloudron VPS sizing floor by number of apps
The data behind this chart
[
  {
    "label": "2 apps (free tier)",
    "vcpu": 2,
    "ram_gb": 4,
    "disk_gb": 60
  },
  {
    "label": "5 apps",
    "vcpu": 4,
    "ram_gb": 8,
    "disk_gb": 120
  },
  {
    "label": "10 apps",
    "vcpu": 6,
    "ram_gb": 16,
    "disk_gb": 240
  }
]

Dos aplicaciones funcionan sin problemas con 4 GB de RAM y 60 GB de disco. Unas diez aplicaciones necesitan 16 GB y 240 GB, porque la base de la plataforma nunca disminuye y cada aplicación añade una imagen de Docker, una base de datos y sus propios datos. El disco se llena más rápido de lo esperado: las imágenes, los datos de las aplicaciones y las copias de seguridad locales comparten un volumen hasta que mueve las copias de seguridad fuera del servidor.

Cloudron proporciona swap ilimitada a cada aplicación, por lo que el límite de memoria que configura sólo se aplica a la RAM. En una imagen de VPS sin archivo de swap, swapon --show no muestra ninguna salida y la presión de memoria se convierte directamente en reinicios OOM en lugar de ralentizar la aplicación. Añadir 2 GB de swap es una medida preventiva económica, aunque no sustituye a la memoria real. La diferencia entre los planes de VPS es pequeña frente a las horas que dedicará a ajustar los límites. Consulte cuánto cuesta realmente un VPS y compre el siguiente tamaño.

DNS: el registro comodín que hace funcionar los subdominios de las aplicaciones

Cloudron publica el dashboard en my.example.com y cada aplicación en su propio subdominio, por lo que DNS es un requisito previo y no un paso posterior. Apunte estos registros a la dirección IP pública del servidor antes de abrir el dashboard por primera vez:

  • my.example.com como registro A. Este es el dashboard.
  • *.example.com como registro A. Este es el registro que hace funcionar los subdominios de las aplicaciones, por lo que wiki.example.com y git.example.com resolverán en cuanto instale esas aplicaciones.
  • example.com como registro A, sólo si quiere alojar una aplicación en el dominio raíz.

Un registro comodín tiene menor prioridad que un registro explícito, por lo que un www.example.com existente que apunte a otro lugar seguirá funcionando.

Durante la configuración, elija cómo gestionará Cloudron DNS a partir de ese momento:

  • Un proveedor con API. Cloudron almacena un token de Cloudflare, DigitalOcean, Route53, Hetzner, Porkbun, Linode, deSEC, Gandi, Namecheap y alrededor de veinte proveedores más. Después, crea todos los registros directamente, incluidos los registros de correo.
  • Wildcard. Añade el registro * manualmente y Cloudron no escribe ningún registro.
  • Manual. Cloudron muestra cada registro y espera mientras usted lo añade, antes de cada instalación de una aplicación.

Un registro DNS comodín no es un certificado comodín. El proveedor de certificados predeterminado es Let's Encrypt Prod - Wildcard, que demuestra la propiedad mediante DNS, por lo que sólo funciona con un proveedor con API. En los backends Wildcard o Manual, se utiliza un certificado por aplicación validado mediante HTTP. Esto significa que el puerto entrante 80 debe permanecer abierto permanentemente. Si su registrador o proveedor de DNS aparece en la lista de API, utilícelo: los registros de correo y los certificados dejan de ser responsabilidad suya.

Verifique la configuración antes de continuar. dig +short my.example.com y dig +short anything.example.com deberían mostrar la dirección IP de su servidor. Si la consulta del comodín no muestra nada, las aplicaciones fallarán más adelante aunque el dashboard funcione correctamente.

Si el dominio está detrás de Cloudflare, configure los registros como DNS only. El proxy sólo reenvía HTTP y HTTPS, por lo que los puertos de correo dejan de funcionar y cada aplicación ve una dirección de Cloudflare en lugar de la dirección del visitante.

Ejecute el script de configuración

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

Ejecútelo como root o mediante sudo, porque, de lo contrario, lo primero que muestra es This script should be run as root.. La instalación tarda varios minutos y no muestra información mientras se ejecuta, ya que la salida de apt y las descargas de Docker se escriben en un archivo de registro. Supervise el proceso desde una segunda sesión SSH:

tail -f /var/log/cloudron-setup.log

Al final muestra After reboot, visit one of the following URLs and accept the self-signed certificate to finish setup. seguido de la dirección de su servidor y, después, solicita The server has to be rebooted to apply all the settings. Reboot now ? [Y/n]. Responda que sí. El indicador --skip-reboot permite programar el reinicio si lo necesita, pero Cloudron no se puede usar hasta que el servidor vuelva a estar disponible.

Primer arranque: dominio, backend DNS y cuenta de administración

Abra https://<server-ip> y acepte la advertencia del navegador. El certificado es autofirmado porque Cloudron aún no conoce su dominio y, por tanto, no tiene un dominio que solicitar a una autoridad de certificación. En Chrome, haga clic en Advanced y después en Proceed to <ip> (unsafe). En Firefox, haga clic en Advanced y después en Accept the Risk and Continue.

La primera pantalla solicita su dominio. Introduzca example.com y el panel quedará disponible en my.example.com. También puede usar un subdominio, como cloudron.example.com; en ese caso, el panel estará en my.cloudron.example.com. Seleccione el backend DNS, pegue el token de API si dispone de uno y cree la cuenta de administración con una dirección de correo que consulte habitualmente. Cloudron la usa para el registro en Let's Encrypt y para todas las alertas de la plataforma.

Al guardar, Cloudron solicita los certificados y mueve el panel a https://my.example.com. La URL basada en la dirección IP deja de funcionar en ese momento, así que guarde la nueva URL en sus marcadores.

Certificados: qué se renueva y cuándo deja de hacerlo

La renovación de certificados es automática y sigue ACME Renewal Information (ARI), el calendario que publica la autoridad certificadora. En la práctica, la renovación se realiza aproximadamente un mes antes de la fecha de expiración. Si una renovación falla, se envía un correo electrónico a la cuenta del administrador. Si el certificado expira, se utiliza el certificado autofirmado integrado. Eso es lo que significa realmente la advertencia del navegador en un sitio que funcionaba el día anterior.

La mayoría de los casos se debe a una de dos causas. La validación HTTP necesita que el puerto 80 acepte conexiones entrantes. Por tanto, cerrar el puerto 80 porque «todo usa HTTPS de todos modos» interrumpe la renovación de todas las aplicaciones que utilizan un backend Wildcard o Manual DNS. La validación DNS necesita un token de API que conserve permisos de escritura. Si se rota o se restringe ese token, la renovación falla de forma silenciosa hasta que llega el correo de advertencia.

La vista Domains tiene un botón Renew All para forzar el intento de inmediato y un proveedor Let's Encrypt Staging para realizar pruebas. Los certificados de staging no son de confianza para los navegadores de forma intencionada. Esa es precisamente su finalidad: puede repetir las pruebas tantas veces como necesite sin consumir el límite de solicitudes de producción.

¿Debe usar el servidor de correo integrado?

Cloudron incluye una pila de correo completa con buzones IMAP, submission, filtros sieve y firma DKIM (domainkeys identified mail). Se habilita por dominio en Email, dentro del panel. El problema es conseguir que el correo se entregue correctamente, y ninguna de estas dificultades depende de Cloudron.

  • La mayoría de los proveedores de VPS bloquean el puerto saliente 25 para controlar el spam. Algunos lo desbloquean después de abrir un ticket de soporte. Pruebe desde el servidor con nc -zv aspmx.l.google.com 25 (instale netcat-openbsd si falta el comando). Los puertos abiertos muestran succeeded, y un puerto bloqueado permanece bloqueado hasta que se agota el tiempo de espera.
  • El registro PTR (DNS inverso) lo configura el proveedor del VPS, no el proveedor de DNS, y debe coincidir con el nombre de host del correo. El correo enviado desde una dirección con un PTR genérico llega a las carpetas de spam.
  • Los registros SPF, DKIM y DMARC se escriben automáticamente en un backend de DNS con API. En los backends Wildcard o Manual debe añadirlos manualmente. Si falta el registro DKIM, ningún mensaje firmado podrá verificarse.

La configuración que funciona para la mayoría consiste en recibir el correo en Cloudron y enviarlo mediante un relay como SendGrid, Postmark, Mailgun o Amazon SES, configurado en la vista Email. El relay debe permitir el envío como cualquier dirección de su dominio. De lo contrario, rechazará las notificaciones de las aplicaciones procedentes de distintos remitentes. Si el correo es el motivo principal por el que compra el servidor, ejecute un servidor de correo dedicado, como Mailcow en otro equipo con su propia reputación de IP.

Si no usa Cloudron Email, bloquee los puertos 25, 465, 587, 993 y 4190 en el firewall del proveedor. Hágalo allí y no en el servidor, porque Cloudron escribe las reglas de iptables y espera administrarlas. Esto es lo contrario de un VPS convencional, donde administra las reglas de ufw usted mismo.

Configura el destino de las copias de seguridad antes de necesitarlo

De forma predeterminada, las copias de seguridad se guardan en el sistema de archivos local, en /var/backups, en el mismo disco que el resto. La documentación lo indica claramente: «Tener las copias de seguridad en el mismo disco físico que el servidor de la plataforma es peligroso». Un fallo del disco afecta a las aplicaciones y a las copias de seguridad al mismo tiempo.

Abra Backups, después Backup Sites, y configúrelo para que use otro destino desde el primer día. El almacenamiento de objetos compatible con S3 suele ser la opción habitual (Backblaze B2, Wasabi, Cloudflare R2, DigitalOcean Spaces o un bucket de MinIO en un segundo servidor). También se admiten destinos SSHFS, NFS, CIFS y de sistema de archivos convencional.

Tres opciones determinan si esa copia de seguridad resulta útil:

  • Formato. tgz escribe un archivo comprimido por aplicación y vuelve a cargarlo completo en cada ejecución. rsync carga sólo los archivos modificados, lo que resulta mucho más económico para un Nextcloud grande, pero genera muchas más peticiones a la API de almacenamiento.
  • Cifrado. AES-256 opcional que protege tanto el contenido de los archivos como sus nombres. Cloudron no conserva una copia de la contraseña. Si la pierde, nadie podrá descifrar las copias de seguridad, incluido usted. Guárdela en un gestor de contraseñas autohospedado antes de hacer clic en guardar.
  • Retención. Se expresa mediante cantidades, como 7 copias diarias y 4 semanales. Una retención prolongada en el almacenamiento de objetos se factura cada mes, así que elija una cantidad cuyo coste esté dispuesto a seguir pagando.

Después, pruebe una restauración. Instale una aplicación pequeña, restáurela desde el panel y compruebe que vuelve a estar disponible con sus datos. Una copia de seguridad que nunca se ha restaurado es sólo una suposición.

Límites del plan gratuito

En agosto de 2026, el plan gratuito está limitado a dos aplicaciones instaladas. Incluye todo lo demás: actualizaciones de las aplicaciones, copias de seguridad por aplicación, el firewall, el servidor de correo y el inicio de sesión único. La tercera aplicación es el punto en el que se necesita una licencia. Los planes de pago eliminan el límite de aplicaciones, y el plan superior añade grupos y roles de usuarios, un servidor de directorio y varios sitios de copia de seguridad. Los precios cambian, así que consulte la página de precios de Cloudron en lugar de basarse en una cifra incluida en un tutorial.

Una licencia cubre una instalación de Cloudron, por lo que dos servidores pequeños cuestan el doble que un servidor grande. Esta estructura de precios lleva a la mayoría de los usuarios a utilizar un solo VPS más grande, lo que contradice la recomendación habitual de distribuir los servicios entre varias máquinas. Dimensione el servidor teniendo esto en cuenta, ya que dividirlo más adelante implica pagar dos veces.

Cuando algo falla

Empiece con la comprobación integrada. Revisa DNS, certificados, disco, memoria y cada servicio por separado, e indica qué prueba falló:

sudo cloudron-support --troubleshoot

Después, use las herramientas habituales de systemd (el gestor del sistema y de servicios). systemctl status box muestra el estado del servicio de Cloudron, journalctl -u box -n 100 muestra sus registros recientes y journalctl -u docker cubre el entorno de ejecución de contenedores subyacente. Todo lo que haya fallado durante la instalación queda registrado en /var/log/cloudron-setup.log.

Si el panel no carga, normalmente el problema está en DNS o en el firewall del proveedor, no en Cloudron. Ejecute dig +short my.example.com desde su portátil y confirme que los puertos 80 y 443 estén abiertos en el firewall de red del proveedor. Es un control independiente de las reglas del propio servidor. Si va a empezar de nuevo, el script rechaza una segunda ejecución con Error: Cloudron is already installed. To reinstall, start afresh. La solución correcta es reconstruir el servidor.

Cuando Cloudron no es la opción adecuada

Cloudron encaja cuando quiere aplicaciones y no infraestructura. Encaja mal cuando quiere ejecutar sus propios contenedores de la forma que prefiera, porque controla nginx, Docker y el firewall, y sobrescribe lo que configure allí. Si su plan consiste en una carpeta de archivos Compose, Traefik delante de sus propias pilas de Docker Compose ofrece el mismo TLS automático y el enrutamiento por subdominios, sin una plataforma adicional. Si todavía no ha elegido, comparación entre Cloudron, CasaOS y Coolify los presenta lado a lado, y la lista más amplia de opciones para alojar por cuenta propia es un mejor punto de partida que una guía de instalación.

FAQ

¿Cuánta RAM necesita Cloudron en un VPS?

El script de instalación se niega a ejecutarse con menos de 941 MB y la documentación solicita 2 GB, pero esa es la cantidad mínima para la plataforma sin aplicaciones. Cloudron ejecuta Docker, nginx, su propio servicio box, contenedores de bases de datos y la pila de correo desde el primer arranque. Reserve 4 GB para dos aplicaciones y 16 GB para unas diez, y añada un archivo de swap, porque Cloudron proporciona swap ilimitada a las aplicaciones y un sistema sin swap convierte la presión de memoria en reinicios.

¿Puedo instalar Cloudron en Debian o en un servidor que ya ejecuta Docker?

Ninguna de las dos opciones funciona. El script comprueba la versión y se detiene con Cloudron requires Ubuntu 20.04, 22.04, 24.04, por lo que Debian, Rocky y Alpine quedan descartados. También se detiene cuando nginx, docker o node ya están presentes, porque instala versiones fijadas de todos ellos y escribe por su cuenta la configuración de nginx y las reglas de iptables. Empiece con una imagen de Ubuntu recién instalada en un VPS KVM.

¿Por qué fallan los subdominios de mis aplicaciones mientras el panel funciona?

Falta el registro DNS comodín. La instalación crea o requiere un registro A para my.example.com, por lo que el panel resuelve correctamente, mientras que wiki.example.com devuelve NXDOMAIN y el navegador indica que no se puede encontrar el sitio. Añada un registro A para *.example.com que apunte a la IP del servidor y confirme el resultado con dig +short wiki.example.com antes de instalar la aplicación.

¿Tengo que usar el servidor de correo de Cloudron?

No. Puede desactivar el correo entrante y enviar mediante un relay externo, como Postmark, Mailgun o Amazon SES. Esta es la opción más segura cuando el proveedor bloquea el puerto saliente 25 o la dirección IP no tiene reputación de correo. Si omite Cloudron Email por completo, cierre los puertos 25, 465, 587, 993 y 4190 en el firewall del proveedor, no en el servidor.

¿Qué ocurre cuando alcanzo el límite de dos aplicaciones del plan gratuito?

El panel bloquea la tercera instalación y solicita una clave de licencia. Las aplicaciones que ya están en ejecución no se modifican: siguen actualizándose, siguen incluyendo copias de seguridad y conservan sus certificados. Añadir una licencia elimina el límite sin reinstalar nada, por lo que el plan gratuito es una forma adecuada de probar primero la plataforma en un dominio real.