AI Automation Italia

Migrazione da n8n Cloud a Self‑Hosted: Guida Completa con Zero Downtime

Migrazione da n8n Cloud a Self‑Hosted: Guida Completa con Zero Downtime

Vuoi più controllo, scalabilità e costi prevedibili senza interrompere le tue automazioni? Questa guida pratica ti mostra come eseguire una migrazione n8n self hosted da n8n Cloud a un’installazione su server (VPS o on‑prem) con zero downtime. Partiremo dai gap più comuni e costruiremo un piano end‑to‑end: scelta dell’architettura (Docker Compose con PostgreSQL e modalità coda di n8n con Redis), gestione credenziali e ENCRYPTION_KEY in n8n, cambio dominio dei webhook n8n, backup e restore del database n8n, reverse proxy per n8n (Traefik, Caddy, Nginx), riconsenso OAuth e strategie di rollback. Il tutto con esempi concreti e configurazioni funzionanti. Che tu stia scalando lead gen, customer onboarding o marketing ops complesse, troverai un processo chiaro per esportare e importare workflow n8n, mantenere la continuità del servizio e migliorare osservabilità e sicurezza. Preparati a una transizione fluida e misurabile, pensata per marketer e team growth che vogliono imparare ad usare n8n per migliorare la propria produttività senza sorprese.

📚 Nuovo a n8n? Parti dalla guida completa: cos'è n8n e come funziona.

Architettura target: Docker Compose con Postgres, Redis e reverse proxy

Per una migrazione da n8n Cloud a installazione su server che regga crescita e picchi, suggeriamo:

  • Database: Postgres (DB_TYPE=postgresdb). n8n raccomanda Postgres 13+ per produzione e sconsiglia SQLite in queue mode.
  • Esecuzioni: EXECUTIONS_MODE=queue con Redis per massima scalabilità.
  • Reverse proxy TLS: Traefik o Nginx davanti a n8n per HTTPS e routing.
  • Variabili ambiente e file .env per n8n: gestione centralizzata e segreti separati.

Esempio Docker Compose minimale e funzionante (main + worker + Postgres + Redis):

version: "3.8"
services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: n8n
      POSTGRES_DB: n8n
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n"]
      interval: 10s
      timeout: 5s
      retries: 5

  redis:
    image: redis:7
    command: ["redis-server", "--appendonly", "yes"]
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 3s
      retries: 10

  n8n-main:
    image: docker.n8n.io/n8nio/n8n:latest
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=n8n
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - QUEUE_BULL_REDIS_PORT=6379
      - N8N_ENCRYPTION_KEY=super-long-random-string
      - N8N_HOST=n8n.example.com
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.example.com/
      - N8N_EDITOR_BASE_URL=https://n8n.example.com/
      - N8N_METRICS=true
      - N8N_LOG_LEVEL=info
      - N8N_ENDPOINT_WEBHOOK=webhook
      - N8N_ENDPOINT_WEBHOOK_TEST=webhook-test
      - N8N_ENDPOINT_WEBHOOK_WAIT=webhook-waiting
    volumes:
      - n8n_data:/home/node/.n8n
    ports:
      - "5678:5678"
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy

  n8n-worker:
    image: docker.n8n.io/n8nio/n8n:latest
    command: n8n worker
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=n8n
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - QUEUE_BULL_REDIS_PORT=6379
      - N8N_ENCRYPTION_KEY=super-long-random-string
      - QUEUE_HEALTH_CHECK_ACTIVE=true
      - N8N_LOG_LEVEL=info
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy

volumes:
  pgdata:
  n8n_data:

Note chiave:

  • Condividi lo stesso N8NENCRYPTIONKEY tra main e worker, altrimenti i worker non leggono le credenziali.
  • Queue mode + filesystem per binari non è supportato: se devi persistere file in produzione, considera storage esterno S3 (Enterprise) o mantieni binari in memoria per flussi che non richiedono persistenza.

