Come fare self-hosting di n8n (guida 2026)

Il self-hosting di n8n ti dà la piattaforma completa di automazione dei flussi di lavoro, senza limiti di esecuzione e con piena proprietà dei tuoi dati. Questa guida percorre in modo onesto la vera configurazione con Docker, Docker Compose e PostgreSQL, e poi mostra la scorciatoia dei 30 secondi se preferisci evitare del tutto l'amministrazione del server.

Cosa significa “self-hosting di n8n”?

n8n è uno strumento di automazione dei flussi di lavoro source-available. A differenza di n8n Cloud, il SaaS gestito dal team di n8n, il self-hosting significa che tu fai girare l'applicazione n8n su un'infrastruttura che controlli. Il software in sé è gratuito con una licenza fair-code, ma il calcolo, il database, lo storage e la banda per tenerlo in funzione 24/7 non lo sono. Il self-hosting è la scelta giusta quando vuoi nessun limite di esecuzione, pieno controllo su credenziali e dati, flussi illimitati e la possibilità di usare nodi della community e codice personalizzato senza che un piano SaaS te lo impedisca.

Requisiti di sistema di n8n

n8n è leggero da avviare, ma scala con quanto sono pesanti i tuoi flussi. Una base realistica:

• CPU: 1 vCPU va bene per un uso leggero; 2+ vCPU per molte esecuzioni concorrenti.
• RAM: da 1 a 2 GB per n8n. I flussi che elaborano payload grandi (file, immagini, JSON voluminosi) ne richiedono di più.
• Database: PostgreSQL è caldamente consigliato per la produzione. Il SQLite predefinito va bene per i test, ma non gestisce bene la concorrenza ed è più difficile da sottoporre a backup in sicurezza.
• Storage: Qualche GB basta per iniziare; la cronologia delle esecuzioni e i dati binari crescono nel tempo.
• Rete: Un endpoint HTTPS pubblico (porta 443) così i webhook in entrata e i callback OAuth funzionano.

Per un'analisi più approfondita, mappata sulle dimensioni dei piani, vedi la nostra Guida ai requisiti del server n8n.

Opzione 1: distribuisci n8n con Docker

Il modo più rapido per far girare n8n sulla tua macchina o su un VPS è l'immagine Docker ufficiale. È ottima per una prova in locale, ma nota che usa SQLite e non ha TLS: non è quello che vuoi in produzione:

docker volume create n8n_data

docker run -it --rm \
  --name n8n \
  -p 5678:5678 \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

Apri http://localhost:5678, crea l'account proprietario e avrai un n8n funzionante. Per qualsiasi uso reale, passa a Docker Compose con PostgreSQL.

Opzione 2: Docker Compose con PostgreSQL

Una configurazione di produzione abbina n8n a un database PostgreSQL dedicato, una chiave di crittografia e gli URL corretti di host e webhook. Salva questo file come docker-compose.yml:

services:
  postgres:
    image: postgres:16
    restart: always
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: change-me
      POSTGRES_DB: n8n
    volumes:
      - pgdata:/var/lib/postgresql/data

  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "5678:5678"
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: change-me
      N8N_HOST: n8n.example.com
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://n8n.example.com/
      N8N_ENCRYPTION_KEY: a-long-random-string
    depends_on:
      - postgres
    volumes:
      - n8ndata:/home/node/.n8n

volumes:
  pgdata:
  n8ndata:

Poi esegui docker compose up -d. Alcune cose sono importanti: imposta una N8N_ENCRYPTION_KEY robusta (cifra le credenziali salvate, quindi perderla significa reinserire ogni credenziale), punta WEBHOOK_URL al tuo dominio HTTPS pubblico reale, e non esporre mai la porta 5678 direttamente su internet senza un reverse proxy davanti.

Le parti che le guide al self-hosting saltano

Far partire n8n è il 20% facile. Mantenerlo in funzione in modo sicuro è l'altro 80%, ed è il punto in cui un VPS grezzo ti morde:

• Certificati TLS: Servono HTTPS per webhook e OAuth. Significa Caddy, Traefik o Nginx più Let’s Encrypt, e un rinnovo dei certificati che non deve mai fallire.
• Webhook e reverse proxy: I webhook in entrata richiedono un URL pubblico stabile e header proxy corretti, altrimenti i trigger si rompono in silenzio.
• Backup: I tuoi flussi, le credenziali e la cronologia delle esecuzioni vivono in PostgreSQL. Ti servono backup automatici e testati del database: un backup non testato non è un backup.
• Aggiornamenti: n8n rilascia spesso nuove versioni. Sei tu a dover scaricare le nuove immagini, leggere le note sulle modifiche incompatibili e migrare il database.
• Uptime: Un singolo VPS è un singolo punto di guasto. Se l'host si riavvia alle 2 di notte, le tue pianificazioni e i webhook si fermano finché non te ne accorgi.

Domande frequenti