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 aspetti da considerare

Tutte e tre le soluzioni presuppongono un 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 corretta, mentre openvz o lxc indicano una configurazione non supportata. Su un piano KVM il comando restituisce kvm, mentre su un server bare metal restituisce none; in entrambi i casi puoi continuare.

Per il resto, i requisiti divergono. Questo è il primo aspetto che orienta la scelta.

• RAM. CasaOS funziona senza problemi con 1GB; è nato sull'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, ma funziona realmente meglio con 4GB, perché esegue un mail server e un database prima ancora che tu installi una singola applicazione.
• Un dominio e il controllo del relativo DNS. Cloudron e Coolify richiedono entrambi un dominio reale con DNS funzionante. Cloudron preferisce avere accesso API al provider DNS, così può creare autonomamente i record e i certificati wildcard. CasaOS funziona anche con un semplice indirizzo IP, ma in questo caso non avrai alcun certificato TLS.
• Porte. Tutte e tre le soluzioni richiedono che le porte 80 e 443 siano aperte per HTTP e HTTPS. Coolify espone 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 tutte le piattaforme.

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 fare 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 preconfigurata e opinata

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 preconfezionate (Nextcloud, WordPress, Gitea, Mattermost e altre). Si rivolge a chi vuole applicazioni gestite, con aggiornamenti automatici, certificati automatici e backup automatici, ed è disposto a pagare per questo.

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

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. Quando il server torna disponibile, 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 configurerà il proprio dashboard all'indirizzo my.example.com.

Aggiunta della prima applicazione. Nel dashboard, 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, prepara il database, configura il single sign-on e pianifica un backup, senza richiedere modifiche ai file di configurazione. Questo è il punto di forza principale della piattaforma, e viene realizzato efficacemente.

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

Costi e licenza: leggere prima di decidere. Cloudron è un prodotto a pagamento con un piano gratuito limitato: il piano gratuito consente due applicazioni. Installando una terza applicazione si raggiunge il paywall; un abbonamento a pagamento (Pro o Max, con fatturazione mensile o annuale, entrambi con applicazioni illimitate) sblocca ulteriori funzionalità. Questo è il fatto più importante su Cloudron. La piattaforma è rifinita proprio perché è un prodotto commerciale, mentre il piano gratuito assomiglia più a una versione di prova estesa che a una soluzione per uno stack in crescita.

Modalità di errore, regola del sistema pulito. Se si prova a installare Cloudron su un server che esegue già altri servizi, la configurazione si interrompe prima di modificare il sistema:

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 è una semplice rigidità del programma. Cloudron impone 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 non configurata: nessun web server, nessuna installazione di Docker e nemmeno un firewall configurato manualmente. Se è stata avviata l'immagine sbagliata, la configurazione rifiuta anche qualsiasi sistema diverso da una versione Ubuntu LTS supportata (22.04 o 24.04) su 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 seleziona l'opzione DNS "Manual" invece di fornire a Cloudron un token API, la piattaforma non può creare i record né richiedere autonomamente un certificato wildcard. Per ogni nuova applicazione è quindi necessario aggiungere manualmente un record DNS prima di poter emettere il certificato, mentre il dashboard resta 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 e di tipo platform-as-a-service, simile a Heroku o Vercel ma eseguita sul proprio server. La sua unità nativa non è «installare un'applicazione pacchettizzata», ma «distribuire un repository Git»: si collega un repository e Coolify lo compila, tramite Nixpacks o un proprio Dockerfile, quindi lo distribuisce nuovamente a ogni push. Include anche database e servizi installabili con un clic. È destinato agli 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 utilizzato da Coolify. Verificare che siano in buone condizioni prima di procedere:

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

