Cloudron, CasaOS o Coolify: quale scegliere su VPS?

Cosa stai creando

Stai scegliendo uno strumento oltre a installarlo. Tre pannelli promettono di trasformare un VPS vuoto in un host per applicazioni gestibile con pochi clic: Cloudron, CasaOS e Coolify. Questa guida installa ciascuno sulla stessa macchina Ubuntu 24.04 appena predisposta, configura una prima applicazione e analizza gli aspetti che raramente compaiono negli screenshot: TLS, backup, aggiornamenti, consumo di memoria e difficoltà di migrazione. Al termine saprai quale soluzione è più adatta oppure se la risposta corretta è «nessuna delle tre: usa semplicemente Docker Compose».

Nessuna di queste soluzioni è magica. Alla base di tutte c'è lo stesso Docker Engine che potresti gestire manualmente. Ciò che un pannello ti offre, in cambio di denaro, memoria RAM o vincolo tecnologico, sono quattro attività gestite automaticamente: installazione delle applicazioni con un clic, certificati TLS automatici, backup pianificati e gestione degli utenti. Se queste quattro funzioni giustificano davvero il sovraccarico per il tuo ambiente, il pannello è una scelta utile. Se esegui uno o due servizi e vuoi sapere esattamente cosa è presente sul server, leggi prima la sezione "Ignora tutti e tre" e risparmiati il lavoro.

Prerequisiti comuni e problemi da considerare

Tutte e tre le soluzioni presuppongono una VPS KVM, non una virtualizzazione basata su container. Docker richiede un kernel reale e Cloudron rifiuta esplicitamente OpenVZ e LXC. Verifica con systemd-detect-virt: kvm o qemu indicano una configurazione compatibile, mentre openvz o lxc no. Su un piano KVM il comando restituisce kvm, mentre su un server bare metal restituisce none; in entrambi i casi puoi procedere.

Per il resto, i requisiti divergono. Questo è il primo elemento da valutare nella scelta.

• RAM. CasaOS funziona senza problemi con 1GB; è nato su hardware Raspberry Pi e mantiene consumi ridotti. Coolify richiede almeno 2GB e due core CPU, di cui circa 600 MB sono utilizzati da Coolify stesso. Cloudron richiede almeno 2GB e funziona realmente meglio con 4GB, perché esegue un server di posta e un database prima ancora di installare una singola applicazione.
• Un dominio e il controllo del DNS. Cloudron e Coolify richiedono entrambi un dominio reale con DNS funzionante. Idealmente, Cloudron richiede l'accesso API al provider DNS, così può creare autonomamente record e certificati wildcard. CasaOS funziona anche con un semplice indirizzo IP, ma in questo caso non avrai alcun TLS.
• Porte. Cloudron e Coolify richiedono che le porte 80 e 443 siano aperte per HTTP e HTTPS. CasaOS pubblica il dashboard tramite HTTP non cifrato, quindi richiede soltanto la porta 80. Coolify pubblica inoltre il dashboard sulla porta 8000 e usa la porta 6001 per il canale realtime e la porta 6002 per il terminale nel browser. Mantieni aperta la porta 22 per SSH su tutti e tre i sistemi.

Configura il DNS affinché punti al server prima di iniziare. Un pannello che non riesce a risolvere il proprio hostname non può richiedere un certificato e passerai la prima ora a eseguire il troubleshooting di questo problema invece di configurare il software. Crea un record A che punti all'indirizzo IP del server e, per Coolify, aggiungi un record wildcard (*.apps.example.com), così ogni applicazione distribuita riceverà il proprio sottodominio.

Cloudron: l'appliance completa e basata su scelte predefinite

Che cos'è. Cloudron è una piattaforma commerciale che trasforma un intero server in un'appliance gestita. Esegue il proprio reverse proxy, database e stack di posta, oltre a un App Store curato con applicazioni pacchettizzate (Nextcloud, WordPress, Gitea, Mattermost e altre). Si rivolge a chi vuole che le applicazioni siano gestite, con aggiornamenti automatici, certificati automatici e backup automatici, ed è disposto a pagare per questo.

Installazione. Richiede un sistema pulito e lo prende completamente in gestione. Eseguire questo comando su un server Ubuntu 24.04 (Noble) appena installato e non fare altro:

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

Lo script installa Docker, nginx, un database e lo stack di posta, quindi riavvia il server. Al termine del riavvio, aprire https://<your-ip>, accettare il certificato temporaneo autofirmato e completare la configurazione nel browser: indicare il proprio dominio, scegliere il provider DNS e Cloudron eseguirà il provisioning del proprio pannello di controllo in my.example.com.

