Come installare Cloudron su VPS Ubuntu: guida pratica

Installare Cloudron su una VPS: versione breve

Per installare Cloudron su una VPS è necessario un server Ubuntu pulito, almeno 2 GB di RAM e un dominio di cui sia possibile modificare i record DNS. L'installazione consiste in tre comandi e un riavvio. Quasi tutti i problemi si verificano prima di questo passaggio (immagine di base errata, tipo di virtualizzazione non supportato) o dopo (DNS, posta, backup).

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

Cloudron installa, aggiorna, esegue il backup ed emette certificati TLS (transport layer security) per le applicazioni self-hosted. Ogni applicazione viene eseguita in Docker, nginx si posiziona davanti a tutte e ogni applicazione riceve un proprio sottodominio del tuo dominio. Quest'ultimo dettaglio è il motivo per cui la configurazione DNS deve essere eseguita per prima.

Perché Cloudron richiede un sistema operativo di base specifico

Lo script di installazione esegue un controllo sul server prima di procedere; se un controllo fallisce, è necessario richiedere un nuovo server. Leggi i requisiti prima di selezionare un'immagine.

• Solo Ubuntu, limitato a tre versioni. Qualsiasi altro sistema operativo causa l'uscita con Cloudron requires Ubuntu 20.04, 22.04, 24.04. Debian, Rocky e Alpine non sono supportati. Ubuntu 24.04 richiede Cloudron 8 o versioni successive; lo script esegue questa verifica automaticamente.
• Solo architetture Intel o AMD a 64-bit: Error: Cloudron only supports amd64/x86_64. Un VPS ARM non è compatibile.
• Solo virtualizzazione hardware completa. Su un VPS basato su container, lo script si interrompe con Error: Cloudron does not support lxc, only runs on bare metal or with full hardware virtualization, poiché rileva il container tramite systemd-detect-virt --container. KVM è supportato, mentre OpenVZ e LXC no.
• Il filesystem root deve essere ext4 o xfs. Con qualsiasi altro tipo, si ottiene Error: Cloudron requires '/' to be ext4 or xfs; questo è il motivo per cui le immagini btrfs e zfs non superano il controllo.
• Almeno 941 MB di RAM e 20 GB su /, misurati tramite free -m e la dimensione del filesystem root.
• Un server realmente pulito. Se nginx, docker o node sono già installati, lo script rifiuta l'operazione con Error: Some packages like nginx/docker/nodejs are already installed..

Quest'ultimo controllo è spesso oggetto di discussione, ecco quindi la motivazione. Cloudron installa versioni specifiche di Docker, nginx, Node.js e MySQL, sovrascrive la configurazione di nginx per ogni applicazione ospitata e gestisce autonomamente le regole del firewall iptables. Una versione di Docker installata in precedenza non sarebbe quella corretta e i file di configurazione nginx esistenti verrebbero sostituiti. Cloudron assume il controllo dell'intera macchina, pertanto è necessario dedicare un VPS esclusivamente a questo scopo.

Un ulteriore controllo viene spesso trascurato. Su una CPU datata priva di AVX (advanced vector extensions), lo script stampa CPU has no AVX support. MongoDB will be disabled e ogni applicazione che richiede MongoDB risulterà impossibile da installare. Verifica la CPU prima di procedere con grep -m1 -o avx /proc/cpuinfo, che stampa avx su un host compatibile e non restituisce nulla su uno obsoleto.

Quanta RAM richiede Cloudron?

Lo script rifiuta di avviarsi con meno di 941 MB, tramite Error: Cloudron requires atleast 1GB physical memory, e la documentazione richiede 2 GB di RAM e 20 GB di disco. Entrambi i valori rappresentano il requisito minimo per la piattaforma, non per la piattaforma sommata alle tue applicazioni. Prima ancora di installare una singola app, Cloudron esegue Docker, nginx, il proprio servizio box, i container di database che fornisce alle app (MySQL, PostgreSQL, MongoDB), Redis e lo stack di posta. Esegui docker ps su un'installazione pulita per contarli.

