n8n self hosted: come installare n8n sul tuo server e liberarti dal cloud per sempre

L’installazione di n8n self hosted è la scelta giusta se vuoi controllo completo su dati, costi e aggiornamenti. Prendi un VPS con almeno 2 vCPU e 4 GB di RAM, installi Docker, configuri le variabili d’ambiente obbligatorie e in meno di un’ora hai un’istanza funzionante. Tutto il resto è ottimizzazione.

Il cloud di n8n.io è comodo finché i workflow sono pochi e semplici. Quando la macchina cresce — più scenari, più esecuzioni parallele, dati sensibili che non puoi far transitare su server altrui — il piano cloud diventa un limite strutturale prima che economico. Il self-hosting risolve entrambi i problemi, ma lo fa bene solo se sai cosa stai costruendo. Questa guida copre l’architettura minima, l’installazione con Docker, la configurazione delle variabili critiche e le guardie senza cui un’automazione si rompe in silenzio.

Perché scegliere n8n self hosted invece del cloud

Il piano cloud di n8n ha un limite di esecuzioni mensili. Quando lo superi, i workflow si fermano o devi salire di piano. Con il self-hosting non esiste quel tetto: le esecuzioni dipendono solo dall’hardware che scegli tu.

Il secondo motivo è la privacy dei dati. Se i tuoi workflow toccano dati di clienti — email, contratti, pagamenti — farli transitare su infrastruttura terza è un problema legale prima che tecnico. Sul tuo server controlli dove vivono i dati e chi ci accede.

Il terzo motivo è il controllo sugli aggiornamenti. n8n rilascia versioni ogni settimana. Sul cloud vengono applicate automaticamente: oggi funziona, domani un nodo si comporta diversamente e non sai perché. Sul self-hosted aggiorni quando vuoi, dopo aver testato.

C’è anche un quarto aspetto che viene ignorato quasi sempre: la possibilità di usare l’API REST di n8n per gestire i workflow programmaticamente. Creare, aggiornare, attivare un workflow via curl o script è molto più stabile quando sei tu a controllare la versione dell’istanza.

L’architettura minima per n8n self hosted

Prima del tool, il processo. Devi decidere tre cose prima di toccare il server: dove vivono i dati, chi esegue i job in coda, e come entrano le richieste dall’esterno.

Database: SQLite va bene solo per i test

n8n usa SQLite come default. Per un’installazione di produzione serve PostgreSQL. SQLite non regge la concorrenza: se due esecuzioni scrivono contemporaneamente, i dati si corrompono in modo silenzioso. PostgreSQL è l’unica scelta sensata dal momento in cui hai più di cinque workflow attivi in parallelo.

Tieni il database su un volume separato dal container n8n. Se aggiorni n8n e qualcosa va storto, vuoi poter tornare indietro senza perdere la cronologia delle esecuzioni.

Queue mode: quando serve e quando no

La queue mode — che usa Redis come broker — serve quando hai workflow con molte esecuzioni parallele e non vuoi che si accodino tutte sul processo principale. In queue mode hai un processo main (che gestisce l’API e l’editor) e uno o più worker che eseguono i job.

Se sei all’inizio, non attivare la queue mode subito. Aggiunge complessità senza beneficio finché i tuoi workflow non saturano un singolo processo. Inizia con l’architettura semplice: un container n8n, un database PostgreSQL, un volume per i file.

Reverse proxy: Nginx o Caddy davanti a tutto

n8n gira sulla porta 5678. Non esporla mai direttamente su internet. Metti un reverse proxy davanti — Nginx o Caddy — che gestisca il certificato SSL e instradi il traffico. Caddy è più semplice da configurare per chi non ha esperienza con Nginx: gestisce il certificato Let’s Encrypt in automatico.

Installazione con Docker: i passi reali

Docker è il modo più controllato per installare n8n self hosted. Hai un container isolato, puoi aggiornarlo con un pull e un restart, e puoi riproducirre l’installazione identica su un altro server in dieci minuti.

Prepara il server

