n8n su un VPS: la tua piattaforma di automazione senza attività manuali ripetitive

Dal sito arriva una richiesta. n8n verifica i dati, cerca eventuali duplicati, crea un’opportunità, prepara una bozza di risposta con l’aiuto dell’IA e avvisa il responsabile su Telegram. Una persona interviene solo quando serve prendere una decisione, non per spostare dati da una scheda all’altra.

Di seguito vedremo come funziona n8n e come installarlo su un VPS con Docker Compose, PostgreSQL, HTTPS ed esecuzione isolata del codice.

n8n in sette passaggi

Piano minimo di avvio:

1. Crea un VPS e indirizza verso di esso un sottodominio, ad esempio n8n.example.com.
2. Installa Docker e Docker Compose.
3. Avvia n8n con PostgreSQL, un task runner esterno e Caddy.
4. Apri l’interfaccia tramite HTTPS e crea l’account del proprietario.
5. Collega Telegram, un CRM, la posta elettronica o qualsiasi API esterna.
6. Configura la gestione degli errori e il periodo di conservazione delle esecuzioni.
7. Automatizza i backup del database, dei dati e della chiave di crittografia.

Per una piccola installazione in produzione è ragionevole iniziare con 2 vCPU e 4 GB di RAM. Per i test spesso bastano 2 GB, ma PostgreSQL, Docker e i processi paralleli consumano rapidamente il margine disponibile.

Cos’è n8n e come funziona

n8n è una piattaforma per l’automazione dei workflow. Uno scenario viene costruito con una serie di nodi: uno avvia il processo, i successivi recuperano e trasformano i dati e l’ultimo esegue un’azione.

Un workflow semplice si presenta così:

Webhook → verifica dei dati → CRM → Telegram → risposta al sito

La catena può essere avviata da un webhook, una pianificazione, un’e-mail, un messaggio o un evento di un servizio esterno. Tra i nodi sono disponibili condizioni, cicli, filtri, attese e gestione degli errori.

Uno dei punti di forza di n8n è che l’automazione non è limitata alle integrazioni già pronte. Qualsiasi servizio dotato di API può essere richiamato tramite HTTP Request, mentre una logica specifica può essere scritta in un Code node con JavaScript o Python. Per questo n8n si colloca tra un semplice builder no-code e il codice server sviluppato da zero.

Perché è più di un semplice trasferimento di dati

n8n è utile quando un processo attraversa più sistemi e richiede una decisione:

modulo → verifica → ricerca di duplicati → valutazione dell’IA → approvazione del responsabile → CRM

L’intervento umano può essere limitato a un solo punto di controllo. Per esempio, l’IA prepara una risposta, ma il messaggio viene inviato al cliente solo dopo l’approvazione di un dipendente.

Scenari tipici:

• vendite e assistenza: raccolta delle richieste, assegnazione dei lead e creazione delle opportunità;
• contenuti e IA: preparazione di bozze, classificazione delle richieste e pubblicazione dopo l’approvazione;
• DevOps: notifiche di guasti, webhook da Git e controlli delle API;
• operazioni interne: sincronizzazione di fogli di calcolo, posta, calendari e sistemi aziendali.

Un’installazione self-hosted offre il controllo sul processo e sul database, ma non rende locali i servizi esterni. I dati inviati a Telegram, a un CRM o a un modello di IA nel cloud lasciano il VPS.

n8n Cloud o server proprio

Parametro	n8n Cloud	n8n su un VPS
Avvio	Nessuna configurazione del server	Richiede dominio, Docker e HTTPS
Aggiornamenti	Eseguiti da n8n	Eseguiti dal proprietario
Database e file	Nell’infrastruttura del servizio	Sul server scelto
Scalabilità	Secondo le condizioni del piano cloud	Configurata in autonomia
Responsabilità	Meno amministrazione	Backup, sicurezza e monitoraggio a carico del proprietario
Per chi è adatto	Avvio rapido senza DevOps	Controllo, personalizzazione e processi sempre attivi

La Community Edition può essere ospitata gratuitamente sul proprio server e utilizzata per processi personali e aziendali interni. Tuttavia, n8n non viene distribuito con una classica licenza open source, ma secondo il modello fair-code Sustainable Use License. La licenza consente l’uso interno e le modifiche, ma non permette semplicemente di distribuire n8n, aggiungere il proprio logo e vendere l’accesso come SaaS indipendente. Per un prodotto di questo tipo è necessario verificare separatamente le condizioni della licenza.

