n8n self hosted: come aggiornare Docker e Compose senza perdere dati

Questa guida è per chi ha n8n self hosted in un container Docker, avviato con docker run oppure con Docker Compose. Se la versione in uso rientra fra quelle indicate nell’alert del CSIRT Italia dell’1 ottobre 2026, l’istanza va aggiornata. Senza un backup, rischi di perdere workflow e credenziali.

Si parte annotando la versione in uso. Poi si fa il backup, si sceglie il tag dell’immagine, si aggiorna e si controlla il risultato. Alla fine trovi come tornare indietro. I comandi sono quelli della documentazione ufficiale di n8n, elencata in fondo.

Cosa serve

• Un’istanza di n8n che gira in Docker, con i dati nel volume n8n_data montato su /home/node/.n8n, come negli esempi ufficiali.
• Docker Desktop, disponibile per Windows, macOS e Linux, che comprende Docker Engine e Docker Compose. Su Linux, per le macchine senza ambiente grafico, Docker Engine e Docker Compose esistono anche come pacchetti separati.
• Un terminale: PowerShell o il prompt dei comandi su Windows, il Terminale su macOS. Con Docker Desktop i comandi sono gli stessi. Dove tenga i volumi su Windows e macOS, le fonti consultate non lo indicano.
• Il comando docker run usato all’installazione oppure la cartella con il file compose.yaml.
• Gli strumenti di PostgreSQL per il backup del database, se l’istanza usa Postgres al posto di SQLite.

La documentazione di n8n su Docker raccomanda il self hosting solo a chi è esperto. Avverte che un errore può causare perdita di dati, problemi di sicurezza e interruzioni del servizio.

Perché aggiornare: l’alert del CSIRT Italia

L’alert AL07/261001/CSIRT-ITA è stato pubblicato l’1 ottobre 2026 e aggiornato il 2 ottobre 2026 con l’aggiunta di due CVE. Segnala nuove vulnerabilità in n8n, 13 di gravità alta. Chi le sfrutta può ottenere informazioni riservate, aggirare sicurezza e autenticazione o eseguire codice arbitrario. Le 13 CVE di gravità alta vanno da CVE-2026-103246 a CVE-2026-103259, esclusa la CVE-2026-103258.

Le versioni affette sono:

• tutte quelle precedenti alla 1.123.80;
• quelle dalla 2.0.0 alla 2.39.5;
• la 2.40.0.

L’alert non indica la versione corretta. Rimanda ai bollettini di sicurezza di n8n, cioè alle Security Advisories del repository n8n-io/n8n su GitHub, dove va letta la versione minima da installare. Al 18 ottobre 2026 la documentazione di n8n indica come stabile la 2.43.7, che non rientra negli intervalli dell’alert.

Controllare Docker e la versione di n8n che gira

Prima di toccare qualcosa annota la versione di n8n, il nome del container e il suo ID: ti servono per capire se l’istanza è vulnerabile e per tornare indietro.

1. Controlla che Docker risponda:

docker --version

2. Se usi Compose, controlla che sia disponibile:

docker compose version

3. Elenca tutti i container, compresi quelli fermi. Quello di n8n ha l’immagine n8nio/n8n. Annota le colonne CONTAINER ID e NAMES, e anche il tag dell’immagine se ce n’è uno.

docker ps -a

Su Linux, se il tuo utente non fa parte del gruppo docker, devi mettere sudo davanti ai comandi, come fa la documentazione di n8n su Docker Compose.

Per leggere la versione di n8n la documentazione non indica un comando: si legge nell’interfaccia, come spiega la pagina di n8n sull’assistenza. Apri il pannello a sinistra, scegli Help e poi About n8n. Con Copy debug information copi i dati dell’istanza e li salvi nelle tue note.

Fare il backup: volume, chiave di cifratura e database

Il volume n8n_data contiene la cartella .n8n. Lì n8n salva il file del database SQLite e la chiave di cifratura delle credenziali. Se usi PostgreSQL, il database sta in Postgres, ma la cartella .n8n resta necessaria: contiene la chiave, i log dell’istanza e i file del controllo di versione.

1. La chiave di cifratura. Se l’hai impostata con N8N_ENCRYPTION_KEY, trovi il valore nel comando docker run o nella configurazione di Compose. Copialo in un posto sicuro, fuori dal server. Senza questa chiave le credenziali salvate non si possono più decifrare.
2. Il volume n8n_data. Con SQLite devi fermare n8n prima di copiare la cartella. Se la copi mentre n8n scrive sul database, il backup può risultare incoerente. La procedura completa è nella pagina Back up and restore, collegata alla pagina sull’aggiornamento.
3. Il database PostgreSQL, se lo usi. Va salvato con gli strumenti di Postgres. La documentazione di n8n non riporta i comandi.
4. Il resto dei dati. Se i dati binari o di esecuzione stanno su uno storage esterno, come S3 o Azure Blob Storage, o su un percorso personalizzato del filesystem, salva anche quelli. Lo stesso vale per le directory dei nodi personalizzati indicate in N8N_CUSTOM_EXTENSIONS: senza, un’istanza ripristinata perde i nodi usati dai workflow.