Aggiunta della prima applicazione. Nel pannello di controllo, aprire l'App Store, fare clic, ad esempio, su Nextcloud, scegliere il sottodominio files.example.com e premere Install. Cloudron crea il record DNS, richiede il certificato Let's Encrypt, esegue il provisioning del database, configura il single sign-on e pianifica un backup, senza richiedere modifiche ai file di configurazione. Questo è il suo principale punto di forza e funziona.

TLS e backup. È la soluzione più completa delle tre. Ogni sottodominio delle applicazioni riceve automaticamente un certificato Let's Encrypt, che viene rinnovato automaticamente. I backup sono integrati e pianificabili verso una directory locale, S3 o un altro sistema di storage remoto, con ripristino per singola applicazione e perfino clonazione di un'applicazione su un nuovo sottodominio con un solo clic.

Costi e licenze: leggere prima di scegliere. Cloudron è un prodotto a pagamento con un piano gratuito limitato: il piano gratuito consente di eseguire due applicazioni. Installando una terza applicazione si raggiunge il limite che richiede un abbonamento; un abbonamento a pagamento (Pro o Max, fatturato mensilmente o annualmente, entrambi con applicazioni illimitate) sblocca funzionalità aggiuntive. Questo è il fatto più importante su Cloudron. È rifinito proprio perché è un'attività commerciale, e il piano gratuito assomiglia più a una versione di prova estesa che a una soluzione per uno stack destinato a crescere.

Modalità di errore, regola del sistema pulito. Se si tenta di installare Cloudron su un server che esegue già altri componenti, la configurazione si interrompe prima di apportare modifiche:

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 non è una semplice rigidità. Cloudron fissa versioni specifiche di nginx, Docker e Node e li integra in profondità, quindi non può coesistere con istanze installate autonomamente. La soluzione consiste nell'usare un'immagine Ubuntu 24.04 appena installata e nient'altro: nessun web server, nessun Docker e nemmeno un firewall configurato manualmente. Se è stata avviata l'immagine sbagliata, la configurazione rifiuta anche qualsiasi sistema che non sia una versione Ubuntu LTS supportata (22.04, 24.04 o 26.04) su x86-64; ARM, LXC e OpenVZ non sono supportati. A partire da Cloudron 10 (settembre 2026), Ubuntu 26.04 è l'impostazione predefinita per le nuove installazioni, quindi è l'immagine da scegliere se si parte oggi da zero.

Seconda modalità di errore, i certificati wildcard richiedono l'API DNS. Se durante la configurazione si sceglie l'opzione DNS "Manual" invece di fornire a Cloudron un token API, Cloudron non può creare i record o richiedere un certificato wildcard. Per ogni nuova applicazione è quindi necessario aggiungere manualmente un record DNS prima che il certificato possa essere emesso, mentre il pannello di controllo rimane in attesa di quel record. Concedendo a Cloudron l'accesso API a un provider DNS supportato (Cloudflare, Route 53, DigitalOcean e altri), l'intero flusso si riduce a un clic.

CasaOS: la dashboard gratuita per il laboratorio domestico

Che cos'è. CasaOS, sviluppata da IceWhale, è una dashboard gratuita e open source che si appoggia a Docker e offre una schermata iniziale, un app store e un file manager. Nasce dall'ambito dei server domestici, quindi è pensata per i laboratori domestici: configurazione rapida, interfaccia intuitiva e poca complessità operativa. Si rivolge agli utenti che vogliono un'interfaccia più curata per Docker senza dover sostenere costi.

Installazione. Basta una riga di comando e non è necessario partire da un sistema pulito:

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

L'installer aggiunge diversi servizi systemd (casaos, casaos-gateway, casaos-app-management e altri). Verifica che il gateway sia attivo prima di aprire un browser:

systemctl status casaos-gateway

Quando è in esecuzione, la dashboard è disponibile su http://<your-ip> (HTTP non cifrato, porta 80). Crea un account locale e puoi accedere.

Aggiunta della prima applicazione. Apri l'App Store, scegli un'applicazione e fai clic su Install. CasaOS crea in background un progetto Docker Compose ed espone l'applicazione su una porta dell'host, ad esempio http://<your-ip>:8080. Il catalogo include le applicazioni tipiche dei server domestici, quindi un media server Jellyfin su un VPS o una libreria fotografica Immich self-hosted sono disponibili con pochi clic. Se non hai ancora scelto un photo server, vale la pena leggere requisiti RAM e app per smartphone che distinguono PhotoPrism da Immich, perché su un sistema CasaOS con 1GB questa scelta determina se l'applicazione riuscirà a funzionare. Puoi anche importare qualsiasi docker-compose.yaml, ed è questo il vero punto di forza: le applicazioni sono normali container, non un formato proprietario.