I limiti di memoria delle app si sommano a questa base. Ogni pacchetto di un'app prevede un limite predefinito basso che puoi aumentare tramite lo slider nella vista Risorse dell'app. Quando un'app supera il proprio limite, viene riavviata e ti invia una notifica OOM (out of memory); pertanto, un server che riavvia continuamente un'app indica solitamente un problema di limiti piuttosto che un bug.

Ecco il dimensionamento che consiglio. Queste sono raccomandazioni per un server che non dovrai ricostruire il mese prossimo. Non sono risultati di benchmark misurati.

[
  {
    "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
  }
]

Due app funzionano correttamente con 4 GB di RAM e 60 GB di disco. Circa dieci app richiedono 16 GB e 240 GB, poiché la base della piattaforma non si riduce mai e ogni app aggiunge un'immagine Docker, un database e i propri dati. Il disco si riempie più velocemente di quanto previsto: immagini, dati delle app e backup locali condividono lo stesso volume finché non sposti i backup fuori dal server.

Cloudron assegna a ogni app swap illimitato, quindi il limite di memoria impostato si applica solo alla RAM. Su un'immagine VPS senza file di swap, swapon --show non restituisce alcun output e la pressione sulla memoria si traduce immediatamente in riavvii OOM anziché in un rallentamento dell'app. Aggiungere 2 GB di swap è un'assicurazione economica, sebbene non sostituisca la memoria reale. La differenza di prezzo tra i piani VPS è minima rispetto alle ore che spenderesti per ottimizzare i limiti, quindi verifica quanto costa realmente un VPS e acquista il taglio superiore.

DNS: il record wildcard che abilita i sottodomini delle applicazioni

Cloudron posiziona la dashboard su my.example.com e ogni applicazione su un proprio sottodominio; pertanto, il DNS è un prerequisito e non un passaggio successivo. Punta questi record all'indirizzo IP pubblico del server prima di aprire la dashboard per la prima volta:

• my.example.com come record A. Questa è la dashboard.
• *.example.com come record A. Questo è il record che abilita i sottodomini delle applicazioni, in modo che wiki.example.com e git.example.com vengano risolti nel momento in cui installi tali applicazioni.
• example.com come record A, solo se desideri un'applicazione sul dominio principale (bare domain).

Un record DNS wildcard ha una precedenza inferiore rispetto a un record esplicito, quindi un eventuale www.example.com esistente che punta altrove continuerà a funzionare.

Durante la configurazione, scegli come Cloudron gestirà il DNS in futuro:

• Provider API. Cloudron memorizza un token per Cloudflare, DigitalOcean, Route53, Hetzner, Porkbun, Linode, deSEC, Gandi, Namecheap e circa altri venti, scrivendo poi ogni record autonomamente, inclusi i record per la posta elettronica.
• Wildcard. Aggiungi manualmente il record * e Cloudron non scrive nulla.
• Manuale. Cloudron ti mostra ogni record e attende che tu lo aggiunga, prima dell'installazione di ogni singola applicazione.

Un record DNS wildcard non è un certificato wildcard. Il provider di certificati predefinito è Let's Encrypt Prod - Wildcard, che verifica la proprietà tramite DNS; pertanto, funziona solo con un provider API. Con i backend Wildcard o Manuale, si ricorre a un certificato per applicazione validato tramite HTTP, il che significa che la porta 80 in ingresso deve rimanere sempre aperta. Se il tuo registrar o provider DNS è presente nell'elenco delle API, utilizzalo: la gestione dei record di posta e dei certificati non sarà più un tuo compito.

Verifica prima di procedere. dig +short my.example.com e dig +short anything.example.com dovrebbero entrambi restituire l'indirizzo IP del tuo server. Se la query wildcard non restituisce nulla, le applicazioni falliranno in seguito, mentre la dashboard funzionerà correttamente.

Se il dominio si trova dietro Cloudflare, imposta i record su "DNS only". Il proxy inoltra solo traffico HTTP e HTTPS, quindi le porte per la posta elettronica smetterebbero di funzionare e ogni applicazione vedrebbe un indirizzo Cloudflare invece di quello del visitatore.

Esecuzione dello script di installazione

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

Eseguire lo script come root o tramite sudo, altrimenti il primo messaggio restituito sarà This script should be run as root.. L'installazione richiede diversi minuti e procede in background; l'output di apt e i pull di Docker vengono reindirizzati su un file di log. È possibile monitorare l'avanzamento da una seconda sessione SSH:

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