n8n raccomanda di fare un backup completo prima di ogni aggiornamento. Se l’aggiornamento non va a buon fine, è questo backup che ti permette di tornare indietro.

Esportare workflow e credenziali con la CLI di n8n

L’esportazione con la CLI produce file JSON con workflow e credenziali. Non contiene utenti, cronologia delle esecuzioni, variabili e impostazioni, quindi non sostituisce il backup della sezione precedente.

Secondo la documentazione della CLI di n8n, con Docker il comando n8n si esegue dentro il container con l’utente node. Si scrive docker exec -u node -it, poi il nome del container e infine il comando. Al posto di <n8n-container-name> metti il valore della colonna NAMES annotato prima. Il container deve essere in esecuzione.

Workflow e credenziali vanno in cartelle diverse. Se una cartella contiene anche file di workflow, import:credentials --separate fallisce: è un problema noto. Questo comando esporta tutti i workflow nella cartella backups/latest/, uno per file:

n8n export:workflow --backup --output=backups/latest/

Le credenziali esportale in un’altra cartella, con il comando della pagina Back up and restore: n8n export:credentials --backup --output=backups/credentials/. Restano cifrate, quindi senza la chiave non servono.

L’opzione --backup equivale a --all --pretty --separate: esporta tutto, in un formato leggibile, con un file per ogni elemento. Attenzione: la cartella backups/ è dentro il container, non nel volume: se rimuovi il container, sparisce con lui. Prima di aggiornare copia i file sulla macchina host, oppure monta una cartella dell’host per i backup.

Scegliere il tag dell’immagine: latest o versione fissata

L’immagine ufficiale si chiama n8nio/n8n. Se non indichi un tag, viene scaricata latest:

docker pull n8nio/n8n

Per fissare una versione, dopo il nome dell’immagine scrivi i due punti e il numero, nella forma n8nio/n8n:NUMERO. Al posto di NUMERO metti una versione uguale o successiva a quella corretta indicata nel bollettino di n8n. Con una versione fissata sai sempre cosa gira, ma a ogni aggiornamento il numero va cambiato a mano. Con Compose il tag si cambia nella riga image del file compose.yaml.

n8n pubblica una nuova versione minore quasi ogni settimana. La stabile è quella per la produzione. La beta è il rilascio più recente e può essere instabile: al 18 ottobre 2026 è la 2.44.3.

Aggiornare un container avviato con docker run

Con docker run, aggiornare vuol dire creare un nuovo container dalla nuova immagine e collegarlo allo stesso volume.

1. Scarica la nuova immagine. Se vuoi una versione fissata, aggiungi il tag come spiegato sopra.

docker pull n8nio/n8n

2. Trova l’ID del container di n8n nella colonna CONTAINER ID, sulla riga con l’immagine n8nio/n8n:

docker ps -a

3. Ferma il container con docker stop e rimuovilo con docker rm, ognuno seguito dall’ID. Nella documentazione al posto dell’ID c’è il segnaposto <container_id>: sostituiscilo con il valore letto al punto 2. Attenzione: docker rm cancella il container e tutto quello che c’è dentro fuori dal volume, comprese le esportazioni che non hai copiato. Il volume n8n_data resta. Se sbagli ID cancelli un altro container, quindi prima controlla che su quella riga ci sia l’immagine n8nio/n8n.
4. Ricrea il container con le stesse opzioni dell’installazione: stesso nome, stesse variabili d’ambiente (fuso orario e, se c’era, N8N_ENCRYPTION_KEY), stesso volume -v n8n_data:/home/node/.n8n. L’immagine nel comando deve essere quella appena scaricata, con lo stesso tag. Se il comando originale aveva un tag fissato vecchio, sostituiscilo con n8nio/n8n:NUMERO, usando la versione scelta. Se lasci il tag vecchio, riparte la vecchia versione anche se hai scaricato quella nuova.

Con Docker Desktop l’immagine si scarica anche dall’interfaccia: nella scheda Images apri il menu della riga e scegli Pull. Dopo il download vanno comunque eseguiti i punti 2-4.

Aggiornare con Docker Compose

Nome del container, variabili e volumi sono già nel file. Spostati nella cartella che contiene compose.yaml, che negli esempi della documentazione si chiama n8n-compose. Se vuoi fissare la versione, cambia prima il tag nella riga image.

1. Scarica le immagini aggiornate:

docker compose pull

Il comando successivo ferma e rimuove i container dello stack: nella configurazione della documentazione sono n8n e Traefik. I volumi non vengono toccati, ma tutto quello che è dentro i container e fuori dai volumi va perso. Il comando agisce sullo stack della cartella in cui ti trovi. Prima di lanciarlo controlla che lì ci sia il compose.yaml di n8n e che i file esportati siano già sull’host.