Preparazione e allineamento: versioni, variabili e sicurezza

Allineamento versioni e architettura target:

  • Allineamento versioni n8n: esegui localmente una versione uguale o superiore a quella Cloud per evitare incompatibilità nei workflow importati.
  • Scelta architettura target: Docker Compose è ideale per iniziare; Kubernetes se prevedi scalabilità massiva o multi‑main.

Variabili ambiente essenziali per produzione:

  • Deployment: N8NHOST, N8NPORT (default 5678), N8NPROTOCOL (http/https), N8NENCRYPTIONKEY, N8NUSERFOLDER, N8NPROXY_HOPS (se dietro più proxy).
  • Database: DBTYPE=postgresdb, DBPOSTGRESDB_HOST/PORT/DATABASE/USER/PASSWORD/SCHEMA.
  • Queue/Redis: EXECUTIONSMODE=queue, QUEUEBULLREDISHOST/PORT (+ eventuali QUEUEBULLREDISUSERNAME/QUEUEBULLREDISPASSWORD).
  • Endpoints: N8NENDPOINTWEBHOOK, N8NENDPOINTWEBHOOKTEST, N8NENDPOINTWEBHOOKWAIT, WEBHOOKURL, N8NEDITORBASEURL.
  • Logging/monitoring: N8NLOGLEVEL (error|warn|info|debug), N8NMETRICS=true per abilitare /metrics; QUEUEHEALTHCHECKACTIVE=true per /healthz dei worker.

Sicurezza e TLS per endpoint n8n:

  • Usa un reverse proxy per TLS (Traefik, Caddy, Nginx) e imposta WEBHOOKURL e N8NEDITORBASEURL al dominio HTTPS.
  • Firewall e SSH: limita le porte esposte (solo 80/443 sul proxy), DB e Redis su rete privata.
  • Backup/snapshot automatici: snapshot del volume Postgres e del volume n8n_data, oltre a dump regolari.

Insight pratico: mantieni un file .env gestito in un secret manager e usa variabili con suffisso FILE dove possibile per separare i segreti (es. DBPOSTGRESDBPASSWORDFILE).

Migrazione operativa: workflow, credenziali, variabili e binari

Esportare e importare workflow n8n:

  • In n8n Cloud, esporta i workflow in JSON.
  • Nella nuova istanza, Import From JSON e verifica nodi e referenze delle credenziali.

Gestione credenziali e ENCRYPTION_KEY in n8n:

  • I workflow referenziano credenziali per nome/ID. Pre‑crea le credenziali con gli stessi nomi nella self‑hosted.
  • Poiché l’ENCRYPTION_KEY di n8n Cloud non è riutilizzabile nella tua istanza, pianifica di reinserire secret/API key e di eseguire riconsenso OAuth nelle integrazioni n8n (nuovo dominio = nuove redirect URI).
  • Mantieni N8NENCRYPTIONKEY stabile e archivialo in modo sicuro: è la chiave per decifrare le credenziali nel database.

Variabili e file .env per n8n:

  • Ricrea le Environment Variables usate nei workflow (Settings > Variables in n8n oppure come env nel container) per garantire portabilità.
  • Se usi expression che dipendono da URL base, aggiorna WEBHOOKURL/N8NEDITORBASEURL e verifica i nodi Webhook Trigger.

Storage binario:

  • In queue mode, evita filesystem per binari; se devi persistere file, valuta S3 esterno (Enterprise) o sposta la logica di archiviazione su un bucket S3 tramite nodi S3.
  • Per carichi marketing (lead import, asset leggeri) spesso basta la modalità in memoria.

Esecuzioni storiche (opzionale):

  • Se ti servono, migrare il database (vedi sezione backup/restore). Altrimenti riparti pulito per ridurre complessità e spazio.

Zero Downtime: strategie di cutover per webhook e trigger