Al termine, lo script stampa After reboot, visit one of the following URLs and accept the self-signed certificate to finish setup. seguito dall'indirizzo del server e richiede The server has to be rebooted to apply all the settings. Reboot now ? [Y/n]. Rispondere yes. Il flag --skip-reboot è disponibile se si desidera pianificare il riavvio, ma Cloudron non sarà utilizzabile finché il sistema non sarà tornato online.

Primo avvio: dominio, backend DNS e account amministratore

Apri https://<server-ip> e accetta l'avviso del browser. Il certificato è auto-firmato perché Cloudron non conosce ancora il tuo dominio e non può quindi richiederne uno a una certification authority. In Chrome fai clic su Advanced, quindi su Proceed to <ip> (unsafe). In Firefox fai clic su Advanced, quindi su Accept the Risk and Continue.

La prima schermata richiede il dominio. Inserisci example.com e la dashboard si imposterà su my.example.com. Puoi utilizzare un sottodominio come cloudron.example.com; in tal caso, la dashboard sarà disponibile su my.cloudron.example.com. Seleziona il backend DNS, incolla il token API se ne possiedi uno e crea l'account amministratore utilizzando un indirizzo email che controlli regolarmente: verrà usato per la registrazione a Let's Encrypt e per tutti gli avvisi della piattaforma.

Al salvataggio, Cloudron richiede i certificati e sposta la dashboard su https://my.example.com. L'URL basato sull'indirizzo IP smetterà di funzionare, quindi aggiungi il nuovo indirizzo ai segnalibri.

Certificati: cosa si rinnova e quando il processo si interrompe

Il rinnovo dei certificati è automatico e segue le specifiche ACME Renewal Information (ARI), ovvero la pianificazione pubblicata dalla Certification Authority, che in genere prevede il rinnovo circa un mese prima della scadenza. Un rinnovo fallito invia una notifica via email all'account amministratore e, in caso di scadenza, il sistema ripiega sul certificato autofirmato predefinito. Questo meccanismo di fallback è la causa dei messaggi di avviso del browser su siti che funzionavano correttamente fino al giorno precedente.

Due cause spiegano la maggior parte dei problemi. La validazione HTTP richiede la porta 80 in ingresso; pertanto, chiudere la porta 80 con la convinzione che "tutto sia comunque HTTPS" interrompe il rinnovo per ogni applicazione che utilizza un backend Wildcard o DNS manuale. La validazione DNS richiede un token API con permessi di scrittura attivi; la rotazione o la restrizione di tale token interrompe il rinnovo in modo silenzioso fino all'arrivo dell'email di avviso.

La vista Domains dispone di un pulsante Renew All per forzare immediatamente il tentativo di rinnovo e di un provider Let's Encrypt Staging per i test. I certificati di staging non sono attendibili per i browser, ed è proprio questo lo scopo: è possibile effettuare tentativi ripetuti senza consumare i rate limit dell'ambiente di produzione.

È opportuno utilizzare il mail server integrato?

Cloudron include uno stack di posta completo con caselle IMAP, submission, filtri sieve e firma DKIM (domainkeys identified mail). È possibile abilitarlo per dominio nella sezione Email della dashboard. La parte complessa è garantire la consegna della posta, e tale difficoltà non dipende da Cloudron.

• La porta 25 in uscita è bloccata dalla maggior parte dei provider VPS come misura anti-spam. Alcuni la sbloccano dopo l'apertura di un ticket di supporto. Eseguire un test dal server con nc -zv aspmx.l.google.com 25 (installare netcat-openbsd se il comando non è presente). Le porte aperte restituiscono succeeded, mentre una porta bloccata rimane in attesa fino al timeout.
• Il record PTR (reverse DNS) viene impostato dal provider VPS, non dall'host DNS, e deve corrispondere all'hostname del mail server. La posta inviata da un indirizzo con un record PTR generico finisce nelle cartelle spam.
• I record SPF, DKIM e DMARC vengono generati automaticamente se si utilizza un backend DNS tramite API. Con i backend Wildcard o Manual è necessario aggiungerli manualmente; un record DKIM mancante rende impossibile verificare ogni messaggio firmato.

