Come fare self-hosting di n8n nel 2026: deploy, TLS, webhook e backup

Un container n8n può risultare attivo mentre il processo che interessa agli utenti è interrotto. In n8n, questo errore nascosto consiste di solito nel fatto che i link webhook continuano a puntare a localhost oppure che gli header del proxy indicano HTTP. Questa guida considera come test di accettazione “attivare un workflow con un webhook di produzione, chiamare quel webhook dall'esterno del server e confermare che l'esecuzione raggiunga il nodo finale” e costruisce il deployment a ritroso partendo da questo risultato.

n8n ha un ruolo specifico nello stack: l'automazione dei workflow con oltre 400 integrazioni e un sistema di nodi estensibile. La domanda in produzione non è quindi se la porta 5678 risponde una volta, ma se stato, dipendenze e indirizzo pubblico continuano a essere coerenti dopo un riavvio, un aggiornamento e un ripristino.

Separa i container sostituibili dai dati persistenti

Definisci il recovery point e il recovery time di n8n in termini di database e dati di crittografia e configurazione di .n8n. Monta /home/node/.n8n prima del bootstrap, scrivi dati di esempio innocui e sostituisci il container per dimostrare che quel percorso è effettivamente persistente. Un volume denominato risolve la persistenza durante il redeploy; non risolve però una compromissione o la perdita del server.

Prepara un ambiente di restore pulito, usa la stessa versione applicativa fissata e dimostra che le credenziali ripristinate vengono ancora decrittografate e che un workflow ripristinato riceve lo stesso URL webhook pubblico. Registra comandi, correzioni dei permessi e tempo trascorso. La guida ai backup è uno standard utile: un backup è affidabile dopo il ripristino, non dopo l'upload.

Rendi riproducibile l'avvio di n8n

Un comando minimale è utile quando mostra cosa dovrà gestire in seguito la piattaforma.

docker run -d \
  --name n8n \
  --restart unless-stopped \
  -p 127.0.0.1:5678:5678 \
  -v n8n-data:/home/node/.n8n \
  -e N8N_ENCRYPTION_KEY=replace-with-a-long-random-value \
  docker.n8n.io/n8nio/n8n

Qui la porta 5678 rimane privata sull'host e ogni percorso richiesto è esplicito. Aggiungi le impostazioni di connessione verificate per Postgres per una configurazione di produzione durevole e multiutente; usa nomi privati per i servizi privati. Verifica l'avvio sia tramite i log sia con la verifica specifica dell'applicazione: attiva un workflow con un webhook di produzione, chiama quel webhook dall'esterno del server e conferma che l'esecuzione raggiunga il nodo finale. Dopo la verifica, blocca la versione dell'immagine per evitare che una sostituzione ordinaria modifichi il comportamento senza che tu te ne accorga.

Porte, processi e servizi privati

Inizia dal network namespace di n8n: il suo web listener è sulla porta 5678, non su una porta dell'host copiata da un tutorial per laptop. Il contratto di rete per n8n prevede Postgres per una configurazione di produzione durevole e multiutente. Mantieni gli endpoint privati sul DNS interno, consenti solo le chiamate in uscita necessarie e assegna a n8n credenziali di servizio con scope limitato.

Dopo aver soddisfatto il requisito, esegui lo scenario completo — attiva un workflow con un webhook di produzione, chiama quel webhook dall'esterno del server e conferma che l'esecuzione raggiunga il nodo finale. Registra log e metriche per la concorrenza delle esecuzioni, la profondità della coda, la dimensione dei payload binari e i nodi di lunga durata, invece delle visualizzazioni delle pagine dell'editor. Queste evidenze diventano la prima architettura nota come funzionante e rendono verificabili gli spostamenti successivi tra il compute di Dockup e un server collegato.

Impedisci che il successo del proxy mascheri un errore dell'applicazione

Il confine pubblico per n8n dovrebbe essere un unico hostname canonico, TLS automatico e un unico target interno sulla porta 5678. Imposta WEBHOOK_URL sull'esatto URL HTTPS esterno, così i client tornano a un indirizzo riconosciuto dal servizio.

Se la transazione di accettazione fallisce, classifica il primo errore. I problemi di DNS, certificato e 502 rientrano nella checklist di validazione TLS. La condizione “i link webhook continuano a puntare a localhost oppure gli header del proxy indicano HTTP” appartiene al lato applicativo, dopo che una richiesta ha raggiunto correttamente n8n.

Cosa deve superare i controlli prima che arrivino dati n8n reali

Trasforma lo smoke test di n8n in un comando di release ripetibile o in un breve runbook. Il suo output deve dimostrare questo risultato: attivare un workflow con un webhook di produzione, chiamare quel webhook dall'esterno del server e confermare che l'esecuzione raggiunga il nodo finale. Registra insieme al risultato la versione dell'applicazione, il digest del container, l'hostname della route e l'identificativo dei dati di test.

Esegui lo stesso controllo dopo una sostituzione ordinaria del container e dopo aver ripristinato il database e i dati di crittografia e configurazione di .n8n altrove. Il restore è riuscito quando le credenziali ripristinate vengono ancora decrittografate e un workflow ripristinato riceve lo stesso URL webhook pubblico. Confronta tempi e consumo relativi alla concorrenza delle esecuzioni, alla profondità della coda, alla dimensione dei payload binari e ai nodi di lunga durata, invece delle visualizzazioni delle pagine dell'editor; una variazione significativa merita un'indagine anche quando l'azione finale continua ad avere esito positivo.