TLS e backup, il punto debole. È qui che emergono i limiti della soluzione gratuita. Per impostazione predefinita, CasaOS serve tutto tramite HTTP non cifrato, inclusa la propria dashboard. Non include Let's Encrypt e non include backup pianificati. I dati risiedono nei volumi Docker sotto /DATA e il backup è a tuo carico (un restic o tar eseguito tramite cron).

Scenario di errore, senza TLS e senza avvisi. Non viene visualizzato alcun errore. Installi un'applicazione, apri http://<your-ip>:8080 e tutto funziona, ma tramite una connessione non cifrata che il browser indica come "Non sicura." Le password e i cookie di sessione attraversano la rete in chiaro. Inoltre, CasaOS ha avuto vulnerabilità reali di remote code execution nella dashboard (CVE-2023-37265 e CVE-2023-37266, un bypass dell'autenticazione che poteva portare alla compromissione completa dell'host), quindi esporre direttamente su Internet quella porta HTTP è un rischio concreto, non una semplice questione stilistica. La soluzione consiste nel non esporre mai direttamente CasaOS. Usa un reverse proxy davanti a CasaOS per terminare TLS, ad esempio nginx con un certificato Let's Encrypt ottenuto tramite Certbot, Caddy o un Cloudflare Tunnel, e inoltra le richieste a CasaOS soltanto sulla rete locale. Tieni presente che CasaOS usa già la porta 80, quindi il proxy e CasaOS entreranno in conflitto se prima non sposti CasaOS su un'altra porta.

Costo. È realmente gratuito, per sempre e senza limiti sul numero di app. Il costo è operativo: TLS, backup e hardening sono a tuo carico.

Coolify: il PaaS self-hosted

Che cos'è. Coolify è una piattaforma open source self-hosted come servizio, simile a Heroku o Vercel ma eseguita sul proprio server. La sua unità nativa non è “installare questa applicazione pacchettizzata”, ma “distribuire questo repository Git”: si collega un repository e Coolify lo compila, tramite Nixpacks o un proprio Dockerfile, quindi lo distribuisce nuovamente a ogni push. Sono disponibili anche database e servizi installabili con un clic. È pensato per gli sviluppatori che distribuiscono il proprio codice e vogliono il deploy tramite push senza affittare un PaaS.

Installazione.

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

Lo script installa Docker e avvia lo stack di container di Coolify. Verificare che siano in buone condizioni prima di procedere:

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

Dovrebbero risultare tutti in stato Up: coolify, coolify-db, coolify-redis, coolify-realtime e coolify-proxy. La dashboard è disponibile all'indirizzo http://<your-ip>:8000. Creare immediatamente l'account amministratore, perché la pagina di registrazione resta aperta fino alla creazione del primo account e chiunque la raggiunga per primo può controllare il server. Impostare quindi il dominio dell'istanza e puntare al server un record DNS wildcard (*.example.com o *.apps.example.com), così Coolify può assegnare a ogni applicazione distribuita il proprio sottodominio.

Aggiunta della prima applicazione. Collegare una sorgente Git (GitHub, GitLab o un semplice URL del repository), selezionare un branch, impostare il dominio e avviare il deploy. Il proxy Traefik integrato in Coolify instrada il sottodominio e richiede il certificato. Per il software pronto all'uso, il catalogo Services consente di distribuire i componenti con pochi clic: lo stesso stack n8n per l'automazione dei workflow che altrimenti si dovrebbe configurare manualmente è una voce del catalogo, così come Uptime Kuma per il monitoraggio delle pagine di stato.

TLS e backup. Coolify gestisce certificati Let's Encrypt automatici per ogni applicazione tramite Traefik, quindi ogni sottodominio distribuito riceve un certificato. I backup sono incentrati sui database: è possibile pianificare dump di Postgres e MySQL su uno storage compatibile con S3. Il backup dell'intera istanza, cioè della configurazione di Coolify che risiede in /data/coolify, richiede più interventi manuali; esportarla e conservarla autonomamente.

Costi e licenza. L'edizione self-hosted è completamente open source e gratuita, senza limiti sul numero di applicazioni. È disponibile anche Coolify Cloud (a pagamento), che ospita il control plane mentre le applicazioni continuano a essere eseguite sui propri server. È una soluzione comoda, ma non necessaria.