La configurazione ideale per la maggior parte degli utenti consiste nel ricevere la posta tramite Cloudron e inviarla attraverso un relay come SendGrid, Postmark, Mailgun o Amazon SES, configurato nella vista Email. Il relay deve consentire l'invio da qualsiasi indirizzo del proprio dominio, altrimenti le notifiche delle applicazioni provenienti da mittenti diversi verranno rifiutate. Se la posta è il motivo principale per cui si acquista il server, è preferibile utilizzare un mail server dedicato come Mailcow su una macchina separata con la propria reputazione IP.

Se non si utilizza affatto la funzione Email di Cloudron, bloccare le porte 25, 465, 587, 993 e 4190 nel firewall del provider. Eseguire questa operazione a livello di provider e non sul server, poiché Cloudron gestisce autonomamente le regole iptables e ne richiede il controllo esclusivo. Questo differisce da un normale VPS, dove le regole ufw vengono gestite autonomamente.

Configurare la destinazione di backup prima che sia necessario

I backup vengono salvati per impostazione predefinita sul filesystem locale in /var/backups, sullo stesso disco di tutto il resto. La documentazione è chiara al riguardo: "Avere i backup residenti sullo stesso disco fisico del server della piattaforma è pericoloso". Un singolo guasto al disco distrugge sia le applicazioni che i backup.

Apri Backups, poi Backup Sites, e punta la destinazione altrove fin dal primo giorno. Lo storage a oggetti compatibile con S3 è la soluzione standard (Backblaze B2, Wasabi, Cloudflare R2, DigitalOcean Spaces o un bucket MinIO su un secondo server), ma sono supportati anche SSHFS, NFS, CIFS e destinazioni su filesystem semplice.

Tre impostazioni determinano se il backup è affidabile:

• Formato. tgz scrive un archivio compresso per ogni applicazione e ricarica l'intero contenuto a ogni esecuzione. rsync carica solo i file modificati, il che è molto più economico per una grande istanza Nextcloud, al costo di un numero maggiore di richieste verso l'API di storage.
• Cifratura. AES-256 opzionale che copre sia il contenuto dei file che i nomi dei file. Cloudron non conserva una copia della password, quindi perderla significa che i backup non potranno essere decifrati da nessuno, nemmeno da te. Salvala in un password manager self-hosted prima di fare clic su salva.
• Conservazione. Definita tramite conteggi come 7 giornalieri e 4 settimanali. Una conservazione prolungata sullo storage a oggetti comporta costi mensili, quindi scegli un numero che sei disposto a mantenere nel tempo.

Successivamente, esegui un test di ripristino. Installa una piccola applicazione, ripristinala dalla dashboard e verifica che i dati siano tornati correttamente. Un backup che non è mai stato ripristinato è solo una supposizione.

Limiti del piano gratuito

A partire da agosto 2026, il piano gratuito è limitato a due applicazioni installate. Tutte le altre funzionalità sono incluse: aggiornamenti delle app, backup per singola app, firewall, mail server e single sign-on. La terza applicazione richiede una licenza. I piani a pagamento rimuovono il limite sulle app e, nel livello superiore, aggiungono gruppi e ruoli utente, un directory server e siti di backup multipli. I prezzi variano, quindi consulta la pagina dei prezzi di Cloudron invece di fare riferimento a cifre riportate in un tutorial.

Una licenza copre una singola installazione di Cloudron; di conseguenza, due server piccoli costano il doppio di un unico server più grande. Questa struttura di prezzo spinge la maggior parte degli utenti verso un singolo VPS più capiente, il che contrasta con il consiglio comune di distribuire i servizi su più macchine. Dimensiona il server tenendo a mente questo aspetto, poiché suddividere le risorse in un secondo momento comporta un costo doppio.

Quando qualcosa si rompe

Inizia con il controllo integrato. Questo esegue una scansione di DNS, certificati, disco, memoria e di ogni singolo servizio, indicando quale test non è stato superato:

sudo cloudron-support --troubleshoot

