n8n 2.x sulla propria infrastruttura: diagnosticare i limiti dei dati di esecuzione e aumentare il payload in sicurezza

Un approfondimento aggiornato e orientato alla produzione che traduce la documentazione dei fornitori in controlli operativi, decisioni di migrazione e criteri di rilascio verificabili.

Cosa è cambiato nel 2026

Torniamo su questo tema perché il perimetro operativo è cambiato. I principi di fondo restano validi, ma le versioni attuali rendono alcune scorciatoie del passato incomplete o rischiose. Questo approfondimento parte dalla documentazione ufficiale disponibile al 14 luglio 2026, distingue i fatti dalle scelte locali e tratta ogni modifica di configurazione come un intervento controllato in produzione.

Fonti primarie aggiornate

• Dati di esecuzione di n8n
• Task runner di n8n
• Archiviazione esterna di n8n

Come utilizziamo questo aggiornamento

Partiamo dalle fonti primarie, registriamo le versioni realmente distribuite e definiamo il risultato osservabile prima di modificare qualsiasi impostazione. L’intervento reversibile più piccolo viene provato in un ambiente rappresentativo. Un comando eseguito con successo non è un criterio di accettazione: lo sono lo stato del servizio, l’integrità dei dati, la latenza, i confini di sicurezza e il tempo di rollback. La sequenza diagnostica ancora utile dell’articolo precedente viene mantenuta come base operativa; gli esempi legati a una versione devono comunque essere verificati nella documentazione corrente.

Prima del rilascio registriamo il diff di configurazione, un backup o un’istantanea di cui sia già stato verificato il ripristino almeno una volta e i comandi necessari per annullare l’intervento. Una persona osserva la prima finestra di produzione e un’altra autorizza l’escalation se gli indicatori concordati si muovono nella direzione sbagliata. Gli avvisi devono descrivere il rischio visibile per l’utente, non soltanto il componente che li ha emessi. Durante la finestra di verifica confrontiamo tassi di errore, profondità delle code, saturazione delle risorse, latenza di elaborazione e completezza dei dati con il riferimento iniziale concordato. Esaminiamo medie e code della distribuzione, perché una media stabile può nascondere errori che colpiscono una quota piccola ma importante del lavoro. La modifica viene chiusa solo dopo il completamento di job differiti, nuovi tentativi, attività pianificate ed esportazioni verso i sistemi a valle. Ogni azione manuale di recupero viene documentata: se manca dal manuale operativo, il manuale non è ancora completo. Questa disciplina di rilascio produce evidenze riutilizzabili al prossimo aggiornamento, evitando al team di dover ricostruire le stesse dipendenze.

• Guida completa 2025 alla risoluzione dei problemi di n8n gestito sulla propria infrastruttura: dimensione dei dati di esecuzione e webhook con Traefik
• Self-hosting di n8n su Hetzner Cloud: tutorial completo di configurazione Docker
• Più di cento container Docker: i nostri controlli mensili sullo stato dei servizi

Base operativa

Gestire n8n sulla propria infrastruttura offre esecuzioni illimitate dei flussi di lavoro e pieno controllo, ma i flussi complessi con grandi volumi di dati possono generare errori frustranti che devi risolvere nella configurazione del tuo server. Se durante il test dei singoli nodi compare il messaggio «Please execute the whole workflow, rather than just the node. (Existing execution data is too large.)», hai raggiunto il limite di dimensione del payload. Ti mostreremo come individuare e risolvere il problema e ottimizzare questo limite nelle installazioni n8n pronte per la produzione.

Il problema: quando i test dei flussi di lavoro non funzionano

Hai configurato correttamente la tua istanza n8n e reso affidabile il funzionamento dei webhook, ma ora stai creando flussi di lavoro più sofisticati che elaborano file, risposte API di grandi dimensioni o dataset. Quando esegui il flusso completo tutto funziona, ma appena provi a testare un singolo nodo o a eseguire solo una parte del flusso, n8n mostra il temuto messaggio di errore.

Questo accade perché n8n impone un limite predefinito di 16MB ai dati delle esecuzioni parziali: è sufficiente per i flussi semplici, ma diventa un collo di bottiglia quando inizi a elaborare volumi di dati reali.