Un VPS con Ubuntu 22.04, 2 vCPU e 4 GB di RAM è sufficiente per iniziare. Se i tuoi workflow usano nodi pesanti — chiamate AI, elaborazione di file grandi, molte esecuzioni simultanee — sali a 8 GB. Installa Docker e Docker Compose seguendo la documentazione ufficiale di Docker.

Il file docker-compose.yml

Crea una directory dedicata, ad esempio /opt/n8n. Dentro ci metti il docker-compose.yml e il file .env con le variabili. La struttura base prevede tre servizi: PostgreSQL, n8n e, se vuoi, Caddy come reverse proxy. I volumi li dichiari esplicitamente così Docker non li cancella al primo down.

Un errore comune è mettere le credenziali del database direttamente nel docker-compose.yml. Mettile nel .env e non committare mai quel file su un repository pubblico. Vale anche per la chiave di encryption di n8n.

Le variabili d’ambiente che non puoi ignorare

n8n legge la configurazione da variabili d’ambiente. Quelle obbligatorie per una produzione stabile sono cinque.

N8N_ENCRYPTION_KEY — cifra le credenziali salvate in n8n. Generala con openssl e non cambiarla mai dopo il primo avvio: se la cambi, tutte le credenziali esistenti diventano illeggibili.

DB_TYPE, DB_POSTGRESDB_HOST, DB_POSTGRESDB_DATABASE, DB_POSTGRESDB_USER, DB_POSTGRESDB_PASSWORD — le coordinate del database PostgreSQL.

N8N_HOST e N8N_WEBHOOK_URL — il dominio su cui gira n8n. Senza questi, i webhook generano URL sbagliati e i trigger non funzionano.

EXECUTIONS_DATA_PRUNE e EXECUTIONS_DATA_MAX_AGE — attivano la pulizia automatica della cronologia delle esecuzioni. Senza questa coppia, il database cresce senza controllo. Imposta un’età massima in ore (720 ore sono trenta giorni, un punto di partenza ragionevole).

Le guardie che separano un’installazione funzionante da una che si rompe in silenzio

Un’automazione senza guardie esegue sbagliato con la stessa sicurezza con cui esegue giusto. Sul self-hosted questo vale doppio perché non hai nessuno che monitori per te.

Backup automatici del database

PostgreSQL si fa il dump con pg_dump. Metti uno script in cron che gira ogni notte, comprime il dump e lo sposta su uno storage separato — un bucket S3, un altro server, non importa: l’importante è che il backup non stia sullo stesso disco del database. Se perdi il server, vuoi avere i dati da qualche altra parte.

Healthcheck sul container

Docker ha un meccanismo di healthcheck nativo. Configuralo nel docker-compose.yml per fare una richiesta HTTP all’endpoint /healthz di n8n ogni trenta secondi. Se il container non risponde per tre controlli consecutivi, Docker lo riavvia. Non è monitoring sofisticato, ma ferma il caso più comune: il processo che si blocca senza uscire.

Alerting esterno

L’healthcheck interno non basta. Se il server cade, Docker non può riavviare niente. Usa un servizio di monitoring esterno — Better Stack ha un piano gratuito — che pinga il tuo dominio ogni minuto e ti manda una notifica se non risponde. Il silenzio dei sistemi non è salute: devi essere tu a cercare il problema, non aspettare che te lo segnali un cliente.

Log centralizzati

Per default, i log di n8n finiscono dentro il container. Configura Docker per scriverli su file con una rotazione automatica, così non riempi il disco. Il parametro da impostare nel daemon Docker è json-file con max-size e max-file. Quando qualcosa va storto, i log sono il primo posto dove guardi: non puoi permetterti di non averli.

Aggiornare n8n self hosted senza perdere dati

Gli aggiornamenti di n8n sono frequenti. La procedura sicura è sempre la stessa: fai un dump del database, poi aggiorna il tag dell’immagine nel docker-compose.yml, poi fai docker compose pull e docker compose up -d. Se qualcosa si rompe, ripristini il dump e torni al tag precedente.

Non usare il tag latest in produzione. Fissa sempre la versione esplicita, ad esempio n8nio/n8n:1.47.1. Così sai esattamente cosa gira, puoi leggere il changelog prima di aggiornare e puoi tornare indietro in modo preciso.

