Cloudron vs CasaOS vs Coolify su VPS

Cosa stai costruendo

Scegliere uno strumento è importante quanto l'installazione stessa. Tre pannelli promettono di trasformare un VPS vuoto in un host di applicazioni basato su interfaccia grafica: Cloudron, CasaOS e Coolify. Questa guida installa ciascuno di essi su una nuova istanza Ubuntu 24.04, installa una prima applicazione e analizza i dettagli tecnici spesso trascurati: TLS, backup, aggiornamenti, consumo di memoria e difficoltà di migrazione. Alla fine saprai quale scegliere, o se la risposta corretta sia "nessuno di questi, usa Docker Compose".

Nessuno di questi strumenti è magico. Sotto tutti e tre opera lo stesso Docker Engine che potresti gestire manualmente. Un pannello ti offre, in termini di costi, RAM o lock-in, quattro funzioni automatizzate: installazione app con un click, certificati TLS automatici, backup pianificati e gestione utenti. Se queste quattro funzioni giustificano l'overhead per le tue esigenze, il pannello è una scelta valida. Se gestisci solo uno o due servizi e preferisci il controllo totale sul sistema, leggi prima la sezione "Salta tutti e tre" per evitare inutili complicazioni.

Prerequisiti condivisi e potenziali criticità

Tutti e tre i sistemi richiedono un VPS KVM, non una virtualizzazione basata su container. Docker richiede un kernel reale; Cloudron non supporta OpenVZ e LXC. Verifica con systemd-detect-virt: kvm o qemu sono validi, openvz o lxc non lo sono. Su un piano KVM il comando restituisce kvm, mentre su bare metal restituisce none; in entrambi i casi puoi procedere.

Oltre questo punto, i requisiti variano, e questo è il primo fattore per la scelta.

• RAM. CasaOS funziona correttamente con 1GB; è ottimizzato per l'hardware Raspberry Pi e rimane leggero. Coolify richiede un minimo di 2GB e due core CPU; circa 600 MB sono occupati da Coolify stesso. Cloudron richiede un minimo di 2GB e le prestazioni migliorano con 4GB, poiché esegue un server mail e un database prima ancora di installare qualsiasi app.
• Un dominio e un DNS sotto il tuo controllo. Sia Cloudron che Coolify richiedono un dominio reale con DNS funzionanti. Cloudron richiede idealmente l'accesso API al tuo provider DNS per creare autonomamente record e certificati wildcard. CasaOS può funzionare solo con un indirizzo IP, ma in questo caso non avrai il protocollo TLS.
• Porte. Tutti e tre i sistemi richiedono le porte 80 e 443 aperte per HTTP e HTTPS. Coolify utilizza inoltre la porta 8000 per la dashboard, la 6001 per il canale realtime e la 6002 per il terminale nel browser. Mantieni la porta 22 aperta per SSH su tutti i sistemi.

Configura il DNS verso il server prima di iniziare. Un pannello che non riesce a risolvere il proprio hostname non può richiedere certificati; passerai la prima ora a fare debugging invece di usare il software. Punta un record A verso l'IP del server e, per Coolify, aggiungi un record wildcard (*.apps.example.com) in modo che ogni app distribuita abbia il proprio sottodominio.

Cloudron: l'appliance rifinita e strutturata

Cos'è. Cloudron è una piattaforma commerciale che trasforma un intero server in un'appliance gestita. Esegue il proprio reverse proxy, database e stack mail, oltre a un App Store curato con app pre-impacchettate (Nextcloud, WordPress, Gitea, Mattermost e altro). Si rivolge a utenti che desiderano app gestite, con aggiornamenti, certificati e backup automatici, e disposti a pagare per questo servizio.

Installazione. Richiede un sistema pulito e ne assume il controllo completo. Eseguire questo comando su un server Ubuntu 24.04 (Noble) appena installato e nient'altro:

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

Lo script installa Docker, nginx, un database e lo stack mail, quindi riavvia il sistema. Al riavvio, aprire https://<your-ip>, accettare il certificato self-signed temporaneo e completare la configurazione nel browser: impostare il proprio dominio, scegliere il provider DNS e il sistema creerà la propria dashboard a my.example.com.