Cosa risolverai

Al termine di questa guida avrai:

• ✅ Un limite di dimensione del payload aumentato da 16MB a 256MB o a un valore personalizzato

• ✅ Esecuzioni parziali funzionanti per flussi complessi con grandi dataset

• ✅ Un’allocazione adeguata delle risorse nel rispetto dei limiti di RAM del server

• ✅ Un sistema di monitoraggio per seguire nel tempo l’utilizzo della memoria

• ✅ Una configurazione pronta per la produzione che supporta i flussi di elaborazione dei file

• ✅ Procedure di backup e rollback per le modifiche alla configurazione

Prerequisiti

• Un’installazione n8n funzionante (preferibilmente seguendo la nostra guida alla configurazione su Hetzner)

• n8n in esecuzione in container Docker

• Accesso SSH al server

• Conoscenza di base delle variabili d’ambiente di Docker Compose

• Almeno 3 GB di RAM disponibile (consigliati per un limite del payload di 256MB)

Comprendere la causa principale

Perché n8n gestito sulla propria infrastruttura impone limiti ai payload

Quando esegui solo una parte del flusso (per testare singoli nodi), n8n deve serializzare e trasmettere al backend lo stato e i dati del flusso di lavoro. Sono inclusi:

• Tutti i dati in ingresso dai nodi precedenti

• La logica del flusso di lavoro e le configurazioni dei nodi

• Il contesto di esecuzione e le variabili

• I dati binari e il contenuto dei file

Il valore predefinito N8N_PAYLOAD_SIZE_MAX=16 (16 MiB; il valore è espresso in MiB) è stato pensato per le normali risposte API e per elaborazioni semplici. I flussi di lavoro moderni, però, spesso gestiscono:

❌ Situazioni comuni in cui si superano i 16MB:

• Caricamento ed elaborazione di file (PDF, immagini, fogli di calcolo)

• Risposte API di grandi dimensioni dalle fonti di dati

• Trasformazioni di dati in blocco

• Flussi di lavoro articolati in più passaggi che accumulano dati

✅ Cosa cambia dopo la correzione:

• Le esecuzioni parziali funzionano con grandi dataset

• È possibile testare i flussi di elaborazione dei file

• È possibile diagnosticare le trasformazioni complesse dei dati nodo per nodo

La configurazione mancante

La soluzione è la variabile d’ambiente N8N_PAYLOAD_SIZE_MAX, che imposta la dimensione massima del corpo della richiesta in MiB, inclusi i dati inviati dall’editor per le esecuzioni parziali. Quando una richiesta supera il limite, n8n risponde con HTTP 413 e l’editor mostra questo errore. Su n8n Cloud, n8n gestisce questa impostazione per te; le istanze gestite sulla propria infrastruttura usano il prudente valore predefinito di 16 MiB.

Passo 1: analizza la configurazione attuale

Verifica le risorse del server

Prima di aumentare i limiti dei payload, verifica che il server possa sostenere un’allocazione di memoria maggiore:

Requisiti di memoria:

• Limite del payload di 64MB: almeno 1GB di RAM disponibile

• Limite del payload di 128MB: almeno 2GB di RAM disponibile

• Limite del payload di 256MB: almeno 3GB di RAM disponibile

Individua il limite attuale

Verifica se N8N_PAYLOAD_SIZE_MAX è impostata nel file Compose. Se non lo è, n8n usa il valore predefinito di 16 MiB.

Riproduci la condizione di errore

Crea un flusso di lavoro di test per riprodurre il problema:

• Apri l’interfaccia di n8n

• Crea un flusso di lavoro con un grande dataset (ad esempio, un nodo HTTP Request verso un’API che restituisce >16MB)

• Prova a eseguire un solo nodo a valle

• Verifica che compaia l’errore «Existing execution data is too large»

Passo 2: risolvi il problema principale aumentando la dimensione del payload

Per una singola istanza n8n

Se hai una sola installazione n8n, esegui prima un backup di docker-compose.yml, poi modifica il file.

Aggiungi la variabile d’ambiente N8N_PAYLOAD_SIZE_MAX alla configurazione esistente. Il valore è espresso in MiB, quindi N8N_PAYLOAD_SIZE_MAX=256 imposta un limite di 256 MiB.