Obiettivo: passare traffico e schedulazioni alla nuova istanza senza interruzioni e senza duplicati.

Piano di esecuzione consigliato:
1) Blue/Green parallelo

  • Attiva l’istanza self‑hosted (green) in private URL e importa i workflow.
  • Disattiva i workflow su Cloud, ma solo dopo test riusciti in green.

2) Mirroring e test di non regressione

  • Per i Webhook Trigger, imposta temporaneamente un mirroring dal proxy (o dal servizio sorgente) verso cloud e self‑hosted per validare idempotenza (usa un header HMAC o un “dedupe key” per non processare due volte).
  • Verifica duplicati/timeout con metriche e log.

3) Cutover DNS controllato

  • Riduci TTL del record DNS (es. a 60 s) 24‑48 h prima.
  • Aggiorna WEBHOOKURL e N8NEDITORBASEURL per puntare al dominio finale.
  • Cambia il CNAME/A verso il nuovo proxy. Con TTL basso, la propagazione è rapida.

4) Trigger schedulati

  • Riattiva i trigger cron sulla self‑hosted (e disattivali sul Cloud). Esegui un “dry run” su finestre non critiche.

5) Riconsenso OAuth

  • Aggiorna redirect URI nei provider e rifai il consenso. Programma questa attività in una finestra a basso traffico.

6) Osservabilità e validazione

  • Abilita /healthz, /healthz/readiness e /metrics per controllare readiness DB/Redis e lo stato.
  • Tieni d’occhio lunghezze coda Redis, esecuzioni in “new” e tempi medi.

Rollback semplice:

  • Tieni Cloud in stand‑by finché i test in produzione sono verdi.
  • In caso di problemi, re‑punta il DNS al Cloud e ripristina i trigger lì. Mantieni snapshot e dump aggiornati (vedi sotto).

Backup, monitoraggio e rollback post‑migrazione

Backup e restore del database n8n (Postgres):

  • Backup:
pg_dump -h <host> -U <user> -d n8n -Fc -f /backups/n8n_$(date +%F).dump
  • Restore:
pg_restore -h <host> -U <user> -d n8n --clean --if-exists /backups/n8n_latest.dump
  • Pianifica cron giornalieri e conserva almeno 7‑14 giorni di retention.

Snapshot e strategie di rollback n8n:

  • Esegui snapshot dei volumi (pgdata, n8n_data) prima del cutover.
  • Conserva il file .env e il valore N8NENCRYPTIONKEY offline.

Monitoraggio esecuzioni e log n8n:

  • Abilita:
  • N8N_METRICS=true → /metrics
  • QUEUEHEALTHCHECK_ACTIVE=true → /healthz e /healthz/readiness
  • N8NLOGLEVEL=info (usa debug solo per indagini)
  • Integra Prometheus/Grafana per code, errori per nodo, durata media esecuzioni.
  • Imposta alerting su failure rate e backlog Redis.

Reverse proxy per n8n (Nginx esempio):

server {
  listen 80;
  server_name n8n.example.com;
  return 301 https://$host$request_uri;
}
server {
  listen 443 ssl http2;
  server_name n8n.example.com;

  ssl_certificate     /etc/ssl/certs/fullchain.pem;
  ssl_certificate_key /etc/ssl/private/privkey.pem;

  client_max_body_size 50m;

  location / {
    proxy_pass http://n8n-main:5678;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
  }
}

Suggerimento Traefik (etichette base):

  • traefik.http.routers.n8n.rule=Host(n8n.example.com)
  • traefik.http.routers.n8n.entrypoints=websecure
  • traefik.http.routers.n8n.tls=true
  • traefik.http.services.n8n.loadbalancer.server.port=5678

Insight pratico: in multi‑main setup usa sticky sessions a livello di load balancer e mantieni tutte le istanze sulla stessa versione.