Aggiunta della prima app. Nella dashboard, aprire l'App Store, cliccare su (ad esempio) Nextcloud, scegliere il sottodominio files.example.com e premere Install. Cloudron crea il record DNS, richiede il certificato Let's Encrypt, prepara il database, configura il single sign-on e pianifica il backup, senza che sia necessario modificare alcun file di configurazione. Questo è il valore principale del prodotto, e Cloudron lo garantisce.

TLS e backup. La funzione più robusta delle tre. Ogni sottodominio delle app riceve un certificato Let's Encrypt automatico, rinnovato automaticamente. I backup sono pianificati e integrati; possono essere salvati in una directory locale, su S3 o altri storage remoti. È possibile ripristinare ogni singola app o clonare un'app su un nuovo sottodominio con un solo clic.

Costi e licenze, leggere prima di procedere. Cloudron è un prodotto a pagamento con un piano gratuito limitato: il piano gratuito permette di installare due app. L'installazione di una terza app richiede un abbonamento; i piani a pagamento (Pro o Max, con fatturazione mensile o annuale, entrambi con app illimitate) sbloccano funzionalità aggiuntive. Questo è il dettaglio più importante su Cloudron. Il prodotto è rifinito perché è un modello di business; il piano gratuito è più simile a una prova estesa che a una soluzione per stack in crescita.

Modalità di errore, la regola del sistema pulito. Se si tenta di installare Cloudron su un server che esegue già altri servizi, 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 it's installation.
Please start with a fresh Ubuntu install and run this script again.

La causa non è un'eccessiva rigidità. Cloudron utilizza versioni specifiche di nginx, Docker e Node e le integra profondamente; pertanto, non può coesistere con altre installazioni presenti. La soluzione è utilizzare un'immagine Ubuntu 24.04 pulita e nient'altro: nessun web server, nessun Docker, nemmeno un firewall configurato manualmente. Se si utilizza l'immagine errata, l'installazione rifiuta qualsiasi sistema che non sia una versione Ubuntu LTS supportata (22.04 o 24.04) su architettura x86-64; ARM, LXC e OpenVZ non sono supportati.

Seconda modalità di errore, i certificati wildcard richiedono l'API DNS. Se durante la configurazione si sceglie l'opzione DNS "Manual" invece di fornire un token API a Cloudron, il sistema non può creare record o certificati wildcard. Per ogni nuova app, sarà necessario aggiungere manualmente un record DNS prima che il certificato possa essere emesso, e la dashboard rimarrà in attesa di tale record. Fornendo a Cloudron l'accesso API a un provider DNS supportato (Cloudflare, Route 53, DigitalOcean e altri), l'intero processo diventa immediato con un solo clic.

CasaOS: la dashboard gratuita per il home-lab

Cos'è. CasaOS, sviluppato da IceWhale, è una dashboard gratuita e open-source che opera sopra Docker. Fornisce una home screen, un app store e un file manager. È progettata per il mondo dei server domestici: configurazione rapida, interfaccia utente intuitiva e minima complessità. È pensata per gli utenti che desiderano un'interfaccia grafica per Docker senza costi di licenza.

Installazione. Basta una riga di comando e non richiede un sistema operativo pulito:

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

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

systemctl status casaos-gateway

Quando è attivo, la dashboard è disponibile su http://<your-ip> (HTTP semplice, porta 80). Creare un account locale per accedere.

Aggiunta della prima app. Aprire l'App Store, selezionare un'app e cliccare su Install. CasaOS crea un progetto Docker Compose in background e espone l'app su una porta host, ad esempio http://<your-ip>:8080. Il suo store include i software standard per i server domestici; ad esempio, un media server Jellyfin su un VPS o una libreria fotografica Immich self-hosted sono raggiungibili con pochi clic. È possibile importare qualsiasi docker-compose.yaml, che rappresenta il vero punto di forza: le app sono container standard, non un formato proprietario.