Poi esegui un errore controllato: nega temporaneamente all'identità di test l'accesso a Postgres per una configurazione di produzione durevole e multiutente. Conferma che n8n segnali il problema e torni alla normalità senza modifiche manuali distruttive. Conserva solo l'estratto di log necessario e con i dati sensibili rimossi. Questo gate in quattro parti copre avvio, persistenza, recovery e gestione degli errori.

Verifiche di capacità e aggiornamento

Costruisci dashboard basate sulla concorrenza delle esecuzioni, sulla profondità della coda, sulla dimensione dei payload binari e sui nodi di lunga durata, invece che sulle visualizzazioni delle pagine dell'editor. Un grafico della CPU privo del contesto del carico di lavoro non può spiegare perché n8n sia lento. Aggiungi un controllo sintetico o pianificato che provi ad attivare un workflow con un webhook di produzione, a chiamare quel webhook dall'esterno del server e a confermare che l'esecuzione raggiunga il nodo finale usando dati di test innocui.

Prima dell'upgrade, considera questo rischio specifico dell'applicazione: le migrazioni del database, la crittografia delle credenziali e i community node installati devono rimanere compatibili con la release n8n di destinazione. Ripristina un backup recente in un deployment isolato, esegui lì le migrazioni e confronta il comportamento. Se i link webhook continuano a puntare a localhost oppure gli header del proxy indicano HTTP, analizza il confine coinvolto — origine pubblica, storage o dipendenza — prima di modificare impostazioni non correlate.

Metti in sicurezza n8n dopo il bootstrap

Non ereditare le assunzioni di sicurezza di un tutorial locale. La preoccupazione specifica di n8n è la rotazione di N8N_ENCRYPTION_KEY dopo il salvataggio delle credenziali. In produzione, quindi, l'editor dovrebbe rimanere autenticato, esponendo solo i percorsi webhook di cui le integrazioni hanno effettivamente bisogno.

Genera N8N_ENCRYPTION_KEY una sola volta, non inserirla in Git e conservarla nel recovery manifest perché modificarla può invalidare lo stato applicativo crittografato o firmato. Limita l'accesso al filesystem e alla rete, proteggi gli endpoint di setup e definisci limiti per upload, richieste o esecuzioni in base alla concorrenza delle esecuzioni, alla profondità della coda, alla dimensione dei payload binari e ai nodi di lunga durata, invece che alle visualizzazioni delle pagine dell'editor.

Mantieni n8n esplicito mentre Dockup gestisce il routing

Il deployment one-click di n8n di Dockup dovrebbe rendere sicura la sostituzione: la route continua a puntare alla porta 5678, i secret non sono incorporati nell'immagine e i percorsi persistenti vengono ripristinati nel nuovo container. Lo stesso deployment può essere eseguito sul compute di Dockup o su una macchina collegata.

Completa il lavoro specifico dell'app collegando e testando Postgres per una configurazione di produzione durevole e multiutente, applicando l'indirizzo pubblico canonico ed eseguendo questo controllo di accettazione: attiva un workflow con un webhook di produzione, chiama quel webhook dall'esterno del server e conferma che l'esecuzione raggiunga il nodo finale. Aggiungi il risultato del restore al runbook prima dell'arrivo degli utenti reali.

Domande frequenti

Di cosa ha bisogno n8n per un deployment di produzione?

Instrada il container n8n sulla porta 5678 attraverso un'unica origine HTTPS. Il requisito di rete di supporto è Postgres per una configurazione di produzione durevole e multiutente. Non considerare n8n pronto finché non puoi attivare un workflow con un webhook di produzione, chiamare quel webhook dall'esterno del server e confermare che l'esecuzione raggiunga il nodo finale.

Quali dati di n8n devono essere inclusi in un backup?

Rendi persistente /home/node/.n8n e includi nel recovery manifest lo stesso database e i dati di crittografia e configurazione di .n8n. Un restore pulito di n8n ha esito positivo solo quando le credenziali ripristinate vengono ancora decrittografate e un workflow ripristinato riceve lo stesso URL webhook pubblico.

n8n richiede HTTPS dietro un reverse proxy?

Usa HTTPS per l'origine pubblica di n8n e mantieni la porta 5678 nella route interna. Applica correttamente l'impostazione di n8n: imposta WEBHOOK_URL sull'esatto URL HTTPS esterno. Per n8n, HTTPS protegge le credenziali o i contenuti degli utenti durante il transito e mantiene coerente il comportamento dei client sensibile all'origine.

Come deve essere testato un upgrade di n8n?

Ripristina lo stato attuale di n8n in un deployment isolato, applica la versione candidata e ripeti la relativa transazione di accettazione. Presta particolare attenzione perché le migrazioni del database, la crittografia delle credenziali e i community node installati devono rimanere compatibili con la release n8n di destinazione. Conserva l'immagine n8n precedente finché non avrai compreso i limiti della migrazione dei dati e del rollback.