Per più istanze n8n

Se usi più istanze n8n, aggiornale tutte. Il limite si applica a ciascuna istanza.

Riavvia i container

Applica le modifiche ricreando i container con docker compose down e docker compose up -d; docker compose restart non applica i valori modificati delle variabili d’ambiente.

Passo 3: verifica la correzione

Controlla i log dei container

Verifica che i container si siano avviati correttamente controllando i log per individuare eventuali errori.

Verifica l’aumento della dimensione del payload

Torna al flusso di lavoro di test che generava l’errore:

• Apri il flusso di lavoro con il grande dataset

• Prova a eseguire un singolo nodo a valle

• Verifica che l’errore «Existing execution data is too large» non compaia più

• Conferma che le esecuzioni parziali funzionino correttamente

Monitora l’utilizzo della memoria

Controlla le risorse del sistema dopo la modifica, per esempio con free -h e docker stats.

Passo 4: ottimizza in base al server

Dimensioni dei payload consigliate in base alla RAM del server

Scegli la dimensione del payload adatta al tuo hardware. Come punto di partenza: 64 MiB per server con 2 GB di RAM o meno, 128 MiB per 4 GB, 256 MiB per 8 GB e 512 MiB per 16 GB o più.

Calcolo dell’utilizzo della memoria

Stima il fabbisogno di memoria: mantieni il limite del payload al di sotto del 20% della RAM disponibile e osserva l’utilizzo effettivo della memoria durante le esecuzioni di flussi di lavoro con grandi quantità di dati.

Risoluzione dei problemi comuni

Problema: il container non si avvia dopo la modifica della configurazione

Sintomi:

• Il container termina immediatamente dopo l’avvio

• Stato «OOMKilled» in Docker

• Il server non risponde più

Soluzione: Controlla nei log del container il motivo dell’arresto. Se il container ha esaurito la memoria, riduci N8N_PAYLOAD_SIZE_MAX (per esempio da 256 a 64) e avvialo di nuovo.

Problema: gli errori di dimensione del payload persistono

Sintomi:

• L’errore persiste dopo la modifica della configurazione

• La variabile d’ambiente sembra non avere effetto

Soluzione: Verifica il valore all’interno del container con docker exec e env. Se manca, ricrea il container con docker compose up -d --force-recreate.

Problema: peggioramento delle prestazioni del server

Sintomi:

• Tempi di risposta più lunghi

• Utilizzo elevato della memoria

• Utilizzo crescente del file di swap

Soluzione: Controlla l’utilizzo della memoria, l’I/O del disco e lo swap. Se necessario, riduci N8N_PAYLOAD_SIZE_MAX (per esempio da 256 a 128) e ricrea il container.

Configurazione avanzata

Istanze separate per dimensioni del payload diverse

Il limite si applica a ciascuna istanza n8n, non al singolo flusso di lavoro. Gli utenti esperti possono valutare istanze separate con limiti diversi, per esempio un’istanza ad alta capacità per l’elaborazione dei file e una standard per i flussi di lavoro ordinari.

Limiti delle risorse dei container

Imposta limiti di memoria espliciti nella sezione deploy.resources di Compose per evitare il sovraccarico del sistema. Una riserva di memoria è un limite flessibile, non una garanzia.

Monitoraggio dell’utilizzo dei payload

n8n non riporta direttamente la dimensione del payload, quindi configura gli avvisi sull’utilizzo della memoria dei container, per esempio con uno script che legge docker stats.

Aspetti di sicurezza

Protezione dai DoS basati sull’esaurimento delle risorse

Limiti elevati dei payload possono essere sfruttati per attacchi. Limita la dimensione delle richieste sul reverse proxy e mantieni questo limite almeno pari a N8N_PAYLOAD_SIZE_MAX, in modo che le richieste legittime non vengano rifiutate con HTTP 413.

Limiti specifici per flusso di lavoro

Valuta restrizioni in base al flusso di lavoro, per esempio registrando quali flussi producono esecuzioni con grandi quantità di dati.

Ottimizzazione delle prestazioni

Gestione dei dati binari