TLS e backup, i punti deboli. Qui si nota il limite del software "free". CasaOS serve tutto tramite HTTP semplice di default, inclusa la sua dashboard. Non sono inclusi Let's Encrypt né backup pianificati integrati. I dati risiedono nei volumi Docker sotto /DATA; il backup è a carico dell'utente (tramite un restic o tar pianificato con cron).

Modalità di errore: assenza di TLS e silenziosità. Non vengono generati errori. Si installa un'app, si apre http://<your-ip>:8080 e il servizio funziona, ma su una connessione non criptata che il browser segnalerà come "Non sicuro". Le password e i cookie di sessione viaggiano in chiaro sulla rete. Inoltre, CasaOS ha presentato vulnerabilità di remote-code-execution nella dashboard (CVE-2023-37265 e CVE-2023-37266, un bypass di autenticazione che permetteva il compromesso totale dell'host); pertanto, esporre la porta HTTP direttamente su internet è un rischio reale. La soluzione è non esporre mai CasaOS direttamente. Utilizzare un reverse proxy che gestisca il TLS, come nginx con certificato Let's Encrypt da Certbot, Caddy o un Cloudflare Tunnel, e inoltrare il traffico a CasaOS solo sulla rete locale. Nota: CasaOS occupa già la porta 80, quindi il proxy e CasaOS entreranno in conflitto a meno di spostare CasaOS su un'altra porta.

Costo. Completamente gratuito, senza limiti di app. Il costo è operativo: la gestione di TLS, backup e hardening è a carico dell'utente.

Coolify: il PaaS self-hosted

Cos'è. Coolify è una piattaforma-as-a-service open-source e self-hosted, simile a Heroku o Vercel ma gestita sul proprio server. Il suo modello operativo non è "installa questa app pacchettizzata" ma "deploya questo repository Git": connetti un repo, Coolify lo builda (tramite Nixpacks o il proprio Dockerfile) e lo distribuisce, effettuando il redeploy a ogni push. Include anche database e servizi con installazione in un click. È pensato per gli sviluppatori che deployano il proprio codice e desiderano il push-to-deploy senza noleggiare 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. Verifica che siano in stato healthy prima di procedere:

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

Dovresti vedere coolify, coolify-db, coolify-redis, coolify-realtime e coolify-proxy tutti con stato Up. La dashboard è disponibile all'indirizzo http://<your-ip>:8000. Crea immediatamente il tuo account admin, poiché la pagina di registrazione rimane aperta fino alla creazione del primo account; chiunque la raggiunga per primo otterrà il controllo del server. Successivamente, imposta il dominio dell'istanza e punta un record DNS wildcard (*.example.com o *.apps.example.com) verso il server, in modo che Coolify possa assegnare a ogni app deployata il proprio sottodominio.

Aggiunta di una prima app. Connetti una sorgente Git (GitHub, GitLab o un URL di un repository), seleziona un branch, imposta il dominio e avvia il deploy. Il proxy Traefik integrato in Coolify gestisce il routing del sottodominio e richiede il certificato. Per il software standard, il catalogo Services permette il deploy con pochi click: lo stesso stack per l'automazione del workflow n8n che altrimenti dovresti configurare manualmente è una singola voce, così come Uptime Kuma per il monitoraggio delle status-page.

TLS e backup. Let's Encrypt è automatico per ogni app tramite il bundle Traefik, quindi ogni sottodominio deployato riceve un certificato. I backup sono focalizzati sui database: è possibile pianificare dump di Postgres e MySQL su storage compatibile con S3. Il backup dell'intera istanza (la configurazione di Coolify stessa, che si trova sotto /data/coolify) è più manuale; pertanto, esporta e conserva i dati autonomamente.

Costi e licenza. L'edizione self-hosted è completamente open-source e gratuita, senza limiti di app. Esiste un'opzione Coolify Cloud (a pagamento) che ospita il control plane per tuo conto mentre le tue app continuano a girare sui tuoi server; è una soluzione comoda ma non obbligatoria.