2. Ferma e rimuovi la versione in uso:

docker compose down

3. Riavvia lo stack in background con la nuova immagine:

docker compose up -d

Verificare dopo l’aggiornamento

1. Controlla che il container di n8n sia attivo nella colonna STATUS e che l’immagine abbia il tag che ti aspetti:

docker ps -a

2. Rileggi la versione da Help e About n8n. Deve essere uguale o superiore a quella corretta indicata nel bollettino di n8n.
3. Esegui un workflow che usa delle credenziali. Se funziona, n8n sta leggendo la chiave di cifratura.
4. Lancia il controllo di sicurezza integrato, che cerca i problemi più comuni. Va eseguito dentro il container con docker exec, come l’esportazione:

n8n audit

Salti tra versioni principali

Per passare da una 1.x a una 2.x non basta cambiare immagine. La pagina di n8n sull’aggiornamento chiede di leggere le note di rilascio, dove sono elencate le modifiche incompatibili, e di provare l’aggiornamento prima su un’istanza di test. Consiglia anche di aggiornare almeno una volta al mese, per non dover saltare molte versioni in una volta. Fra le modifiche di n8n 2.0, la documentazione cita queste:

• N8N_RUNNERS_ENABLED è deprecata e non serve più (nella 1.x andava impostata a true per attivare i task runner);
• l’interruttore attivo/inattivo dei workflow è stato sostituito dal modello pubblica/ritira, e il comando update:workflow è deprecato.

Se qualcosa va storto

Per tornare indietro da un aggiornamento fallito non basta rimettere il vecchio tag: serve la procedura di ripristino completa della pagina Back up and restore.

1. Ferma n8n. Con Compose, dalla cartella del file compose.yaml, il comando è il seguente. Rimuove i container dello stack ma non i volumi, quindi controlla di essere nella cartella giusta.

docker compose down

2. Ripristina la cartella .n8n nel volume n8n_data, più le eventuali directory dei nodi personalizzati indicate in N8N_CUSTOM_EXTENSIONS. Se usi PostgreSQL, ripristina anche il database dal suo backup.
3. Ripristina la configurazione: variabili per la connessione al database, N8N_ENCRYPTION_KEY se la usi e impostazioni dello storage esterno. Nella riga image rimetti il tag della versione annotata all’inizio.
4. Riavvia n8n:

docker compose up -d

Con docker run i passaggi sono gli stessi. Fermi e rimuovi il container con l’ID, poi lo ricrei con il tag della versione precedente.

Se mancano dei workflow, li puoi reimportare dentro il container con docker exec. Prima ricopia i file esportati nel container, nella stessa cartella. L’importazione conserva gli ID: se nel database ci sono già workflow con lo stesso ID, vengono sovrascritti. Per evitarlo, cancella o cambia gli ID prima di importare.

n8n import:workflow --separate --input=backups/latest/

Per le credenziali usa la loro cartella separata, cioè n8n import:credentials --separate --input=backups/credentials/. L’istanza deve avere la stessa chiave di cifratura di quella che le ha esportate. Altri comportamenti segnalati dalla documentazione della CLI:

• import:workflow disattiva tutti i workflow importati, che poi vanno riattivati dall’interfaccia;
• c’è un bug noto: sulle istanze che non sono in modalità multi-main, i trigger cron dei workflow che erano attivi continuano a girare finché non riavvii n8n;
• in SQLite i nomi più lunghi di 128 caratteri possono dare errori come «Data too long for column name». In quel caso accorcia i nomi dall’interfaccia ed esporta di nuovo, oppure modifica i file JSON.

Se dopo il riavvio l’istanza non si raggiunge, la documentazione su Compose indica di controllare il firewall del server e la configurazione DNS. La variabile N8N_WEBHOOK_URL esiste da n8n 2.30.0: nelle versioni precedenti si usa WEBHOOK_URL.

Installazione da zero, npm, n8n Cloud e reverse proxy restano fuori da questa guida: per questi casi si rimanda alla documentazione ufficiale di n8n.

Documentazione di riferimento

Pagine consultate il 18 ottobre 2026. La pagina su Docker Compose è scritta per server Linux.

• Documentazione di n8n: installazione e aggiornamento con Docker
• Documentazione di n8n: Docker Compose
• Documentazione di n8n: aggiornare n8n self-hosted (con il collegamento a Back up and restore)
• Documentazione di n8n: comandi CLI (esportazione, importazione, audit)
• Documentazione di n8n: dove trovare aiuto (Help, About n8n)
• CSIRT Italia/ACN: alert AL07/261001/CSIRT-ITA, Rilevate vulnerabilità in n8n

Leggi anche

• Vaultwarden Docker Compose con HTTPS: installarlo su Linux con Caddy
• Forgejo Docker Compose: come installarlo su un server di casa
• Installare Docker su Ubuntu con il plugin Compose, passo passo