Quick Takeaways

  • Passa a Postgres e EXECUTIONS_MODE=queue con Redis per scalabilità e resilienza.
  • Condividi lo stesso N8NENCRYPTIONKEY tra main e worker per l’accesso alle credenziali.
  • Prepara cutover DNS a TTL basso e gestisci il riconsenso OAuth per il cambio dominio.
  • Evita filesystem per binari in queue mode; usa memoria o S3 esterno.
  • Abilita /metrics e /healthz per test di readiness e monitoraggio proattivo.
  • Esegui backup regolari (pg_dump) e snapshot pre‑cutover per rollback veloce.

Conclusione

Una migrazione n8n self hosted ben eseguita combina scelte tecniche robuste con un piano operativo chiaro. Passare da n8n Cloud a un’installazione su server ti dà controllo su costi, sicurezza, versioni e scalabilità, ma richiede disciplina: inventario iniziale, allineamento versioni, configurazione corretta di Postgres/Redis, gestione sicura dell’ENCRYPTIONKEY e una strategia di cutover dei webhook con zero downtime. Con Docker Compose, reverse proxy e le variabili ambiente giuste (WEBHOOKURL, N8NEDITORBASEURL, EXECUTIONSMODE=queue, DBPOSTGRESDB, QUEUEBULLREDIS_), ottieni un setup pronto per la crescita. Aggiungi backup e restore del database n8n, osservabilità con /metrics e log al livello giusto, e un runbook di rollback semplice per proteggere il business. Se sei un marketer che vuole imparare ad usare n8n per migliorare la produttività, questo passaggio è l’occasione per standardizzare i workflow, introdurre test di non regressione e misurare l’impatto delle automazioni sul funnel. Inizia ora con un ambiente di staging, esegui i test sugli use case critici e pianifica il cutover in una finestra a basso traffico: avrai una migrazione sicura e un’infrastruttura pronta a supportare la tua crescita.

FAQ

1) Posso migrare direttamente le credenziali da Cloud alla mia installazione su server?

  • In genere no: l’ENCRYPTIONKEY del Cloud non è portabile sulla tua istanza. Ricrea le credenziali nella self‑hosted e prevedi riconsenso OAuth dove necessario. Mantieni lo stesso N8NENCRYPTION_KEY su main e worker.

2) Meglio n8n con PostgreSQL o SQLite in produzione?

  • PostgreSQL. n8n con PostgreSQL e confronto con SQLite: Postgres è raccomandato (specie in EXECUTIONS_MODE=queue). SQLite non è consigliato in queue mode e limita scalabilità e affidabilità.

3) Come gestisco il cambio dominio dei webhook n8n senza downtime?

  • Riduci il TTL del DNS, configura WEBHOOKURL e N8NEDITORBASEURL sul nuovo dominio, usa blue/green con mirroring temporaneo dei webhook, poi esegui il cutover aggiornando il record DNS. Verifica /healthz/readiness prima del passaggio.

4) Come attivo la modalità coda di n8n con Redis?

  • Imposta EXECUTIONSMODE=queue e configura QUEUEBULLREDISHOST/PORT (ed eventuale USERNAME/PASSWORD). Avvia almeno un worker con command n8n worker e condividi lo stesso N8NENCRYPTIONKEY.

5) Qual è la strategia minima di backup e restore del database n8n?

  • Esegui pgdump giornaliero e conserva più versioni; prima del cutover fai snapshot dei volumi. Per il ripristino usa pgrestore. Se usi storage binario su filesystem (non consigliato in queue mode), includi anche quel percorso nel backup.

Hai trovato utile questa guida? Raccontaci quale parte della migrazione ti preoccupa di più (webhook, credenziali, rollback o performance) e condividila con il tuo team: potrebbe evitare ore di downtime alla prossima release!

Articoli correlati

Vuoi automazioni AI su misura per la tua azienda?
Scopri la consulenza →
, , , , , , ,