Errore: l'app viene deployata ma il dominio non carica. La dashboard funziona correttamente su http://<ip>:8000, il build risulta completato con successo, ma l'URL dell'app restituisce un errore di connessione o un errore Traefik 404 page not found. Il problema riguarda il proxy o il DNS, non l'app. Le cause comuni sono due. Primo, le porte 80 o 443 erano già occupate quando il proxy ha tentato l'avvio, quindi il suo container è crashato 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, manca il record DNS wildcard, quindi Traefik non riceve mai una richiesta per quell'hostname. Se invece la scheda del server in Coolify riporta "Server is not reachable,", si tratta di un errore diverso: Coolify non riesce a comunicare con il Docker socket del server, solitamente a causa di un daemon Docker fermo o di una chiave SSH non valida. Verifica la causa esatta nei log prima di procedere con ipotesi:

docker logs coolify-proxy --tail 100

Risolvi dalla pagina Proxy: clicca su Restart Proxy, oppure resetta la configurazione del proxy ai valori predefiniti e riavvialo, quindi attendi circa due minuti per il completamento dell'avvio. Mantieni la porta 8000 raggiungibile solo dal tuo IP (o riaprila temporaneamente se il proxy presenta problemi) invece di lasciarla aperta a tutti — la porta serve la dashboard tramite HTTP semplice, e la documentazione ufficiale di Coolify indica che le porte 8000, 6001 e 6002 possono essere chiuse una volta che la dashboard è servita tramite il proprio dominio.

Overhead delle risorse sullo stesso VPS

Misurato in stato di idle su una macchina da 4GB, prima di distribuire qualsiasi carico di lavoro reale. Controlla i tuoi valori con free -m e docker stats --no-stream invece di affidarti a un singolo numero, poiché il totale varia in base alla combinazione di app utilizzate.