Requisiti del server per n8n

Il carico dipende dal volume dei dati, dal parallelismo e dal tipo di operazioni. File, elenchi lunghi, Code nodes e workflow con IA richiedono più memoria rispetto al trasferimento di piccoli oggetti JSON tra API.

Scenario	Configurazione iniziale
Test e workflow personali basati su testo	1 vCPU, 2 GB di RAM, 20 GB NVMe
Piccola installazione in produzione	2 vCPU, 4 GB di RAM, 25–40 GB NVMe
Processi paralleli, IA o file	4 vCPU, 8 GB di RAM o più
Più processi worker in queue mode	Dimensionamento in base al numero di esecuzioni

SQLite è adatto per conoscere la piattaforma e per una piccola istanza singola. Per un’installazione in produzione è più comodo PostgreSQL: semplifica i backup e un successivo passaggio al queue mode.

Come installare n8n su un VPS

In questo esempio vengono utilizzati Ubuntu 24.04, PostgreSQL, Caddy e un task runner esterno. Sostituisci n8n.example.com e il fuso orario con i tuoi valori.

1. Configura il DNS e prepara il server

Crea un record DNS A che punti all’indirizzo IPv4 del VPS, quindi collegati tramite SSH:

ssh root@SERVER_IP
apt update && apt upgrade -y
apt install -y ca-certificates curl ufw openssl

Installa Docker Engine e il plugin Compose dal repository ufficiale:

install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc

cat > /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

apt update
apt install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin
docker compose version

Apri soltanto SSH, HTTP e HTTPS:

ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Non chiudere la sessione SSH attuale finché non hai verificato che una nuova connessione funzioni.

2. Crea le variabili d’ambiente

Prepara la directory:

mkdir -p /opt/n8n
cd /opt/n8n

Crea il file .env. I comandi seguenti generano subito segreti casuali differenti per PostgreSQL, la crittografia di n8n e il task runner:

cat > .env <<EOF
N8N_VERSION=stable
N8N_HOST=n8n.example.com
GENERIC_TIMEZONE=Europe/Berlin

POSTGRES_DB=n8n
POSTGRES_USER=n8n
POSTGRES_PASSWORD=$(openssl rand -hex 32)

N8N_ENCRYPTION_KEY=$(openssl rand -hex 32)
RUNNERS_AUTH_TOKEN=$(openssl rand -hex 32)
EOF

chmod 600 .env

Il tag stable è comodo per il primo avvio. Dopo aver verificato l’installazione, è meglio fissare una versione specifica di n8n, così il prossimo aggiornamento dell’immagine non avverrà in modo inatteso.

N8N_ENCRYPTION_KEY non deve andare perso. n8n usa questa chiave per crittografare password, token e altre credenziali salvate. Se si ripristina soltanto PostgreSQL senza la chiave, i record rimarranno nel database, ma n8n non potrà leggerli.

3. Crea la configurazione Docker Compose

Crea il file compose.yaml:

services:
  postgres:
    image: postgres:18-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      PGDATA: /var/lib/postgresql/data
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
      interval: 5s
      timeout: 5s
      retries: 10

  n8n:
    image: docker.n8n.io/n8nio/n8n:${N8N_VERSION}
    restart: unless-stopped
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_PORT: "5432"
      DB_POSTGRESDB_DATABASE: ${POSTGRES_DB}
      DB_POSTGRESDB_USER: ${POSTGRES_USER}
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}

      N8N_HOST: ${N8N_HOST}
      N8N_PORT: "5678"
      N8N_PROTOCOL: https
      N8N_EDITOR_BASE_URL: https://${N8N_HOST}
      N8N_WEBHOOK_URL: https://${N8N_HOST}/
      N8N_PROXY_HOPS: "1"
      GENERIC_TIMEZONE: ${GENERIC_TIMEZONE}
      TZ: ${GENERIC_TIMEZONE}

      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS: "true"
      N8N_BLOCK_ENV_ACCESS_IN_NODE: "true"

      N8N_RUNNERS_MODE: external
      N8N_RUNNERS_AUTH_TOKEN: ${RUNNERS_AUTH_TOKEN}
      N8N_RUNNERS_BROKER_LISTEN_ADDRESS: 0.0.0.0

      EXECUTIONS_DATA_PRUNE: "true"
      EXECUTIONS_DATA_MAX_AGE: "168"
      EXECUTIONS_DATA_PRUNE_MAX_COUNT: "10000"
    volumes:
      - n8n_data:/home/node/.n8n
    expose:
      - "5678"
    depends_on:
      postgres:
        condition: service_healthy

  n8n-runner:
    image: n8nio/runners:${N8N_VERSION}
    restart: unless-stopped
    environment:
      N8N_RUNNERS_AUTH_TOKEN: ${RUNNERS_AUTH_TOKEN}
      N8N_RUNNERS_TASK_BROKER_URI: http://n8n:5679
    depends_on:
      - n8n

  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    environment:
      N8N_HOST: ${N8N_HOST}
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    depends_on:
      - n8n