Dovrebbero risultare coolify, coolify-db, coolify-redis, coolify-realtime e coolify-proxy, tutti con stato Up. La dashboard è disponibile all'indirizzo http://<your-ip>:8000. Creare subito l'account amministratore, perché la pagina di registrazione resta aperta finché non viene creato il 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 oppure *.apps.example.com), in modo che Coolify possa assegnare a ogni applicazione distribuita il proprio sottodominio.

Aggiunta della prima applicazione. Collegare una sorgente Git (GitHub, GitLab o un semplice URL del repository), scegliere 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 già pronto, il catalogo Services permette di distribuire i componenti con pochi clic: lo stesso stack n8n per l'automazione dei workflow che altrimenti si dovrebbe configurare manualmente è disponibile come singola voce, così come Uptime Kuma per il monitoraggio delle pagine di stato.

TLS e backup. Coolify usa Let's Encrypt per ottenere automaticamente un certificato per ogni applicazione tramite Traefik, incluso nello stack. I backup sono incentrati sui database: è possibile pianificare dump di Postgres e MySQL verso uno storage compatibile con S3. Il backup dell'intera istanza, inclusa la configurazione di Coolify memorizzata in /data/coolify, richiede più operazioni manuali; è quindi preferibile esportarla e conservarla autonomamente.

Costi e licenza. L'edizione self-hosted è completamente open source e gratuita, senza limiti sul numero di applicazioni. Esiste 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.

Caso 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. Questo indica un problema del proxy o del DNS, non dell'applicazione. Le cause comuni sono 2. La prima è che le porte 80 o 443 fossero già occupate quando il proxy ha tentato di avviarsi; il relativo container è quindi terminato 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

La seconda è l'assenza del record DNS wildcard, per cui Traefik non riceve mai 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 demone Docker è arrestato oppure perché la chiave SSH non è valida. Leggere la causa effettiva nei log 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 2 minuti perché completi l'avvio. Consentire l'accesso alla porta 8000 soltanto dal proprio indirizzo IP, oppure riaprirla temporaneamente quando il proxy presenta problemi, invece di lasciarla esposta a Internet: la porta pubblica la dashboard tramite HTTP non cifrato. La documentazione di Coolify indica inoltre 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, apprezzi le quattro funzioni che un pannello automatizza: installazioni con un clic, TLS automatico, backup pianificati e gestione degli utenti. Per uno o due servizi, il semplice Docker Compose dietro Traefik svolge lo stesso compito per il TLS, con un overhead molto inferiore e senza vincoli. I pannelli convengono quando esegui molte applicazioni e il tuo tempo vale più della RAM che consumano.

Qual è il pannello migliore per chi inizia?

Per un laboratorio domestico in cui nulla è esposto a Internet ostile, CasaOS è il punto di partenza più semplice: un comando e un'interfaccia intuitiva, senza costi. Prima di esporre qualsiasi servizio, però, devi mettere davanti un reverse proxy con terminazione TLS, perché il prodotto usa 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 usare due applicazioni, una soluzione adeguata per provarlo o per una configurazione molto piccola. Oltre questo limite, Cloudron è un abbonamento a pagamento, fatturato mensilmente o annualmente, con applicazioni illimitate nei piani a pagamento. È un prodotto commerciale con un piano gratuito limitato, non software libero: se il tuo stack crescerà, prevedi questo costo.

Posso eseguire questi pannelli insieme alle applicazioni che già uso?

Cloudron: no. Richiede un sistema Ubuntu pulito e interrompe l'installazione se nginx, Docker o Node sono già installati, perché gestisce l'intera macchina. CasaOS e Coolify sono più flessibili: installano il proprio stack Docker e, in linea di principio, possono condividere un host. Tuttavia, entrambi richiedono le porte 80 e 443, quindi entrano in conflitto con qualsiasi web server o proxy già in esecuzione. Su un host che ospita già altri servizi, un pannello è in genere lo strumento sbagliato; 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 avviali nuovamente. 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: lo sono soltanto i dati. In ogni caso, verifica il ripristino su un host usa e getta prima di dismettere quello precedente.