Requisiti del server n8n

Quanta macchina serve davvero a un'istanza n8n self-hosted, cosa aggiunge il database e il punto in cui una sola istanza non basta più. La maggior parte delle linee guida di dimensionamento che trovi online è scritta per la modalità coda, che la maggior parte delle persone non usa mai, quindi sembra un requisito molto più grande di quello che è.

La risposta breve

Un'istanza singola di n8n che esegue workflow normali non è un software particolarmente esigente. Due vCPU e 2 GB di RAM fanno girare comodamente un carico reale di lavori pianificati, webhook e chiamate API, perché n8n passa gran parte del tempo ad aspettare i servizi altrui invece di calcolare. Il processo principale di n8n occupa circa 300 MB a riposo.

Ciò che fa davvero salire il numero non è quanti flussi hai definito. È quanti dati una singola esecuzione tiene in memoria contemporaneamente, e quante esecuzioni girano in parallelo.

Cosa consuma memoria in n8n

n8n passa i dati tra i nodi come elementi tenuti in memoria per tutta la durata dell'esecuzione. Questo ha una conseguenza importante per il dimensionamento: un flusso che recupera diecimila righe e le mappa attraverso cinque nodi è un inquilino molto più pesante di cento flussi che spostano ciascuno un payload di webhook.

• Dimensione del payload per esecuzione. Risposte HTTP grandi, import di fogli di calcolo e file binari sono la causa più comune di un'istanza che prima funzionava e a un certo punto non funziona più.
• Concorrenza. Dieci esecuzioni in corso contemporaneamente occupano ciascuna il proprio working set. Una pianificazione che lancia più flussi nello stesso minuto è un picco che non avevi previsto.
• Cronologia delle esecuzioni. I dati salvati delle esecuzioni si accumulano nel database. È una questione di disco e database più che di RAM, ma è la cosa che cresce in silenzio per mesi e poi conta.

L'implicazione pratica: se elabori payload grandi, spezzali. Suddividere un grande dataset in blocchi fa più per la stabilità di qualsiasi quantità di RAM extra, perché cambia il picco invece di alzare il tetto.

Il database è un requisito, non un'ottimizzazione

n8n usa SQLite per default, che va bene per una prova e un'idea pessima in produzione. Gestisce male le esecuzioni concorrenti ed è scomodo da sottoporre a backup e ripristinare in modo affidabile. PostgreSQL è la risposta per la produzione e non è gratis in termini di risorse: prevedi circa da 500 MB a 1 GB per lui, che cresce con la cronologia delle esecuzioni.

È il numero che la maggior parte delle guide al dimensionamento mette silenziosamente nella stessa casella di n8n. Su un VPS fai da te esce dalla stessa RAM dei tuoi flussi, insieme al runtime del container, a un reverse proxy e al sistema operativo. Sui nostri piani il cluster PostgreSQL è un componente ad alta disponibilità separato con la sua memoria, quindi la RAM nel nome del piano è RAM per n8n.

CPU: di solito non è il collo di bottiglia

n8n è dominato dall'attesa. Un'esecuzione passa il suo tempo in andata e ritorno di rete verso le API, non in calcolo, quindi due core bastano e avanzano. Le eccezioni esistono ma sono specifiche: trasformazioni di dati pesanti nei nodi Code, parsing di JSON grandi e flussi AI che fanno lavoro locale significativo invece di chiamare un'API di modelli. Se i tuoi flussi sono per lo più integrazioni, aggiungi RAM prima dei core.

Quando ti serve la modalità coda

Di default n8n fa girare tutto in un unico processo. La modalità coda lo divide: un'istanza principale accetta i trigger e passa le esecuzioni a processi worker separati tramite Redis, così il processo principale resta reattivo indipendentemente da quanto dura un job. È la risposta standard per scalare n8n, ed è anche il motivo per cui la maggior parte dei consigli di dimensionamento pubblicati sembra così pesante.

Ti serve solo quando una di queste condizioni è vera, e non prima:

• Le esecuzioni lunghe bloccano quelle brevi. Un flusso che impiega cinque minuti farà attendere un webhook in arrivo dietro di sé in modalità a processo singolo. In modalità coda l'istanza principale conferma subito e un worker esegue il lavoro.
• Vedi un accumulo evidente. Il segnale più chiaro sono le esecuzioni ferme in stato di attesa per più di qualche secondo nell'interfaccia di n8n. Significa che si sta formando una coda, e nessuna quantità di RAM extra su un singolo processo la elimina.
• Un solo job pesante può trascinare giù l'intera istanza. L'isolamento è spesso la vera motivazione, più che la produttività.

La modalità coda aggiunge due cose ai tuoi requisiti. Redis, che è piccolo, intorno a 128 MB, ma è un altro componente da gestire, e la RAM per worker: ogni processo worker consuma circa da 200 a 500 MB a seconda di cosa trasportano i tuoi flussi. Due worker è il punto di partenza sensato, e ne aggiungi altri solo quando il backlog lo indica. I worker hanno bisogno di RAM molto più che di core, ed è per questo che il normale percorso di scaling aggiunge memoria due o tre volte prima di aggiungere CPU.

Detto onestamente: una distribuzione in modalità coda con più worker richiede un componente Redis e più memoria di quella che offrono i piani sopra, quindi non è per questo che sono pensati questi piani. Sono istanze n8n singole con un database ad alta disponibilità, che è ciò che la grande maggioranza delle istanze self-hosted è davvero. Se hai misurato un accumulo e ti servono davvero dei worker, sei cresciuto oltre una distribuzione con un clic e dovresti dimensionare uno stack dedicato.

Storage, e la cosa che cresce

n8n stesso richiede pochissimo disco. Ciò che cresce è la cronologia delle esecuzioni, e cresce in proporzione a quante volte girano i flussi, non a quanti ne hai. Un flusso che interroga un'API ogni dieci minuti produce da solo circa 4,300 esecuzioni al mese. Elimina i dati salvati delle esecuzioni secondo una policy di conservazione invece di aspettare che sia il disco a decidere per te, e conserva le esecuzioni fallite più a lungo di quelle riuscite, perché sono le uniche che leggerai mai.

Requisiti che non sono hardware

Due di loro contano più di qualsiasi specifica. I webhook richiedono un URL HTTPS pubblico e stabile, cioè un dominio reale, un certificato valido e un reverse proxy davanti a n8n; un'istanza self-hosted senza questo può far girare le pianificazioni ma non può ricevere nulla. E una piattaforma di automazione deve essere attiva quando scatta il trigger, cosa che esclude un laptop e rende l'uptime un requisito nello stesso senso in cui lo è la RAM.

Domande frequenti