Scenario di errore: il deploy dell'applicazione riesce, ma il dominio non viene caricato. La dashboard funziona correttamente su http://<ip>:8000, la compilazione termina con esito positivo, ma l'URL dell'applicazione restituisce un errore di connessione o un errore 404 page not found di Traefik. Il problema riguarda il proxy o il DNS, non l'applicazione. Le cause comuni sono due. Primo, le porte 80 o 443 erano già occupate quando il proxy ha tentato di avviarsi; il relativo container si è quindi arrestato con un errore 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

Secondo, il nome host non viene risolto verso il server. L'applicazione può usare un sottodominio generato tramite wildcard senza che esista il relativo record DNS wildcard, oppure può usare un dominio personalizzato privo di un proprio record DNS puntato al server. In entrambi i casi Traefik non riceve richieste per quel nome host. Se invece l'intera scheda del server in Coolify mostra "Server is not reachable", si tratta di un problema diverso: Coolify non riesce a comunicare con il socket Docker del server, in genere perché il daemon Docker è arrestato o perché la chiave SSH non funziona. Consultare i log per individuare la causa effettiva prima di formulare ipotesi:

docker logs coolify-proxy --tail 100

Correggere il problema dalla pagina Proxy: premere Restart Proxy oppure ripristinare la configurazione predefinita del proxy e avviarlo nuovamente, quindi attendere circa due minuti perché completi l'avvio. Rendere la porta 8000 raggiungibile soltanto dal proprio indirizzo IP, oppure riaprirla temporaneamente quando il proxy presenta problemi, invece di lasciarla esposta a Internet. La porta serve la dashboard tramite HTTP non cifrato e la documentazione di Coolify specifica che le porte 8000, 6001 e 6002 possono essere chiuse quando la dashboard viene pubblicata tramite il proprio dominio.

Overhead delle risorse sullo stesso VPS

Misurato in condizioni di inattività sullo stesso server da 4GB, prima di distribuire un carico reale. Verifica il tuo ambiente con free -m e docker stats --no-stream invece di affidarti a un singolo valore, perché il totale varia in base alla combinazione di applicazioni.