Successivamente, utilizza i comuni strumenti di systemd (gestore di sistema e servizi). systemctl status box riporta lo stato del servizio Cloudron, journalctl -u box -n 100 fornisce i log recenti e journalctl -u docker analizza il runtime dei container sottostante. Eventuali errori verificatisi durante l'installazione sono riportati in /var/log/cloudron-setup.log.

Se la dashboard non viene caricata, il problema è solitamente legato al DNS o al firewall del provider, piuttosto che a Cloudron. Esegui dig +short my.example.com dal tuo computer portatile e verifica che le porte 80 e 443 siano aperte nel firewall di rete del provider, che è un controllo distinto dalle regole interne del server. Se stai ricominciando da capo, lo script rifiuterà una seconda esecuzione con Error: Cloudron is already installed. To reinstall, start afresh; la soluzione corretta in questo caso è ricostruire il server da zero.

Quando Cloudron non è la soluzione adatta

Cloudron è indicato quando si desidera gestire applicazioni e non infrastruttura. È una scelta poco adatta se si intende eseguire i propri container in modo personalizzato, poiché il sistema gestisce autonomamente nginx, Docker e il firewall, sovrascrivendo qualsiasi modifica manuale. Se il proprio obiettivo è utilizzare una cartella di file compose, Traefik davanti ai propri stack Docker Compose offre la stessa gestione automatica di TLS e routing dei sottodomini senza dover installare una piattaforma sovrastante. Se non è stata ancora presa una decisione, Confronto tra Cloudron, CasaOS e Coolify mette a confronto queste soluzioni, mentre l'elenco completo delle applicazioni self-hosted rappresenta un punto di partenza migliore rispetto a una guida all'installazione.

FAQ

Quanta RAM richiede Cloudron su un VPS?

Lo script di installazione non viene eseguito con meno di 941 MB e la documentazione richiede 2 GB, ma questo è il requisito minimo per la piattaforma senza alcuna applicazione installata. Cloudron esegue Docker, nginx, il proprio servizio box, i container del database e lo stack di posta fin dal primo avvio. Prevedi 4 GB per due applicazioni e 16 GB per circa dieci, aggiungendo inoltre un file di swap; Cloudron concede alle applicazioni swap illimitato e un server privo di esso trasforma la pressione sulla memoria in riavvii dei processi.

Posso installare Cloudron su Debian o su un server che esegue già Docker?

Nessuna delle due opzioni è supportata. Lo script verifica la release e si interrompe con Cloudron requires Ubuntu 20.04, 22.04, 24.04, pertanto Debian, Rocky e Alpine sono esclusi. Si interrompe anche quando nginx, docker o node sono già presenti, poiché installa versioni specifiche di ciascuno di essi e gestisce autonomamente la configurazione di nginx e le regole di iptables. Parti da un'immagine Ubuntu pulita su un VPS KVM.

Perché i sottodomini delle mie applicazioni non funzionano mentre la dashboard sì?

Manca il record DNS wildcard. L'installazione crea o richiede un record A per my.example.com, quindi la dashboard viene risolta, mentre wiki.example.com restituisce NXDOMAIN e il browser segnala che il sito non è raggiungibile. Aggiungi un record A per *.example.com che punti all'indirizzo IP del server, quindi verifica con dig +short wiki.example.com prima di installare l'applicazione.

Devo utilizzare il server di posta di Cloudron?

No. Puoi disattivare la ricezione delle email e inviare tramite un relay esterno come Postmark, Mailgun o Amazon SES; questa è la scelta più sicura quando il tuo provider blocca la porta 25 in uscita o l'indirizzo IP non ha una buona reputazione per l'invio di posta. Se non utilizzi affatto Cloudron Email, chiudi le porte 25, 465, 587, 993 e 4190 nel firewall del provider invece che sul server.

Cosa succede quando raggiungo il limite di due applicazioni nel piano gratuito?

La dashboard blocca la terza installazione e richiede una chiave di licenza. Le applicazioni già in esecuzione rimangono invariate: continuano ad aggiornarsi, a essere sottoposte a backup e a mantenere i propri certificati. L'aggiunta di una licenza rimuove il limite senza dover reinstallare nulla, rendendo il piano gratuito un metodo valido per testare la piattaforma su un dominio reale.