Dopo ogni aggiornamento, verifica i workflow critici a mano. n8n a volte cambia il comportamento di nodi esistenti in versioni minori. Un workflow che ieri produceva un certo output potrebbe produrne uno diverso dopo l’aggiornamento, senza errori, senza avvisi. Questo vale soprattutto per i nodi con espressioni complesse: il risultato cambia in silenzio.

I problemi che troverai e come risolverli

I webhook non funzionano dopo l’installazione

Il 90% delle volte è N8N_WEBHOOK_URL non configurata o configurata con HTTP invece di HTTPS. n8n costruisce gli URL dei webhook usando quella variabile: se è sbagliata, genera URL che non puntano da nessuna parte. Controlla che il valore corrisponda esattamente al dominio con cui hai configurato il reverse proxy, incluso il protocollo.

L’editor salva e sovrascrive le patch API

Se aggiorni un workflow via API REST — il classico ciclo GET → modifica → PUT — e l’editor è aperto sulla stessa scheda con la versione vecchia, un salvataggio dall’editor sovrascrive la tua patch senza avvisarti. Il workflow torna alla versione precedente. L’updatedAt cambia, tutto sembra normale, ma sul server gira il vecchio flow. La regola è semplice: prima chiudi l’editor, poi fai la patch via API. Dopo il PUT, ricarica l’editor per caricare la versione nuova.

Il database cresce e rallenta tutto

Senza la pulizia automatica, la tabella delle esecuzioni diventa il collo di bottiglia. n8n salva ogni esecuzione con i dati di input e output di ogni nodo. Su workflow con payload grandi, questa tabella può arrivare a gigabyte in poche settimane. Attiva EXECUTIONS_DATA_PRUNE=true e imposta EXECUTIONS_DATA_MAX_AGE a un valore ragionevole. Se hai già un database gonfio, fai un VACUUM ANALYZE su PostgreSQL dopo la prima pulizia.

Per chi costruisce automazioni serie — agenzie, infobusiness con più funnel attivi — il self-hosting non è una scelta tecnica ma di architettura. Significa decidere che la macchina è tua: la controlli tu, la ripari tu, la fai crescere tu. Il framework completo per usare n8n in modo professionale parte da qui, dall’infrastruttura. Il resto — i workflow, gli agenti, le integrazioni — viene dopo. Prima il processo, poi il tool: questa sequenza non cambia neanche quando il tool sei tu a ospitarlo.

Se stai valutando se ha senso passare al self-hosting rispetto a continuare con il cloud, la risposta dipende da una cosa sola: hai workflow con dati sensibili o hai già superato i limiti del piano? Se la risposta è sì a uno dei due, il self-hosting non è un’opzione, è la prossima mossa. Se sei ancora lontano da entrambi i limiti, il processo di automazione dell’agenzia viene prima: non ha senso ottimizzare l’infrastruttura se le automazioni non girano ancora.

Domande frequenti

Quanto costa mantenere n8n self hosted ogni mese?

Un VPS adeguato per un’installazione media costa tra 10 e 40 euro al mese a seconda del provider e delle risorse. n8n in sé è gratuito in self-hosting con la licenza fair-code. I costi aggiuntivi sono il dominio e, opzionalmente, un servizio di backup su cloud storage.

Posso migrare i workflow dal cloud n8n al self-hosted?

Sì. n8n permette di esportare i workflow in formato JSON dall’editor. Li importi sull’istanza self-hosted, riconfigi le credenziali e riattivi i trigger. Le credenziali non si esportano per motivi di sicurezza: devi reinserirle a mano sulla nuova istanza.

La queue mode è necessaria per andare in produzione?

No. La queue mode serve quando hai molte esecuzioni parallele che saturano il processo principale. Per la maggior parte delle installazioni con workflow standard, l’architettura semplice con un singolo container regge bene. Attivala quando vedi effettivamente il collo di bottiglia, non prima.

Cosa succede se non aggiorno n8n per mesi?

L’istanza continua a girare. Il rischio vero non è la stabilità ma la sicurezza: le versioni vecchie possono avere vulnerabilità note. Controlla il changelog di n8n ogni due settimane e pianifica un aggiornamento mensile con backup preventivo.