volumes:
  postgres_data:
    name: n8n_postgres_data
  n8n_data:
    name: n8n_data
  caddy_data:
    name: n8n_caddy_data
  caddy_config:
    name: n8n_caddy_config

Il task runner esterno esegue il codice separatamente dal processo principale di n8n. È più sicuro della modalità interna e riduce la possibilità che un errore in un Code node influisca sull’editor e sull’elaborazione dei webhook.

4. Attiva HTTPS

Crea il file Caddyfile:

{$N8N_HOST} {
    reverse_proxy n8n:5678
}

Caddy otterrà automaticamente un certificato TLS se il DNS punta già al VPS e le porte 80 e 443 sono raggiungibili. La porta interna 5678 non viene esposta su Internet: dall’esterno sono disponibili soltanto le porte 80 e 443, mentre Caddy accede a n8n tramite la rete Docker.

Le variabili N8N_WEBHOOK_URL e N8N_PROXY_HOPS servono affinché l’editor generi gli indirizzi pubblici corretti dei webhook e consideri attendibili gli header provenienti da un reverse proxy.

5. Avvia n8n

Controlla la configurazione finale e avvia i container:

docker compose config
docker compose up -d
docker compose ps
docker compose logs --tail=100 n8n caddy

Apri:

https://n8n.example.com

Crea l’account del proprietario. Non condividere la password con i colleghi: per il lavoro in squadra usa account separati e assegna solo gli accessi necessari.

Il primo workflow utile

Un buon test consiste nell’elaborare una richiesta proveniente dal sito:

1. Aggiungi un nodo Webhook con il metodo POST.
2. Con Edit Fields, mantieni soltanto nome, indirizzo e-mail e provenienza.
3. Usa un nodo If per rifiutare una richiesta priva dei dati obbligatori.
4. Crea un’opportunità nel CRM oppure invia una richiesta tramite HTTP Request.
5. Aggiungi una notifica su Telegram.
6. Concludi la catena con un nodo Respond to Webhook.
7. Dopo il test, attiva il workflow e sostituisci il webhook di prova con l’URL di produzione.

Questo esempio verifica immediatamente il dominio, HTTPS, le richieste in ingresso, le credenziali e il funzionamento dell’integrazione esterna. Successivamente conviene aggiungere un Error Workflow separato che invii una notifica in caso di errore della catena principale.

Sicurezza di n8n dopo l’installazione

Avere installato n8n non significa ancora avere un n8n affidabile. Dopo l’avvio, verifica che:

• l’editor sia accessibile soltanto tramite HTTPS;
• .env abbia i permessi 600 e non venga incluso in Git;
• le chiavi delle API esterne abbiano soltanto i permessi minimi;
• ogni webhook verifichi la firma o il segreto della fonte;
• la cronologia delle esecuzioni venga eliminata automaticamente;
• gli errori dei workflow critici vengano inviati all’amministratore.

I Community nodes vengono installati come pacchetti e possono ottenere accesso ai dati dei workflow e al server. Non aggiungere nodi sconosciuti senza verificarli. Se non servono, disattivali con N8N_COMMUNITY_PACKAGES_ENABLED=false.

Esegui l’audit integrato:

docker compose exec n8n n8n audit

Aiuta a individuare webhook non protetti, nodi rischiosi e problemi con le credenziali, ma non sostituisce un controllo manuale.

Cronologia delle esecuzioni e dati personali

n8n salva i dati in ingresso e in uscita per il debug. Insieme a essi, nel database possono rimanere e-mail, numeri di telefono, documenti e risposte delle API.

Nella configurazione precedente, le esecuzioni vengono eliminate dopo sette giorni e il loro numero è limitato a 10.000. Per i processi sensibili, il periodo va scelto in base alla politica di conservazione dei dati e i campi non necessari devono essere rimossi prima della fine del workflow.

Backup e aggiornamenti

