n8n 3.0 è uscita in beta il 27 ottobre 2026 e la versione stabile è attesa a inizio dicembre. Non porta grandi funzioni nuove. Elimina nodi vecchi, rende più severe le impostazioni di sicurezza e si installa solo con Docker. Alcuni workflow che oggi funzionano si fermeranno dopo l’aggiornamento.
Prima di passare alla 3.0 apri il Migration Report in Settings > Migration Report e correggi ciò che segnala. Poi fai un backup completo, perché il ritorno alla 2.x non è previsto.
Qui trovi le modifiche che rompono la compatibilità, i sostituti dei nodi rimossi e l’ordine in cui affrontare la migrazione. Le informazioni vengono dalla documentazione ufficiale di n8n aggiornata a fine ottobre 2026.
Che cosa è n8n 3.0 e quando arriva
n8n è una piattaforma per automatizzare processi aziendali collegando applicazioni, database e modelli di intelligenza artificiale con workflow visuali. Si usa in cloud oppure installata sui propri server. Segue il versionamento semantico: le modifiche che possono rompere workflow o configurazioni arrivano solo con un nuovo numero principale. Nell’ultimo anno il team ha raccolto codice da togliere, impostazioni da rendere più sicure e funzioni da ritirare. La 3.0 le mette insieme in un solo rilascio.
Le novità invece continuano a uscire con gli aggiornamenti settimanali: dalla 2.0 di dicembre 2025 n8n ha pubblicato più di 45 versioni. Per questo la 3.0 non va confusa con un aggiornamento ricco di funzioni. Serve a ripulire le basi su cui lavoreranno le versioni 3.x.
Le date ufficiali sono tre. La beta 3.0.0 è disponibile dal 27 ottobre 2026 sia per chi installa n8n sui propri server sia su n8n Cloud. Su Cloud si sceglie 3.0.0 Beta (early access) quando si cambia versione. La versione stabile è prevista per inizio dicembre 2026. Il supporto alla 1.x termina il 31 dicembre 2026, come indica il centro assistenza di n8n.
| Versione che usi | Cosa succede | Cosa fare |
|---|---|---|
| 1.x | Supporto fino al 31/12/2026; non esiste un passaggio diretto alla 3.0 | Aggiorna prima alla 2.x. Le istanze Cloud self-serve ancora su 1.x passano alla 2.x in automatico |
| 2.x | Dopo l’uscita della 3.0 stabile riceve correzioni di sicurezza e bug critici per 12 mesi | Nessuna fretta: porta l’istanza all’ultima 2.x e usa il Migration Report |
| 3.0 beta | Facoltativa; dalla 3.x non si torna alla 2.x | Provala solo su un’istanza di test con backup completo |
Le modifiche valgono per tutte le edizioni: Community installata in proprio, Cloud, Business ed Enterprise. Credenziali e storico delle esecuzioni restano dopo l’aggiornamento. L’aggiornamento richiede un breve riavvio, come gli altri.
Docker obbligatorio per l’installazione sui tuoi server
È la modifica più visibile. Dalla 3.0 n8n self-hosted si installa solo con Docker. Le installazioni con npm o con npx n8n non sono più supportate e la 3.0 non pubblica un pacchetto n8n eseguibile su npm. Secondo n8n alcune nuove funzioni di sicurezza dipendono da un’installazione in container. Le installazioni con Kubernetes e Helm non cambiano.
Per un’installazione nuova n8n propone uno script di installazione in una riga:
curl -fsSL https://get.n8n.io | sh
Lo script controlla che Docker sia presente e attivo e crea una cartella n8n. Poi scrive i file di configurazione con segreti generati e avvia l’istanza sulla porta 5678. Richiede il plugin docker compose v2, non il vecchio comando separato docker-compose. Su Windows va lanciato da WSL con l’integrazione WSL2 di Docker Desktop. Puoi anche scaricarlo e leggerlo prima di eseguirlo.
Lo script è pensato per installazioni nuove, non per convertire quelle esistenti. Usa di default SQLite come database. Per un’istanza aziendale o di produzione n8n consiglia Docker Compose con Postgres.
Se hai già un tuo file Docker Compose non devi cambiare nulla. Se invece usi npm, l’installazione attuale continua a girare sulla 2.x. Prima di passare alla 3.0 però devi spostarla su Docker, portando con te i dati e la chiave di cifratura (senza la chiave le credenziali salvate non si leggono).
I nodi rimossi e cosa usare al loro posto
Un workflow che contiene un nodo rimosso fallisce quando parte. Se è pubblicato, all’avvio della 3.0 non si attiva e i suoi trigger smettono di scattare. La pagina delle modifiche incompatibili elenca tutti i nodi tolti. Questi sono i sostituti indicati da n8n per i più diffusi.
| Nodo rimosso | Sostituto ufficiale |
|---|---|
| Function | Code, modalità Run Once for All Items |
| Function Item | Code, modalità Run Once for Each Item |
| Item Lists | Split Out, Aggregate, Sort, Limit, Remove Duplicates o Summarize |
| Cron e Interval | Schedule Trigger |
| HTML Extract | HTML, operazione Extract HTML Content |
| iCalendar | Convert to File, operazione Convert to ICS |
| Read Binary File, Read Binary Files, Write Binary File | Read/Write Files from Disk |
| Read PDF | Extract from File, operazione Extract From PDF |
| Workflow Trigger | n8n Trigger |
| OpenAI legacy e OpenAI Assistant | OpenAI (risorsa Assistant per gli assistenti) |
| OpenAI Model | OpenAI Chat Model |
| HTTP Request Tool legacy | HTTP Request collegato all’ingresso Tool dell’AI Agent |
| Manual Chat Trigger | Chat Trigger |
| Nodi Insert e Load dei vector store | Simple, Pinecone o Supabase Vector Store, scegliendo l’operazione |
Alcuni nodi non hanno un sostituto diretto. LangChain Code, le memorie Motorhead e Zep e il vector store Zep vanno sostituiti con altri nodi supportati. Per SerpApi si usa il nodo HTTP Request come strumento verso la sua API REST, oppure un nodo della community verificato. Orbit sparisce perché il servizio ha chiuso.
Agenti AI: cosa cambia per chi automatizza con l’intelligenza artificiale
Chi usa n8n per costruire agenti AI deve controllare tre punti. La 3.0 elimina la versione 1 del nodo AI Agent e le sue vecchie modalità. Sono SQL Agent, Conversational Agent, OpenAI Functions Agent, Plan and Execute Agent e ReAct Agent. La versione attuale le sostituisce tutte con Tools Agent, e i workflow già impostati su Tools Agent continuano a funzionare allo stesso modo. Per i casi d’uso SQL n8n indica un sotto nodo strumento Postgres o MySQL collegato a un AI Agent recente.
Il nodo AI Transform non si può più aggiungere né eseguire. Il Migration Report lo converte in un nodo Code e conserva il JavaScript già generato, ma l’aggiornamento non fa questa conversione da solo. Se un AI Transform non ha mai generato codice, va sostituito a mano. Dal nodo Code sparisce anche la scheda Ask AI: il codice creato in passato resta e continua a girare.
Chat Hub viene spento di default: la sezione Chat sparisce dal menu, ma sessioni, agenti e messaggi restano nel database. Per tenerlo attivo nella 3.x aggiungi chat-hub alla variabile N8N_ENABLED_MODULES, senza togliere i moduli che hai già. La 4.0 lo eliminerà del tutto e n8n indica l’assistente e gli agenti come sostituti.
Impostazioni di sicurezza più severe
La rotazione della chiave di cifratura è attiva di default. I dati cifrati prima dell’aggiornamento restano leggibili e vengono ricifrati con la chiave corrente alla modifica successiva. Le credenziali Slack richiedono il signing secret: senza, i workflow con Slack Trigger non si pubblicano e quelli già pubblicati smettono di ricevere eventi. Il segreto si copia da Basic Information nelle impostazioni dell’app Slack e si incolla nel campo Signature Secret della credenziale, prima dell’aggiornamento.
I pacchetti della community non verificati sono disattivati: non si installano più da npm e quelli già installati smettono di caricarsi. Per mantenerli serve N8N_UNVERIFIED_PACKAGES_ENABLED=true, ma la strada più prudente è passare ai nodi verificati. Con la protezione SSRF attiva, la lista dei blocchi predefinita cresce di quattro intervalli di indirizzi. Uno è 100.64.0.0/10, lo spazio condiviso usato dal NAT dei fornitori di rete. Se i tuoi workflow chiamano host in quegli intervalli, aggiungili a N8N_SSRF_ALLOWED_IP_RANGES o N8N_SSRF_ALLOWED_HOSTNAMES.
Il nodo Compression accetta archivi fino a 256 MiB decompressi e 1.000 file, contro i 2 GiB e 5.000 file di prima. Il limite serve contro gli archivi costruiti per saturare la memoria. Se lavori con archivi più grandi, imposta N8N_COMPRESSION_NODE_MAX_DECOMPRESSED_SIZE_BYTES e N8N_COMPRESSION_NODE_MAX_ZIP_ENTRIES prima di aggiornare.
Timeout, code di lavoro e cartelle: le modifiche di configurazione
Il tempo massimo di un’attività del nodo Code scende da 5 minuti a 1 minuto. Le elaborazioni più lunghe falliscono. Se ne hai, imposta N8N_RUNNERS_TASK_TIMEOUT con il valore in secondi che ti serve. In modalità queue le esecuzioni manuali girano sempre sui worker: la variabile OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS sparisce e conviene rivedere la memoria assegnata ai worker.
Al primo avvio la 3.0 rinomina la cartella ~/.n8n/binaryData in ~/.n8n/storage. Se esistono entrambe, n8n si ferma con un errore. Chi monta un volume sul vecchio percorso deve spostarlo sul nuovo oppure impostare N8N_STORAGE_PATH. La modalità che teneva i file binari in memoria non esiste più e le istanze passano a filesystem. Il disco montato nel container deve quindi avere spazio sufficiente.
Spariscono anche le variabili N8N_DB_PING_TIMEOUT, sostituita da DB_PING_TIMEOUT_MS, N8N_WORKFLOW_TAGS_DISABLED e N8N_PRE_EXECUTE_ERROR_CREATES_EXECUTION. I tag dei workflow sono sempre attivi e quelli salvati in precedenza ricompaiono.
Comportamenti che cambiano senza errori
Alcune modifiche non bloccano nulla ma cambiano il risultato. Per questo sono le più difficili da notare. La prima riguarda l’opzione Always Output Data. Quando è attiva, i nodi con più uscite come If e Switch aggiungono un elemento vuoto solo quando tutte le uscite sono vuote. Prima lo aggiungevano a ogni uscita vuota e facevano partire rami che non dovevano partire.
Il Gmail Trigger nelle versioni da 1 a 1.3 si comporta come la 1.4. Legge al massimo 10 email per controllo (fino a 50 se lo imposti) e recupera le altre ai controlli successivi. Salta le bozze se non attivi il filtro Include Drafts. Le email inviate fuori dalla posta in arrivo e quelle programmate non avviano più il workflow.
Le versioni 1 e 1.1 del nodo Edit Image non funzionano più e il nodo va portato alla versione 2. Questa usa un’altra libreria grafica, quindi sfocature, testi sovrapposti e ridimensionamenti possono dare un risultato diverso. Le vecchie versioni del nodo Execute Sub-workflow perdono le sorgenti Local File e URL. Dall’editor sparisce l’importazione da URL, sostituibile con copia e incolla, importazione da file, CLI o API di n8n. Il widget di chat @n8n/chat va portato almeno alla versione 1.31.0 se lo incorpori tu.
Come funziona il Migration Report
Il Migration Report è lo strumento ufficiale per prepararsi. Compare dalla versione 2.39 in Settings > Migration Report. n8n consiglia di passare prima all’ultima 2.x, che contiene la versione più aggiornata del report. Analizza l’istanza e divide i problemi in due schede: Workflow issues per i singoli workflow e Instance issues per variabili d’ambiente e configurazione. La seconda la vedono solo proprietario e amministratori.
Ogni problema ha un livello di impatto. Ecco cosa significano e in che ordine affrontarli.
| Livello | Significato |
|---|---|
| Upgrade blocked | L’aggiornamento non può procedere o l’istanza potrebbe non avviarsi |
| Executions will fail | Workflow o istanza falliscono dopo l’aggiornamento |
| Executions might fail | Cambia un valore predefinito e le esecuzioni potrebbero fallire |
| Behavior changes | I workflow girano ma si comportano in modo diverso |
| Capability removed | Una funzione usata non esiste più, le esecuzioni non sono toccate |
Per alcuni problemi compare il pulsante Migrate, che riscrive i nodi in automatico. Il risultato viene salvato come nuova versione del workflow: quella pubblicata continua a girare finché non pubblichi la nuova. Testa sempre l’output, perché la migrazione automatica cambia i nodi ma non verifica i dati.
Il report suggerisce un responsabile per ogni workflow, di solito l’ultima persona che lo ha modificato, e con l’SMTP configurato può avvisarlo via email. I workflow obsoleti si segnano come Won’t fix: se un workflow non gira da oltre 12 mesi, un avviso propone di farlo. Il riepilogo si esporta in CSV per tenere traccia dell’avanzamento.
La procedura per aggiornare a n8n 3.0 senza fermare le automazioni
Mettendo insieme il blog e la documentazione di n8n, la sequenza consigliata è questa:
- aggiorna l’istanza all’ultima versione 2.x e apri il Migration Report;
- risolvi prima i problemi Upgrade blocked ed Executions will fail, poi gli altri livelli;
- migra o modifica i workflow segnalati e provali in un ambiente di sviluppo;
- sistema le variabili d’ambiente e la configurazione indicate nella scheda Instance issues;
- rilancia la scansione con Refresh e controlla che il numero di workflow compatibili sia uguale al totale;
- fai un backup completo di database, dati dell’istanza e chiave di cifratura;
- aggiorna prima un’istanza di test, poi quella di produzione.
Un report vuoto in entrambe le schede non chiude il lavoro. Lo strumento non rileva ogni modifica, quindi rileggi la pagina delle modifiche incompatibili per i casi che il report non vede. Uno riguarda i client di chat personalizzati collegati al WebSocket del Chat Trigger. Dalla 3.0 quel canale invia ogni messaggio come oggetto JSON con un campo type.
Il nostro consiglio
Non c’è motivo di installare la beta in produzione: la 2.x resta supportata per 12 mesi dopo l’uscita della stabile. Il momento giusto per il Migration Report invece è adesso, quando hai ancora settimane per correggere i workflow con calma. Fissa la versione dell’immagine Docker invece di usare il tag latest, così nessun riavvio ti porta alla 3.0 prima del previsto.
Le automazioni che gestiscono ordini, fatture o comunicazioni con i clienti hanno bisogno di qualcuno che le controlli a ogni aggiornamento. SBR Software si occupa di automazioni e di software su misura. Se vuoi una verifica dell’istanza n8n, il passaggio a Docker o la migrazione dei workflow, possiamo seguire l’aggiornamento al posto tuo.
