Se hai già abbandonato il PaaS gestito, il tuo VPS è pronto, la chiave SSH è stata aggiunta e il cursore del terminale lampeggia sulla riga di installazione. Resta solo una domanda: esegui curl ... | bash per Coolify, o per Dokploy?
Entrambi gli strumenti si installano con un solo comando. Entrambi ti offrono deployment via Git-push, SSL automatico, una UI web e un reverse proxy sopra Docker. Le differenze interessanti sono quelle che emergono in produzione: come ciascuno gestisce uno standard docker-compose.yml, cosa succede durante un deploy e come ogni progetto ha risposto alle notizie che hanno ridefinito questo confronto nel 2026. Due notizie pesano più di tutte le altre: le Divulgazioni CVE di Coolify di gennaio 2026 e il Ristrutturazione della licenza di Dokploy dello stesso mese.
Questo articolo abbina ciascuno strumento a un caso d'uso specifico anziché incoronare un vincitore. Alla fine speriamo che tu sappia quale si adatta al tuo flusso di lavoro.
Riassunto rapido
- Coolify è più vecchio con l'ecosistema più ampio (~55k stelle su GitHub, oltre 300 template di servizi one-click), più pesante a riposo, Apache 2.0 ovunque, senza alcun livello a pagamento sul lato self-hosted.
- Dokploy è più giovane (~34k stelle), più leggero a riposo, core Apache 2.0 più una Source Available License separata che limita le future funzionalità a pagamento (SSO, RBAC, audit log, white-labeling).
- Coolify oggi non può eseguire deployment zero-downtime tramite Docker Compose; solo tramite Dockerfile, Nixpacks o deploy a immagine singola. Dokploy offre Docker Swarm come modalità di prima classe; lo Swarm di Coolify è etichettato come sperimentale.
- Le CVE di Coolify di gennaio 2026 sono corrette nella v4.0.0 (April 27, 2026). Aggiorna Coolify e non esporre pubblicamente la dashboard.
Quando nessuno dei due strumenti è la risposta giusta
Sia Coolify che Dokploy sono la forma sbagliata per alcune configurazioni. Tre alternative che vale la pena conoscere, in breve:
- Kamal (da 37signals): per team con una o due app che non vogliono alcuna UI; basta
kamal deploydal tuo laptop. Più semplice di Coolify o Dokploy di gran lunga, ed è la scelta giusta quando non vuoi una dashboard. - Dokku: il classico, modello Git-push a server singolo. Più vecchio, ambito più ridotto, molto stabile. L'originale "Heroku su un solo VPS".
- GitHub Actions + Docker Compose su un VPS spoglio: lo stack più piccolo possibile. Nessuna UI di orchestrazione, ma nemmeno il sovraccarico dell'orchestrazione. Ottimo per una singola app dove il flusso di deploy è
docker compose pull && docker compose up -dattivato da CI.
Se la tua forma è un'app su un solo server, sia Coolify che Dokploy sono probabilmente eccessivi; prova prima una delle opzioni qui sopra. Se hai più app, più database o un team con membri non tecnici che hanno bisogno di una UI per operare, la scelta tra Coolify e Dokploy è quella giusta da fare. Per una panoramica più ampia delle opzioni in questa categoria, consulta la nostra rassegna di piattaforme cloud self-hosted con interfaccia web.
Coolify e Dokploy in sintesi
Coolify v4.0.0 stable è uscito il April 27, 2026, dopo un lungo ciclo beta. Dokploy è alla v0.29.4 al May 11, 2026. Entrambi sono progetti PaaS open-source self-hosted nello spazio delle alternative a Heroku/Render/Vercel, entrambi avvolgono Docker con una UI, un reverse proxy HTTPS-by-default (Traefik) e deploy basati su Git.
| Funzione | Coolify | Dokploy |
|---|---|---|
| Ultima release stabile | v4.0.0 (April 27, 2026) | v0.29.4 (May 11, 2026) |
| Licenza | Apache 2.0 | Core Apache 2.0 + Source Available per le funzionalità a pagamento |
| Stack tecnologico | PHP / Laravel | TypeScript / Node.js |
| Stelle su GitHub | ~55,000 | ~34,000 |
| RAM minima (ufficiale) | 2 GB | 2 GB |
| CPU minima (ufficiale) | 2 core | non specificato |
| RAM a riposo (segnalata dalla community) | 500 MB – 1.2 GB | 300 – 400 MB |
| Zero-downtime con Docker Compose | Non supportato (solo Dockerfile/Nixpacks) | Gestione standard di Compose |
| Clustering multi-server | Docker Swarm (sperimentale) | Docker Swarm (nativo) |
| Supporto ARM64 | Sì (incl. Raspberry Pi OS) | Non pubblicizzato nella documentazione |
| Sistemi di build | Nixpacks, Dockerfile, immagine Docker | Nixpacks, Dockerfile, immagine Docker, Heroku Buildpacks, Paketo, Railpack |
| Proxy inverso | Traefik | Traefik |
| Ambito del monitoraggio self-hosted | Metriche integrate + visualizzatore di log | Metriche di base sulle risorse + analisi AI degli errori di log/build (v0.29.0+) |
Il nostro parere: scegli Dokploy se vuoi un overhead a riposo inferiore, supporto multi-server nativo e gestione standard di Docker Compose senza adattamenti specifici della piattaforma. Scegli Coolify se vuoi la libreria di app one-click più ampia, il supporto ARM64/Raspberry Pi, o Apache 2.0 puro senza alcun futuro livello a pagamento in agguato.
Impronta sulle risorse e dimensionamento del VPS
Un PaaS self-hosted può farti risparmiare il costo di Heroku. Se il livello di orchestrazione consuma 1,5 GB dei 2 GB del tuo VPS a riposo, non ti resta nulla su cui distribuire. Quindi la prima domanda pratica su un server piccolo è: quanto ti costa ciascuno strumento prima ancora di aver distribuito una singola app?
L'uso della RAM a riposo di Coolify dipende da quale monitoraggio è abilitato, con un'impronta CPU di base del 5–7% che ha dei picchi quando viene eseguito lo scrape delle metriche. La documentazione di Coolify usa un carico di lavoro di produzione rappresentativo di 8 GB di RAM, 4 core e 150 GB di storage che esegue 3 app Node.js, 4 siti statici e qualche database. È un riferimento di dimensionamento ragionevole se il tuo stack è simile.
Dokploy, al contrario, gira molto più leggero, ben al di sotto del 2% di CPU quando non c'è alcun deploy in corso.
A Resoconto di produzione di LogRocket che ha messo a confronto entrambi gli strumenti fianco a fianco è giunto alla stessa conclusione direzionale: un docker stop && docker start su un'app Dokploy non innesca un rebuild completo, mentre la stessa operazione su Coolify sì. Già solo questo sposta il costo a regime a favore di Dokploy, specialmente sui piani VPS più piccoli dove le raffiche di rebuild divorano il tuo budget di CPU.
Per il dimensionamento, ecco la configurazione VPS che consiglierei:
- Coolify, carico di lavoro leggero: 2 vCPU / 4 GB RAM / 120 GB NVMe is the practical starting point for Coolify plus a couple of small apps.
- Coolify, carico di lavoro di riferimento per la produzione: 4 vCPU / 8 GB RAM / 160 GB NVMe to match Coolify's own documented 3 Node.js + 4 static sites + databases example.
- Dokploy, carico di lavoro leggero: 1 vCPU / 2 GB RAM / 60 GB NVMe is comfortable for a single small app.
- Dokploy, margine per la produzione: 2 vCPU / 4 GB RAM / 120 GB NVMe gives you room for a small production stack.
Consiglio: la RAM a riposo di Coolify scala con la configurazione del monitoraggio. Se hai poca memoria, riduci l'intervallo di scrape delle metriche (o disabilita del tutto il monitoraggio integrato se già usi Prometheus/Grafana altrove) prima di provvedere a un server più grande.
La realtà del deployment: Docker Compose, Dockerfile e zero-downtime
La maggior parte dei team arriva a uno di questi strumenti con un docker-compose.yml , e un'aspettativa: incolli il file, fai clic su deploy, vedi l'app avviarsi. Come ciascuna piattaforma gestisce uno standard Compose, e cosa succede alle richieste in corso durante il deploy successivo, è dove emerge la distinzione pratica.
Coolify supporta Docker Compose, Dockerfile, Nixpacks (rilevamento automatico dai file di progetto) e deployment diretti di immagini Docker. C'è però un'insidia che vale la pena esplicitare: i deployment zero-downtime (rolling update, blue/green) in Coolify funzionano solo tramite Dockerfile, Nixpacks o deploy a immagine singola. Non funzionano tramite Docker Compose. Un maintainer di Coolify ha confermato in una discussione su GitHub che "per i deployment basati su Compose, tutti i container vengono arrestati prima di avviare quelli nuovi, attualmente non c'è alcun rolling update per i deployment basati su Compose." Il supporto al rolling per Compose è nella roadmap per la v5; la v4 non lo avrà. La soluzione alternativa suggerita dal maintainer è suddividere uno stack Compose in singoli servizi Coolify, il che è una migrazione tutt'altro che banale se il tuo file Compose esprime reali relazioni tra i servizi.
La conseguenza per l'utente emerge in un thread su Hacker News su Coolify, dove un operatore l'ha detto senza mezzi termini: "qualsiasi richiesta in sospeso quando aggiorni un'app viene semplicemente uccisa." Questo è accurato per i deploy con Compose oggi.
Il livello Compose di Coolify aggiunge anche ciò che il progetto chiama "variabili magiche." Ciò significa l'iniezione automatica di immagini di supporto, riscritture di rete e override dell'ambiente. L'intento è essere più efficienti; l'effetto collaterale è che un docker-compose.yml che gira senza problemi sul tuo laptop a volte ha bisogno di aggiustamenti per girare senza problemi su Coolify. Lo stesso thread su Hacker News fa emergere un caso rappresentativo: "Aggiunte 8 variabili dentro docker-compose, solo 7 vengono riconosciute." Se il tuo stack Compose è piccolo e standard, potresti non incappare in questi problemi. Se è grande o insolito, ci incapperai.
La posizione di Dokploy è diversa. Il resoconto pratico di LogRocket ha riscontrato che Dokploy "può distribuire un docker-compose.yml esistente con poche o nessuna modifica" e rimane vicino al modello di routing nativo basato su label di Docker. Lo stesso resoconto nota che lo stop/start dei container in Dokploy non innesca un rebuild completo, mentre la stessa azione su Coolify sì. Questo è un segnale direzionale sul comportamento a runtime piuttosto che una formale "garanzia di zero-downtime" dalla documentazione di Dokploy, ma è coerente con ciò che riferiscono i self-hoster su istanze VPS più piccole.
Dokploy supporta anche Heroku Buildpacks, Paketo Buildpacks e Railpack oltre a Nixpacks e Dockerfile. Per i team che arrivano da Heroku con heroku.yml o flussi di lavoro basati su buildpack, è la via di minor resistenza.
Punto chiave della sezione: se i tuoi servizi esistenti sono un vero stack Docker Compose, Coolify ti richiederà di ristrutturare la tua strategia di deployment oppure di accettare un breve downtime a ogni push. Dokploy no.
Sicurezza: le divulgazioni CVE di Coolify di gennaio 2026
Io leggo la storia più ampia in questo modo: Coolify è sicuro da eseguire oggi se lo tieni aggiornato e non esponi la dashboard all'internet pubblico. La divulgazione non squalifica il progetto. È stata seguita una divulgazione responsabile e le patch sono uscite. Ciò che rivela è che la superficie di attacco disponibile a un utente autenticato a basso privilegio era più ampia di quanto avrebbe dovuto essere. È una lezione di progettazione per il progetto e una lezione operativa per l'operatore: restringi ora il modello di esposizione.
Consiglio: anche dopo aver applicato la patch, tratta la tua dashboard di Coolify come SSH. Vincolala a una rete privata, mettila dietro una VPN, o frapponi un Tailscale. Non esporre la porta 8000 all'internet pubblico solo perché lo script di installazione lo rende facile.
Nemmeno Dokploy è esente da questo tipo di problema. Le note di rilascio della v0.29.3 riconoscono una vulnerabilità di sicurezza identificata in Dokploy e includono uno script di patch di sicurezza che ci si aspetta tu esegua insieme all'aggiornamento. Superficie più piccola, storia di progetto più breve, ma vale la stessa disciplina operativa: aggiorna il giorno in cui escono le patch, non lasciare la dashboard sull'internet pubblico.
Punto chiave della sezione: la storia delle CVE è un cartellino giallo per la pratica operativa di Coolify, non un cartellino rosso contro il progetto, ma alza l'asticella sulla disciplina degli aggiornamenti e su come esponi la dashboard.
Licenze: cosa è gratuito, cosa no
La licenza di Dokploy è stata ristrutturata il January 21, 2026. Ecco cosa è cambiato e cosa significa per i self-hoster.
Dokploy è ora Apache 2.0 standard per il core, sostituendo la precedente Apache 2.0 adattata non standard che confondeva gli utenti su cosa fosse open source e cosa no. Una Dokploy Source Available License separata ora regola il codice nelle directory proprietary/ directory: codice sorgente visibile, a pagamento per l'uso in produzione. Le funzionalità che Dokploy dice resteranno dietro quella licenza:
- Single Sign-On (SSO/SAML) e controlli di accesso avanzati
- Branding personalizzato e white-labeling
- Alta disponibilità, auto-scaling e disaster recovery
- Monitoraggio avanzato, integrazioni e funzionalità di conformità
Il progetto si è impegnato esplicitamente a non spostare mai una funzionalità open-source esistente nel livello a pagamento; le future funzionalità a pagamento sono pensate per le organizzazioni che hanno bisogno di un collante enterprise. Oggi il 2FA è già dietro il livello Startup nella pagina dei prezzi di Dokploy.
La situazione di Coolify è semplice. Il progetto è Apache 2.0 su GitHub; ogni funzionalità nella versione self-hosted è gratuita. Esiste una offerta Coolify Cloud per i team che vogliono che sia il maintainer a ospitarlo, ma la versione self-hosted è un prodotto completo senza limitazioni di funzionalità e senza un percorso di upgrade verso un livello a pagamento che oggi non hai.
Il mio parere: per gli sviluppatori solitari e i piccoli team che fanno self-hosting sul proprio VPS, Dokploy è di fatto gratuito e lo rimarrà. Per un'organizzazione che alla fine ha bisogno di SSO, RBAC granulare, audit log o white-labeling, Dokploy ti spingerà alla lunga verso un livello a pagamento. Coolify no, perché Coolify non ha quel livello nella roadmap.
Una precisazione tra le varie fonti che vale la pena fare: la build self-hosted di Dokploy include effettivamente metriche di base sulle risorse (CPU, memoria, storage, rete), e la v0.29.0 ha aggiunto l'analisi AI degli errori di log e build. Il sistema di monitoraggio di Dokploy è solo cloud per le funzionalità di monitoraggio più avanzate. Il monitoraggio, tuttavia, gira comunque localmente su un'installazione self-hosted per le metriche di base sulle risorse pre-container.
Multi-server e clustering: realtà vs marketing
Prima o poi un singolo VPS non basta più, ed entrambi i progetti promuovono in primo piano il supporto multi-server sulle loro landing page. La realtà sul campo non è la stessa.
La documentazione ufficiale sulla scalabilità di Coolify è diretta a riguardo: il supporto a Docker Swarm è etichettato come sperimentale. Il pattern multi-server standard usa server remoti validati connessi via SSH con un Docker Registry condiviso tra loro, e istanze Traefik in esecuzione per server. La modalità Swarm richiede un minimo di tre server con la stessa architettura (tutti ARM, o tutti AMD64). Kubernetes? "Solo pianificato, ma non ancora nella roadmap, quindi nessuna ETA." Se leggi la pagina di Coolify a riguardo, la versione breve è: il multi-server funziona, Swarm è una beta e Kubernetes è una visione.
Dokploy offre Docker Swarm come modalità di prima classe senza un flag sperimentale. Traefik gestisce il routing sia nelle configurazioni a server singolo che in quelle Swarm. La release v0.29.0 ha aggiunto il supporto multi-server non-root, che colma una lacuna reale (niente più SSH solo-root per aggiungere nodi remoti).
Se il clustering multi-nodo è qualcosa di cui avrai bisogno nei prossimi sei mesi, non "un giorno su una slide," Dokploy è oggi la scelta a minor rischio.
Punto chiave della sezione: se il clustering è nella tua roadmap a breve termine, la differenza su Swarm ribalta la raccomandazione verso Dokploy a prescindere dagli altri assi.
Sistemi di build e supporto ai linguaggi
I team che arrivano da Heroku terranno più di tutto agli ecosistemi di buildpack supportati da ciascuno strumento, perché è questo a decidere quanta riscrittura serve al tuo progetto prima del primo deploy.
Il percorso di build di Coolify è Nixpacks (predefinito, rilevato automaticamente dai file del progetto), Dockerfile, o un'immagine Docker pre-compilata. Nixpacks è solido per i casi comuni (Node, Python, PHP, Go, Rust), ma il rilevamento automatico ha le sue asperità. Vale la pena verificare per il tuo stack: un problema di Nixpacks di gennaio 2026 che riguardava i progetti Laravel con entrambi composer.json e package.json produceva blocchi location Nginx duplicati, il che ha rotto un'intera classe di deployment finché l'upstream non l'ha corretto.
Dokploy supporta Nixpacks, Dockerfile e immagine Docker, e aggiunge sopra Heroku Buildpacks, Paketo Buildpacks e Railpack. Se il tuo progetto si compila già senza problemi con heroku.yml o un buildpack, Dokploy ti permette di mantenere quel flusso di lavoro. Coolify ti chiederà di convertirlo.
In superficie entrambi gli strumenti sembrano uguali: deployment via Git-push da GitHub, GitLab, Bitbucket, SSL Let's Encrypt automatico, una UI web per le variabili d'ambiente e la gestione del database. L'ampiezza del sistema di build è uno dei pochi ambiti in cui Dokploy si spinge chiaramente più in là.
Cataloghi di app one-click
Per gli operatori non tecnici che vogliono distribuire servizi open-source noti (n8n, Plausible, Supabase, Ghost, Listmonk, la solita scuderia di self-hosted), la dimensione della libreria di template one-click è un vero elemento di differenziazione. Per alcuni utenti, questo è più importante di altri aspetti come le prestazioni o l'essere leggero.
Coolify offre oltre 300 servizi one-click in circa 40 categorie: AI, analytics, automazione, database, sicurezza, storage e tutto il resto. È la libreria più ampia di gran lunga e la risposta pratica per i non sviluppatori che vogliono distribuire un servizio senza scrivere un file Compose.
La libreria di template di Dokploy è più piccola. La documentazione attuale di Dokploy non pubblica un conteggio preciso, quindi non ti darò un numero.
La risposta pratica: se il tuo flusso di lavoro è "distribuisci n8n, Supabase e Plausible con due clic ciascuno," Coolify vince questo asse nettamente. Se scrivi le tue app e vuoi solo distribuirle, la dimensione del catalogo non conta e contano gli altri assi.
Come scegliere: raccomandazioni per caso d'uso
Non c'è un unico vincitore qui. Ci sono abbinamenti tra uno strumento e una forma di deployment:
- Team non tecnico che vuole una libreria di servizi: Coolify. Il catalogo di oltre 300 template è un vantaggio significativo.
- Sviluppatore Docker-native che vuole leggerezza + gestione standard di Compose: Dokploy.
- Hardware ARM64 (Raspberry Pi, VPS basati su ARM): Coolify. Dokploy non pubblicizza il supporto ARM64 nella documentazione attuale; se sei su ARM, scegli Coolify come impostazione predefinita finché non hai verificato il contrario.
- Clustering multi-nodo che userai questo trimestre: Dokploy. Swarm nativo vs Swarm sperimentale è il fattore decisivo.
- Apache 2.0 puro, nessun possibile futuro livello a pagamento: Coolify.
- Migrazione da Heroku con la volontà di mantenere gli Heroku Buildpacks: Dokploy.
- Preoccupato per le CVE di gennaio 2026: un Coolify aggiornato (v4.0.0+) va bene. La vera domanda è il tuo modello di esposizione. Se non puoi vincolare la dashboard a una rete privata o a una VPN, Dokploy è la scelta meno stressante: superficie più piccola e una storia più breve di divulgazioni ad alta gravità.
Una nota sul deployment di entrambi gli strumenti
Una volta scelto, l'installazione in sé è un solo comando su entrambi i progetti, ma c'è una scorciatoia che vale la pena conoscere. Sia Coolify che Dokploy sono disponibili come deployment one-click in il nostro marketplace, con Ubuntu 24.04 e Docker preinstallati e la dashboard già accessibile. Se vuoi saltare la configurazione manuale, gli annunci del marketplace per Coolify e Dokploy sono il percorso più veloce. Se invece preferisci partire da un OS pulito ed eseguire tu stesso l'installer ufficiale, entrambi i progetti pubblicano uno script su una riga; scegli quello che si adatta al tuo flusso di provisioning.
Domande frequenti
Dokploy è ancora open source dopo il cambio di licenza del 2026?
Sì per la piattaforma core. A partire dal January 21, 2026, il core di Dokploy è Apache 2.0 standard. Una Dokploy Source Available License separata ora regola il codice nelle directory proprietary/ directory, attualmente limitate alle future funzionalità enterprise (SSO/SAML, RBAC granulare, audit log, white-labeling). Per l'uso self-hosted solitario e dei piccoli team, Dokploy è di fatto open source.
Le vulnerabilità di sicurezza di Coolify di gennaio 2026 sono ancora un problema?
Le 11 CVE divulgate sono corrette in Coolify v4.0.0 (rilasciato il April 27, 2026). Se stai usando la v4.0.0 o una versione più recente, le vulnerabilità divulgate sono risolte. Ciò che resta è l'esposizione: tieni Coolify aggiornato e non esporre la dashboard all'internet pubblico. Vincolala a una rete privata o mettila dietro una VPN.