Per il ripristino servono un dump di PostgreSQL, il volume n8n_data, i file di configurazione e .env con N8N_ENCRYPTION_KEY. Prima di copiare, arresta i processi di elaborazione lasciando PostgreSQL in esecuzione. Questo provocherà una breve interruzione dei workflow:

cd /opt/n8n
mkdir -p backup
docker compose stop n8n n8n-runner

docker compose exec -T postgres sh -c \
  'pg_dump -U "$POSTGRES_USER" "$POSTGRES_DB"' \
  | gzip > "backup/n8n-db-$(date +%F).sql.gz"

docker run --rm \
  -v n8n_data:/source:ro \
  -v "$PWD/backup":/backup \
  alpine sh -c \
  'tar -czf /backup/n8n-data-$(date +%F).tar.gz -C /source .'

tar -czf "backup/n8n-config-$(date +%F).tar.gz" \
  .env compose.yaml Caddyfile

docker compose start n8n n8n-runner

L’archivio che contiene .env include dei segreti: crittografalo e conservalo fuori dal VPS. Verifica periodicamente la copia eseguendo un ripristino di prova.

Prima di un aggiornamento, crea un backup e consulta le note di rilascio:

cd /opt/n8n
docker compose pull
docker compose up -d
docker compose ps

Il task runner e il container principale devono usare lo stesso tag di versione.

Quando sarà necessario scalare

Non iniziare con Redis e più worker prima che esista un carico reale. Una singola istanza con PostgreSQL è più semplice da gestire e in genere copre i piccoli processi interni.

Il queue mode diventa necessario quando le attività lunghe ritardano i webhook, molti workflow vengono avviati contemporaneamente o l’elaborazione dei file occupa regolarmente tutta la memoria. In quel caso, l’istanza principale riceve gli eventi, Redis distribuisce i lavori e i worker li eseguono in parallelo. Tutti i componenti devono collegarsi allo stesso PostgreSQL e utilizzare la stessa N8N_ENCRYPTION_KEY.

Quale VPS scegliere per n8n

Per eseguire insieme n8n, PostgreSQL, Caddy e un task runner, è ragionevole iniziare con 2 vCPU, 4 GB di RAM e un disco NVMe. Su tropic.host, questa configurazione corrisponde al piano Light: 2 vCPU, 4 GB di RAM e 25 GB NVMe. È sufficiente per i primi workflow in produzione senza un’elaborazione pesante dei file.

Per documenti, grandi volumi di dati e numerosi workflow paralleli con IA è meglio scegliere 8 GB di RAM. Anche una rete stabile è importante: webhook, callback OAuth e attività pianificate devono rimanere sempre disponibili.

Conclusione

n8n trasforma le operazioni ripetitive in flussi visivi e chiari: i nodi già pronti velocizzano l’avvio, HTTP Request collega quasi qualsiasi API e un Code node permette di aggiungere la propria logica.

La versione self-hosted offre il controllo sul server e sul database, ma richiede HTTPS, chiavi con autorizzazioni limitate, pulizia della cronologia e backup verificati. Conserva N8N_ENCRYPTION_KEY insieme a PostgreSQL: senza questa chiave, le credenziali ripristinate non possono essere decifrate.

FAQ

È possibile usare n8n gratuitamente?

Sì. La Community Edition può essere ospitata gratuitamente sul proprio server per processi personali e interni. La rivendita di un’istanza n8n ospitata come SaaS indipendente è limitata dalla licenza fair-code.

È possibile installare n8n senza un dominio?

Per un test locale, sì. Per webhook pubblici e OAuth è meglio usare un dominio e HTTPS.

Quanta RAM serve a n8n?

Per semplici workflow personali spesso bastano 2 GB di RAM. Per n8n con PostgreSQL, Caddy e un task runner sono più appropriati 4 GB; i file e le esecuzioni parallele possono richiedere 8 GB o più.

Tutti i dati rimangono all’interno del VPS?

Rimangono soltanto i dati che il workflow non invia all’esterno. Il database e la cronologia delle esecuzioni si trovano sul VPS, ma i nodi di Telegram, del CRM o di un modello di IA esterno inviano i dati selezionati al servizio corrispondente.

Cosa deve includere un backup di n8n?

Un dump di PostgreSQL, il volume n8n_data, compose.yaml, Caddyfile e il file .env con N8N_ENCRYPTION_KEY. Conserva la copia crittografata fuori dal VPS e verificala tramite un ripristino.