• CasaOS è il più leggero. Il pannello è un piccolo insieme di servizi Go; considera un overhead di circa 150-300 MB oltre ai container in esecuzione.
• Coolify esegue diversi container di supporto propri (l'app, un Postgres, un Redis, un servizio realtime e Traefik), quindi si attesta tra 600 MB e 1 GB in idle prima di qualsiasi distribuzione.
• Cloudron è il più pesante a riposo, poiché esegue il proprio nginx, database, stack mail e monitoraggio indipendentemente dal loro utilizzo; prevedi 1-1.5 GB in idle. Per questo motivo richiede un minimo di 2GB e funziona meglio con 4GB.

Su un piccolo VPS da 2GB, CasaOS lascia più spazio alle app reali e Cloudron lascia meno spazio. Se il tuo piano è da 2GB e desideri utilizzare Cloudron con il relativo mail server attivo, pianifica un upgrade della macchina.

Confronto tra aggiornamenti, backup e lock-in

Aggiornamenti. Cloudron aggiorna la piattaforma e ogni app secondo un programma di test predefinito: richiede il minimo sforzo e la massima assistenza. Coolify si aggiorna tramite la propria dashboard con un singolo tasto. CasaOS aggiorna il pannello tramite il proprio script di installazione o apt, ma la gestione degli aggiornamenti delle app installate è a carico dell'utente tramite pull e restart.

Lock-in, il problema critico dopo il secondo anno. CasaOS presenta il minor lock-in: le sue app sono comuni progetti Compose, quindi è possibile copiare il docker-compose.yaml e i volumi sotto /DATA su qualsiasi altro host per continuare l'operazione. Coolify si posiziona a metà: i deploy utilizzano Dockerfile e repository proprietari, ma la configurazione è salvata nel database di Coolify; spostare l'host richiede quindi la ricreazione dei progetti sul nuovo sistema. Cloudron presenta il maggior lock-in: le app sono pacchettizzate da Cloudron; sebbene i dati possano essere esportati tramite i suoi backup, il pacchetto software non è portabile, rendendo necessario il re-deploy sulla piattaforma di destinazione. I dati sono portatili, l'infrastruttura no.

Quale scegliere

Versione breve, poi l'uscita. Scegli Cloudron se desideri il server con meno gestione manuale tra i tre, se devi eseguire diverse app pre-confezionate e se sei disposto a pagare un canone annuale per TLS, backup e aggiornamenti gestiti. Scegli CasaOS se si tratta di un home lab dietro la propria rete o un reverse proxy, se desideri un'interfaccia amichevole per Docker e se non vuoi pagare nulla. Scegli Coolify se distribuisci il tuo codice da Git e desideri il push-to-deploy con TLS automatico, senza il costo di un PaaS ospitato. Se nessuna di queste tre opzioni ti rappresenta, la sezione successiva contiene la risposta onesta.

Salta tutti e tre se...

Sii onesto riguardo alla tua scala. Se gestisci solo una o due app, o se vuoi capire e controllare esattamente cosa è installato sul tuo server, salta i pannelli. L'overhead e il lock-in non sono giustificati per uno stack piccolo e stabile. L'approccio DIY consiste nell'usare un reverse proxy davanti ai propri file Compose: Traefik con TLS automatico davanti a diverse app Docker Compose fornisce un equivalente dell'HTTPS con un solo clic senza il peso dei pannelli, e puoi eseguire il backup con un job restic pianificato tramite cron che puoi comprendere appieno.

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 app principale il caso è ancora più chiaro: una installazione di Nextcloud su Docker con TLS e routine di backup dedicata richiede un solo file Compose e un certificato. Configurare un intero appliance per eseguirla comporterebbe costi elevati senza benefici reali. Se stai ancora decidendo cosa eseguire prima di decidere come, la guida a cosa vale la pena auto-ospitare nel 2026 è il punto di partenza migliore.

FAQ

È necessario un pannello di self-hosting?

Solo se sono necessari i quattro processi automatizzati da un pannello su diverse app: installazione con un click, TLS automatico, backup pianificati e gestione utenti. Per uno o due servizi, Docker Compose con Traefik gestisce il TLS con meno overhead e senza lock-in. I pannelli sono vantaggiosi se si gestiscono molte app e il tempo ha un valore superiore alla RAM consumata.

Qual è il miglior pannello per un principiante?

Per un home lab senza servizi esposti su internet, CasaOS è l'opzione più semplice: un solo comando e un'interfaccia utente intuitiva, senza costi. È necessario però configurare un reverse proxy con terminazione TLS prima di esporre qualsiasi servizio, poiché CasaOS utilizza HTTP semplice. Se si desidera la gestione automatica di TLS e backup e si è disposti a pagare, Cloudron offre il massimo supporto, entro il limite di due app della versione gratuita.

Cloudron è gratuito?

Parzialmente. Il piano gratuito permette due app, ideale per test o configurazioni molto piccole. Oltre questo limite, Cloudron richiede un abbonamento mensile o annuale con app illimitate nei piani a pagamento. È un prodotto commerciale con un piano gratuito limitato, non è software free, quindi prevedere il costo se il sistema crescerà.

Posso eseguire questi pannelli accanto alle mie app esistenti?

Cloudron: no. Richiede un sistema Ubuntu pulito e l'installazione si interrompe se nginx, Docker o Node sono già presenti, poiché il pannello gestisce l'intero sistema. CasaOS e Coolify sono più flessibili, poiché installano il proprio stack Docker e possono condividere una macchina, ma entrambi richiedono le porte 80 e 443; questo causa conflitti con qualsiasi web server o proxy già attivo. Su una macchina che ospita già altri servizi, un pannello non è lo strumento adatto; utilizzare invece Traefik e Compose.

Come posso abbandonare un pannello in futuro?

Pianificare l'uscita prima che diventi necessaria. Da CasaOS, copiare la docker-compose.yaml dell'app e i relativi volumi /DATA sul nuovo host e riavviarli. Da Coolify, esportare la configurazione di ogni progetto e puntarla agli stessi repository sulla destinazione. Da Cloudron, ripristinare i dati dai backup nelle app appena installate sulla nuova piattaforma, poiché il packaging di Cloudron non è trasferibile, solo i dati. In ogni caso, testare il ripristino su una macchina di prova prima di eliminare la vecchia.