Per i flussi di elaborazione dei file, archivia i dati binari su disco con N8N_DEFAULT_BINARY_DATA_MODE=filesystem anziché in memoria. n8n non supporta la modalità filesystem con la modalità coda; per quest’ultima, la documentazione raccomanda la modalità database.

Ottimizzazione del database

I payload di grandi dimensioni possono influire sulle prestazioni del database. Monitora la crescita del database ed elimina più aggressivamente le vecchie esecuzioni con EXECUTIONS_DATA_MAX_AGE e EXECUTIONS_DATA_PRUNE_MAX_COUNT.

Backup e ripristino

Strategia di backup della configurazione

Esegui sempre un backup di docker-compose.yml prima di apportare modifiche, inserendo data e ora nel nome del file.

Procedura rapida di rollback

Se devi annullare le modifiche, ripristina uno specifico file di backup, poi esegui docker compose down e docker compose up -d.

Impatto sui costi e sulle prestazioni

Analisi dei costi della memoria

L’aumento dei limiti dei payload incide sui costi del server, perché limiti più elevati richiedono più RAM.

Vantaggi per le prestazioni

Limiti più alti dei payload consentono:

• Elaborazione dei file: gestire documenti, immagini e video

• Integrazione dei dati: elaborare risposte API di grandi dimensioni

• Operazioni in blocco: trasformare i dataset in modo efficiente

• Diagnostica: testare flussi di lavoro complessi nodo per nodo

Conclusione

Aumentare N8N_PAYLOAD_SIZE_MAX dal valore predefinito di 16MB a un valore adatto al server consente di usare funzionalità avanzate dei flussi di lavoro che prima non erano disponibili nelle esecuzioni parziali. Il limite di 256MB che abbiamo configurato copre molto bene la maggior parte dei casi reali, mantenendo la stabilità del server.

Principali vantaggi di questa configurazione

• Produttività: diagnosticare flussi di lavoro complessi nodo per nodo con molti meno vincoli di dimensione

• Funzionalità: elaborare file e grandi dataset in modo efficiente

• Convenienza: elaborare insiemi di dati più grandi su un server con risorse modeste gestito sulla propria infrastruttura

• Affidabilità: configurazione testata in produzione con una gestione adeguata delle risorse

• Scalabilità: adeguare facilmente i limiti all’aumentare della complessità dei flussi di lavoro

Questa configurazione si basa sulla nostra guida originale alla configurazione di n8n e sulla guida alla risoluzione dei problemi dei webhook, per creare una piattaforma di automazione completa, pronta per la produzione e capace di gestire flussi di elaborazione dei dati di livello aziendale.

Per payload con volumi elevati o requisiti particolari, valuta una consulenza con esperti di automazione per ottimizzare il tuo caso d’uso e assicurare un’allocazione ottimale delle risorse del server.

Dalla configurazione alla decisione operativa

La domanda pratica non è se una piattaforma possa essere configurata. È se il team sappia chiarire le responsabilità, rilevare gli scostamenti, ripristinare il servizio senza improvvisare e dimostrare che la modifica ha migliorato il risultato previsto. Per questo associamo ogni modifica a un responsabile, un riferimento iniziale, un percorso di rollback e una finestra di verifica. Una correzione isolata diventa così una capacità operativa. La documentazione di produzione deve includere il motivo della modifica, le evidenze esaminate, l’ambito esatto e la persona autorizzata a interrompere o annullare l’intervento. Dopo il rilascio, confronta gli indicatori concordati con il riferimento iniziale e conserva il risultato insieme alla documentazione della modifica. Se il miglioramento atteso non si verifica, il rollback è un esito valido, non un fallimento. Questa disciplina conta più di qualsiasi singolo valore di configurazione. La stessa documentazione offre a chi gestirà il sistema in seguito un punto di partenza affidabile e rende le ottimizzazioni future decisioni basate su misurazioni anziché un nuovo ciclo di tentativi.

Approfondimenti correlati

• Ripristino di emergenza per servizi gestiti sulla propria infrastruttura: la nostra strategia di backup
• La scelta del self-hosting: quando il SaaS costa più della propria infrastruttura
• Il problema dell’idoneità dei dati all’uso nell’IA aziendale