• CasaOS è la soluzione più leggera. Il pannello è composto da un numero ridotto di servizi Go; considera un overhead di circa 150-300 MB, oltre alla memoria utilizzata dai container in esecuzione.
• Coolify esegue diversi container di supporto propri (l'applicazione, un database Postgres, Redis, un servizio realtime e Traefik), quindi in condizioni di inattività utilizza circa 600 MB-1 GB prima della distribuzione di qualsiasi applicazione.
• Cloudron è la soluzione che utilizza più risorse quando è inattiva, perché esegue il proprio nginx, database, stack di posta e sistema di monitoraggio indipendentemente dal loro utilizzo; considera 1-1,5 GB in condizioni di inattività. Per questo richiede almeno 2GB e funziona meglio con 4GB.

Su un VPS piccolo da 2GB, CasaOS lascia più risorse disponibili per le applicazioni reali, mentre Cloudron ne lascia meno. Se il tuo piano prevede 2GB e vuoi eseguire Cloudron con il relativo server di posta, prevedi di aumentare le risorse del server.

Aggiornamenti, backup e vincolo alla piattaforma a confronto

Aggiornamenti. Cloudron aggiorna la piattaforma e tutte le applicazioni secondo una pianificazione verificata dal team: richiede il minimo sforzo e offre la maggiore automazione. Coolify si aggiorna dal proprio pannello con un solo pulsante. CasaOS aggiorna il pannello tramite lo script di installazione o apt, ma devi occuparti personalmente di recuperare e riavviare le applicazioni installate.

Vincolo alla piattaforma: il problema che emerge nel secondo anno. CasaOS presenta il vincolo minore: le sue applicazioni sono normali progetti Compose, quindi puoi copiare docker-compose.yaml e i volumi contenuti in /DATA su qualsiasi altro host e continuare a utilizzarli. Coolify si colloca nel mezzo: i deployment sono basati sui tuoi Dockerfile e repository, ma la relativa configurazione risiede nel database di Coolify. Per cambiare host devi quindi ricreare i progetti sul nuovo sistema. Cloudron presenta il vincolo maggiore: le applicazioni sono pacchetti Cloudron e, sebbene i dati possano essere trasferiti senza problemi tramite il suo eccellente sistema di backup, il sistema di packaging no. Devi quindi eseguire nuovamente il deployment sulla piattaforma di destinazione. Dati portabili, componenti di gestione non portabili.

Quale scegliere

In breve, con una possibilità alternativa. Scegli Cloudron se vuoi che il server richieda il minor intervento possibile tra le tre opzioni, intendi eseguire diverse applicazioni distribuite come pacchetti e accetti di pagare un canone annuale per TLS gestito, backup e aggiornamenti. Scegli CasaOS se si tratta di un home lab nella tua rete o dietro un reverse proxy, vuoi un'interfaccia semplice per Docker e non vuoi pagare nulla. Scegli Coolify se distribuisci il tuo codice da Git e vuoi il deployment tramite push con TLS automatico, senza sostenere il costo di una PaaS hosted. Se nessuna di queste tre opzioni fa al caso tuo, la sezione successiva fornisce la risposta più onesta.

Salta tutte e tre se...

Sii realistico riguardo alle tue dimensioni. Se esegui solo una o due applicazioni, oppure vuoi capire e controllare esattamente cosa è presente sul server, salta i pannelli. Per uno stack piccolo e stabile, il sovraccarico e il vincolo rispetto alla piattaforma non valgono la pena. Il percorso fai-da-te consiste nell'usare un reverse proxy davanti ai tuoi file Compose: Traefik con TLS automatico davanti a diverse applicazioni Docker Compose offre un HTTPS equivalente a quello configurato con un clic, senza il peso del pannello, e puoi eseguire il backup con un job cron basato su restic che comprendi realmente.

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

Per una singola applicazione principale, il caso è ancora più evidente: una installazione di Nextcloud su Docker con TLS e una propria procedura di backup richiede un file Compose e un certificato. Configurare un'appliance completa solo per eseguirla comporterebbe soltanto costi, senza vantaggi. Se stai ancora decidendo cosa eseguire prima di decidere come, la guida a ciò che vale la pena eseguire in self-hosting nel 2026 è il punto di partenza migliore.

FAQ

Mi serve davvero un pannello per il self-hosting?

Solo se, per diverse applicazioni, vuoi automatizzare i quattro aspetti che un pannello gestisce: installazioni con un clic, TLS automatico, backup pianificati e gestione degli utenti. Per uno o due servizi, Docker Compose configurato dietro Traefik svolge lo stesso lavoro per TLS, con un sovraccarico molto inferiore e senza vincoli verso un fornitore. I pannelli sono convenienti quando esegui molte applicazioni e il tuo tempo vale più della RAM che consumano.

Qual è il pannello migliore per un principiante?

Per un laboratorio domestico in cui nulla è esposto a Internet non affidabile, CasaOS è il punto di partenza più semplice: basta un comando e offre un'interfaccia intuitiva, senza costi. Prima di esporre qualsiasi servizio, però, devi mettere davanti un reverse proxy con terminazione TLS, perché CasaOS utilizza HTTP in chiaro. Se vuoi che TLS e backup siano gestiti automaticamente e sei disposto a pagare, Cloudron offre la maggiore assistenza, entro il limite gratuito di due applicazioni.

Cloudron è gratuito?

Solo in parte. Il piano gratuito consente di eseguire due applicazioni, una soluzione adatta per provarlo o per una configurazione molto piccola. Oltre questo limite, Cloudron è un abbonamento a pagamento, con fatturazione mensile o annuale; i piani a pagamento consentono di eseguire applicazioni illimitate. È un prodotto commerciale con un piano gratuito limitato, non software libero, quindi devi prevederne il costo se il tuo stack crescerà.

Posso eseguire questi pannelli insieme alle applicazioni che ho già installato?

Cloudron: no. Richiede un sistema Ubuntu pulito e interrompe l'installazione se nginx, Docker o Node sono già presenti, perché gestisce l'intera macchina. CasaOS e Coolify sono più flessibili, perché installano il proprio stack Docker e, in linea di principio, possono condividere un server. CasaOS, però, richiede la porta 80 per il dashboard, mentre il proxy di Coolify richiede sia la porta 80 sia la 443. Di conseguenza, ciascuno entra in conflitto con un web server o un proxy che utilizza già quelle porte. Su un server che ospita già altri servizi, in genere un pannello non è lo strumento adatto: usa invece Traefik e Compose.

Come posso abbandonare un pannello in seguito?

Pianifica la migrazione prima di averne bisogno. Da CasaOS, copia docker-compose.yaml dell'applicazione e i relativi volumi /DATA sul nuovo host, quindi riavviali. Da Coolify, esporta la configurazione di ogni progetto e collegala agli stessi repository sulla destinazione. Da Cloudron, ripristina i dati dai suoi backup in applicazioni installate da zero sulla nuova piattaforma, perché il packaging di Cloudron non è trasferibile: vengono trasferiti solo i dati. In ogni caso, verifica il ripristino su un server temporaneo prima di dismettere quello vecchio.