C’è stato un momento, qualche tempo fa, in cui chiunque sviluppasse con Next.js, Astro o SvelteKit puntava gli occhi su Vercel quasi per inerzia. Connetti il repository, fai push, ricevi un URL: difficile chiedere di meglio.
Poi sono arrivate le prime bollette a tre cifre per progetti hobbistici che facevano un picco di traffico imprevisto. Heroku invece è entrato ufficialmente in sustaining engineering mode a febbraio 2026, smettendo di aggiungere feature, e chi lo usava in azienda ha iniziato a fare i conti con NIS2 e GDPR. La domanda che molti si pongono adesso è semplice: ha ancora senso tenere il deploy su infrastruttura altrui quando un VPS Hetzner da 5 euro al mese basta e avanza?
In questo scenario è maturato Coolify, una PaaS open source che ha raggiunto la versione stabile 4.0.0 ad aprile 2026 dopo quasi due anni di beta. Sviluppato dall’ungherese Andras Bacsai, oggi sfiora le 60.000 stelle su GitHub e offre oltre 280 servizi one-click tra applicazioni e database. La promessa è prendere un server Linux qualsiasi, lanciare uno script, e ottenere un’esperienza di deploy molto simile a quella di Vercel o Heroku ma sotto il proprio controllo. Con il rilascio della 4.1.0 a maggio, sono arrivati il build pack Railpack, l’audit logging strutturato e il supporto MCP per l’integrazione con gli agenti AI. È un buon momento per valutare se vale la pena fare il salto.
Perché una PaaS self-hosted ha senso nel 2026
Per anni gestire un server da solo significava configurare nginx, ottenere certificati SSL e orchestrare container significava giornate di lavoro e potenziali notti in bianco. La situazione è cambiata parecchio.
Strumenti come Coolify hanno automatizzato la parte noiosa, ovvero il reverse proxy Traefik, i certificati Let’s Encrypt che si rinnovano da soli, i backup dei database e i webhook per il deploy automatico al push. Quello che rimane da gestire è poco, e per molti progetti il rapporto fatica/beneficio si è invertito completamente.
Il punto economico è quello che più colpisce. Un VPS Hetzner con 2 vCPU e 2 GB di RAM costa circa 5 euro al mese ed è in grado di reggere un’applicazione Next.js di medio traffico, un database PostgreSQL, una cache Redis e qualche servizio di contorno come Plausible Analytics o Uptime Kuma.
Sulla stessa infrastruttura, Vercel ti chiederebbe il piano Pro a 20 dollari per sviluppatore, più i costi di banda che possono esplodere durante i picchi.
C’è poi la questione della sovranità del dato. Le aziende europee si trovano sempre più spesso davanti a clienti che chiedono dove fisicamente risiedono i dati, e poter rispondere “su un nostro server in Europa e gestito da noi” è un argomento serio. Coolify rimuove un livello di dipendenza da provider extra-UE che molti considerano scomodo.
Come funziona Coolify sotto il cofano
L’architettura è più semplice di quanto sembri. All’installazione, lo script crea quattro container Docker che compongono il control plane, ovvero il pannello web scritto in PHP/Laravel, un database PostgreSQL per la configurazione, una coda Redis e un realtime server per le notifiche live nel browser. Tutto qui, niente orchestrazione complessa tipo Kubernetes e nessuno stack che ti spaventa quando devi capire cosa è andato storto.
Quando colleghi un repository Git, Coolify legge il codice e decide come buildarlo usando i cosiddetti build packs. Le opzioni disponibili sono quattro, ciascuna con un caso d’uso preciso.
- Nixpacks, l’impostazione predefinita, rileva automaticamente il linguaggio del progetto e prepara un’immagine Docker pronta all’uso
- Dockerfile, se preferisci scrivere tu il file di build mantenendo il controllo completo sul processo
- Docker Compose, ideale per applicazioni multi-servizio dove vuoi orchestrare più container in un unico stack
- Railpack, introdotto in beta con la versione 4.1.0 di maggio 2026, pensato per superare alcuni limiti di Nixpacks
Railpack è il candidato a diventare il default nelle prossime release per chi necessita di pipeline più articolate.
Davanti a tutte le applicazioni che fai girare c’è Traefik, un reverse proxy moderno che gestisce automaticamente i certificati TLS tramite Let’s Encrypt. Tu inserisci il dominio nel pannello, punti il record DNS al tuo server, e Coolify si occupa del resto, ovvero emette il certificato, lo rinnova ogni 60 giorni e lo applica al traffico in entrata. Lo stesso vale per i sottodomini dinamici delle preview deployment, quelli che ti permettono di avere un URL pubblico per ogni pull request aperta.
L’altra novità interessante di v4.1.0 è il supporto MCP nativo. Coolify espone un server MCP a livello di istanza con tool in sola lettura sulle sue risorse, attivabile da API o dal pannello. In pratica, puoi collegare Claude Code o un altro agente AI alla tua installazione e chiedergli “dimmi quanti deploy hai fatto questa settimana e quali container stanno consumando più RAM“, e ottenere risposte basate sui dati del tuo control plane. È un’integrazione basilare ma è il primo segnale che la categoria self-hosted sta abbracciando il protocollo MCP per gli agenti.
Installare Coolify in dieci minuti
L’installazione è probabilmente la parte che fa più piacere. I requisiti minimi sono modesti, ovvero un VPS 2 core con almeno 2 GB di RAM, 30 GB di spazio disco, una distribuzione Debian-based (Ubuntu, Debian) o Redhat-based (Fedora, AlmaLinux, Rocky), e accesso SSH come root. Funziona anche su Raspberry Pi OS a 64 bit, anche se, per uso serio è meglio una macchina più prestante.
La procedura standard parte da un server appena creato. Collegati via SSH e lancia il comando ufficiale.
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bashLo script verifica la distribuzione, installa Docker se manca, scarica le immagini necessarie e configura tutto. L’installazione dura tra i 5 e i 10 minuti a seconda della banda del server. Al termine, ti viene mostrato l’URL del pannello web (http://IP-DEL-SERVER:8000) e ti chiede di creare l’account amministratore al primo accesso.
A questo punto la prima cosa sensata è puntare un dominio al server e configurarlo nel pannello. Vai in Settings e imposta l’ INSTANCE_DOMAIN con il tuo sottodominio (per esempio panel.tuosito.it). Coolify ti dirà di aggiungere un record A nel DNS che punti all’IP del server. Una volta propagato il DNS, abilita HTTPS automatico e il pannello stesso diventerà accessibile via TLS, cifrato dall’inizio alla fine.
Il secondo passo obbligatorio è collegare un account Git. La via più pulita è creare una GitHub App dedicata, dal pannello scegli Sources, New, GitHub App, segui la procedura guidata che genera la app su GitHub, installala sui repository che ti interessano e torna su Coolify per finalizzare. Da questo momento in poi, ogni push su un branch monitorato può triggerare un deploy automatico.
Se vuoi tenere Coolify aggiornato, sappi che il sistema si auto-aggiorna di default. Per forzare manualmente un upgrade alla versione corrente puoi entrare nel server e lanciare i comandi seguenti.
cd /data/coolify/source
docker pull ghcr.io/coollabsio/coolify:latest
docker compose up -dI dati e le configurazioni persistono attraverso gli aggiornamenti, ma prima di un major version jump conviene sempre fare un backup del database PostgreSQL interno.
Deploy di un’applicazione Next.js, in pratica
Per capire cosa cambia davvero rispetto a Vercel, vediamo il flusso completo per un’applicazione reale. Mettiamo che tu abbia un progetto Next.js 15 con un database PostgreSQL e ti serva metterlo in produzione su un sottodominio.
Dal pannello, crea un nuovo progetto e poi una nuova risorsa di tipo Application. Scegli la GitHub App che hai configurato prima, seleziona il repository e il branch (tipicamente main per la produzione, staging per un ambiente intermedio). Coolify ti mostra le opzioni di build, lascia Nixpacks selezionato e specifica il dominio finale, per esempio app.tuosito.it. Aggiungi il record DNS che punta al server, e il certificato TLS verrà emesso automaticamente al primo deploy.
Le variabili d’ambiente vanno nella sezione dedicata. Per Next.js servono cose come NODE_ENV=production e le credenziali del database. Coolify offre le cosiddette magic environment variables, ovvero stringhe interpolabili che si risolvono a runtime con i valori reali dei servizi collegati. Se crei un database PostgreSQL come risorsa separata nello stesso progetto, puoi referenziarlo nell’app con DATABASE_URL=${POSTGRES_URL} senza copia-incolla manuali.
Per il database, torna alla home del progetto, New Resource, scegli PostgreSQL 16 dai servizi one-click. Coolify ti chiede solo nome del database, versione e se vuoi abilitare i backup automatici verso un bucket S3 (o uno qualunque dei provider compatibili). Una volta avviato, copia la stringa di connessione interna e usala come riferimento nell’app.
L’ultimo passaggio è attivare il deploy automatico. Nella scheda dell’applicazione, abilita Auto Deploy on Push e configura il webhook GitHub. Da quel momento, ogni commit su main triggera una nuova build. Se apri una pull request, Coolify può creare una preview deployment su un sottodominio temporaneo (per esempio pr-42.app.tuosito.it), esattamente come fa Vercel.
Il primo deploy richiede qualche minuto perché Nixpacks scarica le dipendenze e costruisce l’immagine Docker. I deploy successivi sono più veloci grazie alla cache delle immagini. Se qualcosa va storto, hai un terminale integrato che ti mostra i log di build e di runtime in tempo reale.
I limiti da conoscere prima di cambiare
Coolify ha qualche limite che è meglio mettere in chiaro prima di migrare progetti critici.
Il primo è la singola istanza. Fino alla versione 4.x, Coolify è pensato per gestire applicazioni distribuite su più server (server di build, server di produzione, server di staging) ma il control plane è uno solo. Se quel server muore, perdi il pannello fino a quando non lo ripristini, anche se le applicazioni continuano a girare. La scalabilità multi-server orizzontale arriverà con la v5, attualmente in sviluppo, ma per ora se vuoi alta disponibilità del control plane devi arrangiarti con backup robusti e procedure di disaster recovery.
Il secondo limite riguarda il testing integrato. Vercel ha Deployment Checks native, un marketplace di tool di testing che si agganciano alla pipeline senza configurazione. Coolify, come Dokku, Kamal e CapRover, non offre un equivalente nativo, per integrare test automatici sulle preview deployment devi orchestrare GitHub Actions o un workflow simile, effettuando il polling dello stato del deploy via API Coolify e lanciare i test contro l’URL della preview. È fattibile e nemmeno difficile, ma è un pezzo di lavoro in più rispetto al “tutto incluso” delle PaaS commerciali.
Il terzo è la gestione manuale degli aggiornamenti del sistema operativo sottostante. Su Vercel non devi preoccuparti dell’OS, mentre con Coolify il server è tuo, ogni due o tre settimane serve dedicare del tempo ad aggiornare con apt update && apt full-upgrade, riavviare se necessario, e controllare che Docker e Traefik abbiano ripreso a girare correttamente.
Infine, c’è la curva di apprendimento iniziale. Anche se l’installazione è banale, capire come strutturare i progetti, come usare correttamente le magic environment variables, come configurare le build su monorepo con pnpm workspaces o turbo richiede qualche lettura della documentazione. La community è attiva e la documentazione ufficiale è migliorata molto nell’ultimo anno, ma non aspettarti di essere produttivo dal primo giorno se vieni da un’esperienza Vercel.
Coolify: considerazioni finali
Coolify si trova in una posizione interessante. Non è la PaaS magica che sostituisce Vercel per chiunque. La verità è che hai sempre una scelta tra zero ops e responsabilità, tra “qualcun altro pensa a tutto” e “decidi tutto tu“. Coolify è semplicemente il tool che ha reso questa seconda strada più percorribile di quanto lo sia mai stata.
Se stai costruendo un progetto serio, probabilmente scoprirai che migrare a un setup Coolify su Hetzner o OVH ti fa risparmiare abbastanza per investire in altro.
L’arrivo del supporto MCP è la cosa che, personalmente, trovo più interessante guardando ai prossimi mesi. Avere un’infrastruttura che gli agenti AI possono leggere e (in futuro) modificare cambia il modo in cui penserai alla manutenzione. Non più “apro il pannello e cerco l’errore“, ma “Claude: investiga perché il container è in restart loop e pianifica una fix” oppure “Claude: scrivi un’app python per gestire gli update del server e notificarmi in email se qualcosa va storto“.
