n8n è un motore di automazione a nodi, open source, che connette app, API e logica personalizzata in un unico flusso visuale. Puoi ospitarlo sul tuo server e non pagare per esecuzione, oppure usare il cloud gestito. La differenza non è solo di costo: è di controllo.
Ho costruito e gestito l’infrastruttura di automazione di un’academy americana che nei mesi buoni superava il milione al mese di cash collected. Lì ho imparato che la scelta del tool è l’ultima decisione da prendere, non la prima. Prima si capisce il processo, poi si sceglie il ferro. Questa guida in italiano su n8n segue quell’ordine: prima i concetti che servono davvero, poi i pattern che funzionano in produzione, poi i limiti da conoscere prima che ti mordano.
Cos’è n8n e dove sta rispetto a Make e Zapier
Zapier è il tool per chi vuole partire in cinque minuti e non toccare mai un JSON. Make è il passo successivo: flussi più complessi, logica ramificata, prezzi legati alle operazioni. n8n è un livello ancora più in basso nel senso buono: ti dà accesso diretto al dato grezzo, un Code node per scrivere JavaScript reale, e la possibilità di girare su infrastruttura tua.
Il posizionamento pratico è questo. Zapier copre integrazioni standard senza attrito. Make gestisce scenari multi-step con buona visibilità grafica. n8n serve quando hai bisogno di trasformare dati in modo non banale, chiamare API non supportate nativamente, o quando il costo per operazione di Make inizia a pesare sul margine.
La libertà di n8n ha un prezzo: devi capire cosa succede dentro il nodo, non solo cosa entra e cosa esce.
Non è lo strumento più semplice. È quello che scala meglio quando il processo è chiaro.
Self-hosted vs cloud: i costi veri di n8n
n8n cloud parte da circa 20 dollari al mese per il piano Starter, con limiti su workflow attivi ed esecuzioni. Il piano Pro è intorno ai 50 dollari. Nessun server da gestire, aggiornamenti automatici, supporto incluso.
Il self-hosted su un VPS da 10-20 dollari al mese (DigitalOcean, Hetzner, qualsiasi provider) ti dà esecuzioni illimitate e nessun limite sui workflow. Il costo fisso è quello del server. Se hai volumi alti o workflow che girano centinaia di volte al giorno, il self-hosted ripaga in poche settimane.
Il costo nascosto del self-hosted è il tempo. Aggiornamenti, backup, monitoring, SSL: non sono lavori difficili, ma richiedono attenzione. Se non vuoi toccare un terminale, inizia con il cloud e migra quando hai un motivo concreto.
Quando conviene il self-hosted: volumi alti, dati sensibili che non vuoi far passare per server terzi, team tecnico che può gestire l’infrastruttura. Quando conviene il cloud: fase di prototipazione, team piccolo, vuoi zero ops. La documentazione ufficiale sul self-hosting copre le opzioni di deploy in dettaglio.
La scorciatoia onesta
Se il server non lo vuoi gestire, questa è la strada
n8n self-hosted ti fa risparmiare sulle operazioni e ti fa pagare in aggiornamenti, backup e uptime. Se quel lavoro non lo vuoi fare tu, Make fa la stessa cosa senza infrastruttura da mantenere: parti dal piano free e vedi se i tuoi flussi ci stanno.
- Nessun server — niente aggiornamenti, niente notti in piedi.
- 1.000 operazioni al mese gratis — scenari illimitati, senza scadenza.
- Il conto lo fai prima — run × moduli attivi: se sfori, allora sì, n8n torna economico.
I concetti fondamentali di n8n: nodi, trigger, espressioni e Code node
Nodi e trigger
Ogni workflow in n8n è una sequenza di nodi. Un nodo fa una cosa: chiama un’API, legge un foglio, filtra dati, manda un’email. Il primo nodo è quasi sempre un trigger: l’evento che fa partire la macchina. Può essere un webhook (una chiamata HTTP in arrivo), un timer (ogni ora, ogni giorno), o un evento da un’app integrata.
Il webhook trigger è quello che userai di più se costruisci automazioni connesse a form, CRM o sistemi esterni. n8n genera un URL univoco; chiunque faccia una POST a quell’URL avvia il workflow. Semplice, potente, ma richiede che il sistema mittente sia configurato correttamente.
Espressioni e accesso ai dati
In n8n accedi ai dati dei nodi precedenti tramite espressioni, scritte con la sintassi {{ $json.campo }} o {{ $node["NomeNodo"].json.campo }}. Non è una sintassi inventata: è JavaScript con un wrapper. Se sai leggere un oggetto JSON, sai già scrivere espressioni in n8n.
Il punto critico è capire che ogni nodo riceve un array di items, non un singolo oggetto. Se il nodo precedente ha prodotto tre righe, il nodo successivo le riceve tutte e tre. Questa struttura a items è la cosa che confonde di più chi viene da Make o Zapier, dove ogni record è isolato.
Il Code node
Il Code node è il motivo per cui scelgo n8n quando il dato da trasformare è complesso. Scrivi JavaScript diretto: puoi filtrare array, costruire oggetti annidati, fare calcoli, chiamare funzioni native. Non hai bisogno di concatenare cinque nodi di trasformazione per fare quello che una funzione di venti righe risolve in modo leggibile.
Attenzione: il Code node non ha accesso a moduli esterni per default nel self-hosted standard. Puoi abilitare moduli aggiuntivi nella configurazione, ma richiede un passaggio esplicito.
Credenziali
n8n gestisce le credenziali come entità separate dai workflow. Crei una credenziale una volta (OAuth, API key, basic auth), la colleghi ai nodi che la usano. Se la chiave cambia, aggiorni in un punto solo. Nel self-hosted le credenziali sono cifrate nel database locale; nel cloud sono gestite da n8n.
Error handling e guardie: come portare n8n in produzione
Un’automazione senza guardie esegue sbagliato con la stessa sicurezza con cui esegue giusto. Non rallenta, non dubita, non ti chiama. Produce.
Il modo in cui n8n si rompe in silenzio è questo: un nodo fallisce, il workflow si ferma, nessuno lo sa. Se non hai configurato un error workflow, l’esecuzione finisce in coda come «failed» e aspetta che tu apra la console. Nel frattempo, i dati che dovevano passare non sono passati.
Error workflow
n8n permette di definire un workflow dedicato alla gestione degli errori. Lo attivi nelle impostazioni del workflow principale. Quando un’esecuzione fallisce, il sistema avvia automaticamente l’error workflow passandogli i dati del fallimento: nome del workflow, nodo che ha ceduto, messaggio di errore, timestamp. Da lì puoi mandare una notifica su Slack, aprire un ticket, scrivere su un foglio di log.
Questo non è opzionale se usi n8n in produzione. È la prima cosa che costruisci, prima ancora di completare il workflow principale.
Retry e timeout
Per le chiamate API puoi configurare i retry sul singolo nodo HTTP Request: quanti tentativi, quanto aspettare tra uno e l’altro. Non farlo significa che un timeout di rete fa cadere l’intera esecuzione. Il timeout di default in n8n è spesso generoso, ma per chiamate a LLM o sistemi lenti è meglio alzarlo esplicitamente.
Il nodo IF come guardia
Usa i nodi IF per validare i dati prima di passarli ai nodi critici. Se il campo email è vuoto, il ramo destro dell’IF lo manda a un log degli errori invece di far fallire il nodo di invio. È la differenza tra un workflow che si ferma e uno che degrada in modo controllato.
Il silenzio dei sistemi non è salute: è il sintomo che qualcosa produce sbagliato senza dirtelo.
I pattern che uso davvero in produzione con n8n
Webhook in entrata con coda su Google Sheets
Il pattern più comune: un form o un CRM fa una POST al webhook di n8n. Il workflow valida i dati, li arricchisce (geocodifica, lookup su un altro database, classificazione via AI), e scrive su un Google Sheet come coda di lavoro. Un secondo workflow, schedulato, legge quella coda e processa i record uno alla volta.
La coda su Sheets non è elegante, ma è leggibile da chiunque nel team, modificabile a mano in emergenza, e non richiede infrastruttura aggiuntiva. Per volumi alti si sostituisce con un database reale, ma per iniziare funziona e ti fa capire i colli di bottiglia prima di over-engineerare.
Chiamate API non integrate
n8n ha centinaia di nodi nativi, ma il nodo HTTP Request è quello che uso di più. Qualsiasi API con documentazione è accessibile: costruisci l’header di autenticazione, componi il body con le espressioni, gestisci la risposta. Ho connesso sistemi che non avranno mai un nodo nativo perché sono verticali di nicchia — e n8n non ha mai opposto resistenza.
AI nei flow: attenzione alla posizione del retrieval
Quando costruisci workflow con LLM e RAG, la posizione del nodo di retrieval non è un dettaglio. Ho visto un flow che produceva N post con titoli diversi ma tutti sullo stesso argomento, perché il nodo RAG stava fuori dal loop: una sola query, un solo contesto, replicato N volte. L’output sembrava vario a colpo d’occhio; era identico nella sostanza. Una query RAG per iterazione, dentro il loop, costruita sulla variabile che cambia. Fuori dal loop stanno solo le cose davvero invarianti.
Per i workflow AI in n8n, la sezione Advanced AI della documentazione ufficiale è il punto di partenza corretto per capire come collegare modelli e memory nodes.
I limiti e le trappole di n8n da conoscere prima
Il debugging non è immediato. Quando un’esecuzione fallisce, n8n mostra i dati di input e output di ogni nodo nell’esecuzione registrata — ma solo se hai abilitato il salvataggio delle esecuzioni. Di default, le esecuzioni riuscite non vengono salvate per non riempire il database. Configura la retention in modo esplicito.
Le espressioni con dati annidati profondi diventano fragili. Se il JSON che arriva dall’API cambia struttura, l’espressione restituisce undefined senza errore esplicito. Usa il Code node con accesso condizionale (?.campo) quando la struttura del dato non è garantita.
I workflow lunghi e ramificati diventano difficili da leggere. n8n non ha un sistema di sotto-workflow robusto come Make ha gli scenari riutilizzabili. Puoi chiamare un altro workflow via nodo, ma la leggibilità si degrada presto se non tieni la struttura piatta e modulare fin dall’inizio.
Il self-hosted richiede attenzione agli aggiornamenti. n8n rilascia versioni spesso; alcune breaking change hanno rotto workflow in produzione senza preavviso evidente. Prima di aggiornare, testa su un ambiente di staging. Se non hai staging, hai una dipendenza dal coraggio.
Il primo workflow sensato da costruire con n8n
Non partire da un workflow complesso. Il primo workflow che ha senso costruire in n8n italiano è questo: webhook in entrata → validazione con IF → scrittura su Google Sheets → notifica su Slack o email.
Quattro nodi. Ti insegna la struttura a items, le espressioni, le credenziali Google, e il routing condizionale. È abbastanza semplice da finire in un pomeriggio, abbastanza reale da metterlo in produzione subito.
Aggiungi l’error workflow prima di attivarlo. Manda un messaggio di test al webhook, verifica che il dato arrivi su Sheets, verifica che l’errore forzato arrivi su Slack. Solo dopo puoi dire che il workflow è finito.
Da lì aggiungi complessità un nodo alla volta. Ogni aggiunta porta una guardia. Questo è il modo in cui si costruisce una macchina che regge, non una demo che funziona solo quando la guardi.
n8n non è il tool più semplice del mercato, ma è quello che ti lascia più leva quando il processo è chiaro e il volume cresce. La scelta di usarlo non è tecnica: è la scelta di investire in una macchina che non ti presenterà il conto per ogni esecuzione quando scala.
Domande frequenti
n8n è gratuito?
Il codice sorgente di n8n è open source e puoi ospitarlo gratis su un tuo server. Paghi solo l’infrastruttura. Il cloud gestito da n8n ha piani a pagamento che partono da circa 20 dollari al mese. Non esiste un piano cloud gratuito permanente.
n8n funziona in italiano?
L’interfaccia di n8n è in inglese e non ha una traduzione ufficiale in italiano. Puoi usarlo in italiano nel senso che non ci sono barriere tecniche: tutta la logica, le espressioni e i dati supportano caratteri UTF-8 senza problemi.
Qual è la differenza principale tra n8n e Make?
Make ha un modello di pricing a operazioni e un’interfaccia più accessibile. n8n dà accesso diretto al codice JavaScript, nessun limite di operazioni nel self-hosted, e più controllo sulla struttura dei dati. Make è più veloce da avviare; n8n scala meglio a parità di volume elevato.
n8n self-hosted è difficile da configurare?
Con Docker ci vogliono meno di trenta minuti per un’istanza funzionante. Il punto più delicato è la gestione del database PostgreSQL in produzione e la configurazione SSL. Con un VPS standard e le istruzioni ufficiali, un’installazione base è alla portata di chiunque abbia usato un terminale.
Trasparenza: in questo articolo c’è un link di affiliazione. Se ti iscrivi da lì io ricevo una commissione, per te non cambia niente. Linko solo strumenti che uso in produzione.
