Come Eseguire n8n sul Tuo Proprio Server

Da sei mesi osservi la tua fattura di Zapier che sale.

Ogni nuovo workflow aggiunge un’altra voce, e ogni passaggio d’azione riuscito conta come un task. La fattura mensile ora costa più del tuo strumento di gestione dei progetti.

Inizi a cercare alternative su Google e ti imbatti in n8n, una piattaforma di automazione che puoi ospitare autonomamente sul tuo server privato virtuale (VPS) al prezzo di un piccolo server.

Nessuna quota di esecuzioni. Nessun prezzo per task. Nessuna bolletta a sorpresa quando le tue automazioni decollano.

E sì, ti guidiamo in tutto il processo, comando per comando, da un server Ubuntu vuoto fino a un’istanza funzionante con HTTPS, backup e un ripristino testato.

Cos’è n8n e Perché Le Persone Lo Ospitano in Autonomia?

n8n è una piattaforma di automazione dei flussi di lavoro che ti permette di collegare app, spostare dati tra servizi e creare automazioni complesse tramite un editor visuale. Pensala come il motore dietro “quando accade X, fai Y e Z”, solo che trascini nodi e disegni connessioni invece di scrivere codice.

Il progetto ha superato le 200.000 stelle su GitHub e la sua immagine Docker ufficiale conta oltre 100 milioni di pull. Sono tanti i server che eseguono n8n.

La piattaforma è distribuita con una Sustainable Use License, che vale la pena comprendere prima di impegnarti. Non è open source tradizionale (n8n stesso dice di non usare questo termine, perché le licenze approvate dall’OSI non possono limitarne l’uso), ma non è nemmeno blindata. Puoi eseguirla liberamente per gli scopi interni della tua azienda. Non puoi vendere un prodotto, un servizio o un modulo il cui valore derivi interamente o in modo sostanziale dalle funzionalità di n8n.

“In pratica, ciò significa che ogni uso è consentito, a meno che tu non venda un prodotto, un servizio o un modulo il cui valore derivi interamente o in modo sostanziale dalle funzionalità di n8n.” — FAQ sulla licenza di n8n

Le persone ospitano autonomamente n8n perché i conti si ribaltano una volta superato l’uso di base. n8n Cloud parte da €20/mese (con fatturazione annuale) per 2.500 esecuzioni sul piano Starter, e se gestisci volumi reali questi limiti si fanno sentire in fretta.

Sul tuo VPS? Nessuna quota di esecuzioni, controllo sui dati archiviati dalla tua istanza n8n e nessuna fattura di licenza o di esecuzione n8n, anche se server, dominio, spazio per i backup e amministrazione hanno comunque un costo. Le esecuzioni in sé non costano nulla in più; volumi più elevati consumano più memoria e storage, ma è una questione di dimensionamento (trattata più avanti), non di fatturazione.

Cosa Puoi Automatizzare Con n8n?

Le oltre 400 integrazioni di n8n coprono un’ampia gamma, e i nodi creati dalla community allungano ulteriormente l’elenco. n8n è anche una delle tante alternative self-hosted agli strumenti SaaS; la stessa logica vale per tutto, dal CRM alla gestione dei progetti.

Alcune configurazioni comuni:

• CRM e routing dei lead. Sincronizza i contatti tra il tuo CRM, la piattaforma email e Slack quando arrivano nuovi lead.
• Workflow attivati da webhook. Rispondi in tempo reale agli eventi provenienti da processori di pagamento, invii di moduli o commit su GitHub.
• Automazione delle pipeline di dati. Estrai dati dalle API, trasformali e inviali a database o fogli di calcolo secondo una pianificazione.
• Catene di agenti IA. Collega gli LLM ai tuoi strumenti interni per creare assistenti IA personalizzati in grado di cercare, riassumere e agire sui tuoi dati.

(È con quest’ultimo caso che le risorse del server iniziano a contare. Maggiori dettagli nella sezione sulle specifiche.)

Quanto Costa il Self-Hosting di n8n?

La Community edition self-hosted non prevede costi di licenza né di esecuzione n8n per gli usi consentiti. Il costo totale comprende il server più l’eventuale dominio, lo spazio per i backup e il tempo di amministrazione. L’analisi dei costi 2026 di ExpressTech stima un VPS base con Docker a $4–5 al mese, un VPS gestito con Coolify a $5–8 e le piattaforme n8n gestite con un clic a $3–7.

Queste sono le stime di hosting di terze parti di ExpressTech. Per un dato di prima mano: il piano che consigliamo più avanti, DreamHost VPS Hosting Stack 4, ad agosto 2026 costa $8,99/mese per i primi 3 mesi con fatturazione mensile e si rinnova automaticamente a $15,99/mese dopo tale periodo, con l’intero periodo più le tasse addebitati al checkout (i prezzi attuali sono nella pagina VPS per n8n).

Confrontalo con i piani in hosting e con licenza di n8n, come riportati nella pagina dei prezzi di n8n. n8n indica i prezzi in euro, e queste sono le tariffe con fatturazione annuale:

Piano	Costo mensile	Limite di esecuzioni
n8n Cloud Starter	€20/mese	2.500 esecuzioni
n8n Cloud Pro	€50/mese	10.000 esecuzioni
n8n Business (licenza self-hosted)	€667/mese	40.000 esecuzioni
Community edition self-hosted su un VPS	Nessun costo di licenza o di esecuzione n8n per gli usi consentiti; possono applicarsi costi di VPS, dominio, spazio per i backup e amministrazione	Nessuna quota

Il divario si allarga se consideri come ciascuna piattaforma conteggia l’utilizzo. n8n conteggia un’esecuzione per ogni avvio del workflow, “indipendentemente dalla complessità”, e ogni piano include passaggi illimitati. Zapier, invece, conteggia ogni passaggio d’azione riuscito come un task.

Quindi un workflow con quattro passaggi d’azione eseguito 100 volte al giorno corrisponde a 3.000 esecuzioni n8n al mese, ma a circa 12.000 task Zapier.

I numeri reali lo confermano. L’analisi di ExpressTech esamina l’esempio di quattro workflow per un totale di circa 7.000 esecuzioni al mese: un carico che supera n8n Cloud Starter e richiede il livello Pro (indicato lì a $60/mese con fatturazione mensile), mentre una configurazione self-hosted da $3–7/mese lo gestisce senza limiti, una differenza che stimano in $636–684 all’anno.

I Costi Nascosti del Self-Hosting

I risparmi in dollari sono reali. Ma il self-hosting non è gratuito in ogni senso.

Ecco cosa ti costa:

Il tuo tempo. Il tempo di manutenzione varia in base al carico di lavoro e alla tua esperienza operativa, ma sarai responsabile di aggiornamenti, backup, monitoraggio e test di ripristino. Le configurazioni più pesanti con automazioni basate sull’IA richiederanno di più.

Attriti nella configurazione OAuth. Collegare servizi come Google Workspace o Microsoft 365 richiede la configurazione di credenziali OAuth. Prevedi tempo di configurazione aggiuntivo per ogni provider e segui la documentazione della sua console. (Se hai mai fissato uno spinner di caricamento mentre una schermata di consenso decide se fidarsi della tua app, conosci la sensazione.)

Un TLS di cui fidarsi, ma da verificare. Il proxy Caddy della configurazione qui sotto ottiene e rinnova automaticamente un certificato attendibile pubblicamente, usando un’autorità emittente come Let’s Encrypt o ZeroSSL. Automatico non significa infallibile: dopo modifiche al DNS o al proxy, verifica che il certificato si rinnovi ancora.

Curva di apprendimento se sei alle prime armi con i server. La guida qui sotto presuppone che tu sappia accedere a un server via SSH, modificare un file ed eseguire comandi. Se non l’hai mai fatto, metti in conto del tempo per imparare oltre al deployment vero e proprio.

Di Quali Specifiche Server Ha Bisogno n8n?

n8n di per sé è leggero. Quanto di più vicino a un dimensionamento ufficiale sono i valori di esempio nella documentazione sul deployment OEM di n8n, che n8n definisce “solo a scopo illustrativo”, basati su n8n Cloud: un intervallo di memoria da 320 MB a 2 GB, un database su SSD da 512 MB a 4 GB e circa 100 MB di memoria per un’istanza inattiva. Come allocazione iniziale prudente, e non come minimo ufficiale di n8n, considera 2 GB per i test e 4 GB quando aggiungi PostgreSQL e workflow di produzione. Monitora workflow rappresentativi e aggiungi memoria quando la pressione diventa costante.

Ricorda inoltre che n8n di solito è limitato più dalla memoria che dalla CPU. La documentazione di n8n lo dice chiaramente: la piattaforma “non è CPU intensive” e “di solito, i requisiti di memoria prevalgono su quelli di CPU”. A far salire la memoria sono i tuoi workflow: il volume di dati, i nodi Code (che copiano i dati prima e dopo l’elaborazione) e i file binari di grandi dimensioni.

Ecco il nostro rapido calcolo a spanne per dimensionare il margine:

Dimensiona in base alla concorrenza delle esecuzioni e al volume di dati che ogni workflow elabora, poi monitora l’uso della memoria con un carico di lavoro rappresentativo. I nodi Code e i payload binari di grandi dimensioni possono aumentare i requisiti di memoria, quindi lascia un margine e scala il VPS quando il monitoraggio mostra una pressione costante.

Sei alle prime armi con l’hosting VPS? Inizia con la guida per principianti al VPS di DreamHost per comprendere le basi prima di dimensionare il tuo server.

Quale VPS Scegliere per n8n Self-Hosted?

n8n non pubblica livelli di RAM fissi in base al carico di lavoro. Dimensiona in base alla concorrenza delle esecuzioni e al volume di dati, lascia margine per Docker e PostgreSQL, poi monitora workflow rappresentativi e scala quando la pressione sulla memoria è costante.

Ecco quindi come lo tradurremmo nei piani DreamHost:

Piano	Specifiche	Quando sceglierlo
DreamHost VPS Hosting Stack 4	4 GB di RAM, 2 vCPU, 75 GB SSD NVMe	Un’allocazione iniziale di 4 GB, non verificata con benchmark ma prudente, per un primo server n8n.
DreamHost VPS Hosting Stack 8	8 GB di RAM, 2 vCPU, 150 GB SSD NVMe	L’opzione da 8 GB per un margine di memoria aggiuntivo quando il monitoraggio mostra una pressione costante, con il doppio di RAM e storage.
DreamHost VPS Hosting Stack 16	16 GB di RAM, 4 vCPU, 250 GB SSD NVMe	L’opzione da 16 GB per maggiore concorrenza, volumi di dati più grandi o l’aggiunta di worker Redis in modalità coda.

Alcune specifiche a cui prestare attenzione oltre alla RAM: n8n indica lo storage SSD come best practice per il database. Di solito i requisiti di memoria superano quelli di CPU, ma il vero collo di bottiglia dipende dalla concorrenza dei workflow, dal volume di dati e dai nodi che usi. La larghezza di banda illimitata è importante se gestisci carichi di lavoro ricchi di webhook con un flusso costante di richieste HTTP in arrivo.

Scegli un ambiente di hosting che ti permetta di eseguire Docker e di configurare database, rete, storage persistente e reverse proxy. L’hosting condiviso tradizionale in genere non offre quel livello di controllo.

I piani di Hosting VPS di DreamHost soddisfano i requisiti essenziali (storage SSD NVMe, larghezza di banda illimitata, accesso root completo e supporto per Docker), e n8n è nella libreria di app con un clic, preinstallato con PostgreSQL e SSL automatico se preferisci saltare la configurazione manuale qui sotto.

La nostra scelta per un primo server n8n è Stack 4. Ad agosto 2026 costa $8,99/mese per i primi 3 mesi con fatturazione mensile e si rinnova automaticamente a $15,99/mese, con l’intero periodo più le tasse addebitati al checkout; la pagina VPS per n8n mostra sempre le tariffe attuali. Quel prezzo di rinnovo è il numero onesto da confrontare con i €20/mese di n8n Cloud Starter.

Ah, e una cosa da tenere a mente per dopo: man mano che il tuo utilizzo cresce, n8n supporta la modalità coda, un’architettura di scalabilità che separa l’istanza principale (UI, trigger, webhook) dall’esecuzione dei workflow, usando Redis come message broker e istanze worker per eseguire i job. La documentazione di n8n la definisce la modalità che “offre la migliore scalabilità”.

Come Configuri n8n Su Un VPS?

Il deployment di un’istanza n8n self-hosted richiede 11 passaggi: DNS, protezione di SSH, un firewall, Docker, segreti, un file Compose per lo stack a tre container (n8n, PostgreSQL e Caddy), il Caddyfile, avvio e verifica, aggiornamenti, backup e un test di ripristino. Caddy è il nostro reverse proxy: il server che si posiziona tra internet e la tua applicazione, gestendo TLS e routing. Includiamo i comandi per il deployment principale e per un test manuale di backup e ripristino.

I comandi sono pensati per Ubuntu 22.04 o più recente, ma sostituisci il dominio di esempio, i valori segreti, il nome del volume e i nomi dei file di backup datati dove indicato. La documentazione di n8n su Docker Compose copre gli stessi argomenti con un proxy Traefik, se preferisci seguire il modello di n8n.

Cosa Ti Servirà Prima Di Iniziare

• Un VPS con accesso root con Ubuntu 22.04 o più recente e almeno 2 GB di RAM (4 GB è la nostra raccomandazione prudente per la produzione)
• Un nome di dominio che puoi puntare all’indirizzo IP del tuo server (per il TLS e per accedere all’editor di n8n)
• Dimestichezza di base con il terminale : dovresti sapere come accedere a un server via SSH, modificare un file ed eseguire comandi

Un altro prerequisito che non compare in nessun elenco ufficiale: fai il backup della tua N8N_ENCRYPTION_KEY nel momento stesso in cui la generi. Per questo il passaggio 5 ti fa creare la chiave con openssl rand -hex 32 prima del primo avvio, invece di lasciare che n8n ne generi una in silenzio. Questa chiave cripta tutte le credenziali memorizzate, incluse ogni chiave API, token OAuth e password di database che hai collegato. La documentazione Docker di n8n avverte che, se la chiave non viene trovata all’avvio, n8n ne crea una nuova e le credenziali esistenti non possono più essere decifrate: in pratica dovrai ricostruire ogni singola integrazione da zero (e rimpiangere le tue scelte di vita). Copiala in un posto sicuro, separato dai backup del database.

Se il tuo provider ti ha fornito solo un accesso root, crea prima un utente per il deployment, dalla console del provider o da una sessione SSH come root, prima dei comandi SSH locali del passaggio 2:

adduser deploy
usermod -aG sudo deploy

Tutto ciò che segue viene eseguito con quell’utente, usando sudo dove serve.

Passaggio 1: Punta il tuo dominio al server

Crea un record DNS A per un sottodominio dedicato (n8n.example.com in tutta questa guida) che punti all’indirizzo IP del tuo server, esattamente come descritto nella guida di n8n su Docker Compose. Fallo per primo: se il DNS non si è propagato, Caddy non può ottenere un certificato e il browser potrebbe mostrare un errore di sicurezza invece dell’editor di n8n.

Passaggio 2: Proteggi l’accesso SSH

Sul tuo computer locale, genera una coppia di chiavi (la documentazione OpenSSH di Ubuntu consiglia ed25519) e copiala sul server:

ssh-keygen -t ed25519
ssh-copy-id deploy@your_server_ip

Verifica di riuscire ad accedere con la chiave. Poi, sul server, disattiva gli accessi con password e come root, e controlla cosa applicherà effettivamente sshd:

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf > /dev/null <<'EOF'
PasswordAuthentication no
PermitRootLogin no
EOF
sudo sshd -t
sudo sshd -T | grep -E '^(passwordauthentication|permitrootlogin) '

Il prefisso 00- è voluto. OpenSSH usa il primo valore che legge per ogni parola chiave, secondo il manuale di sshd_config, e le immagini dei server cloud includono spesso drop-in precedenti nella stessa directory (cloud-init, per esempio, scrive le sue impostazioni SSH in 50-cloud-init.conf). Se chiami il tuo file 99-hardening.conf, uno di quei frammenti può prevalere senza che tu te ne accorga. sshd -t controlla che la configurazione non contenga errori; sshd -T stampa le impostazioni effettive dopo l’unione di tutti i file. Verifica che l’ultimo comando stampi passwordauthentication no e permitrootlogin no prima di andare avanti. Poi riavvia sshd:

sudo systemctl restart ssh.service

La documentazione di Ubuntu avverte che una configurazione errata di sshd su un server remoto può chiuderti fuori. Tieni aperta la sessione attuale e prova un nuovo accesso in un secondo terminale prima di chiudere qualsiasi cosa.

Passaggio 3: Attiva il firewall

Ubuntu include UFW (Uncomplicated Firewall) disattivato per impostazione predefinita. Consenti SSH prima di attivarlo, così il firewall non può interrompere la tua stessa sessione:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw --force enable
sudo ufw status

Tre porte, nient’altro. Un avvertimento specifico di Docker dalla documentazione di installazione di Docker: le porte che Docker pubblica sull’host aggirano completamente le regole di UFW. Ecco perché il file Compose del passaggio 6 pubblica porte sull’host solo per Caddy: 80 e 443 sono le uniche porte dei container pubblicate da Compose (anche SSH sulla 22 è aperta), mentre n8n e PostgreSQL non hanno alcuna porta pubblicata sull’host.

Passaggio 4: Installa Docker e Docker Compose

Installa Docker Engine dal repository apt ufficiale di Docker, non con lo script di comodo get.docker.com, che la documentazione di Docker consiglia solo per test e sviluppo. Prima i prerequisiti e la chiave di firma di Docker:

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

Poi registra il repository vero e proprio. Questo comando scrive il file del repository tratto dalla guida di installazione di Docker per Ubuntu, inserendo automaticamente la tua release di Ubuntu:

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

Poi installa e verifica:

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo docker run hello-world

Se hello-world stampa il suo messaggio di conferma, Docker e il plugin Compose sono pronti.

Passaggio 5: Crea la directory del progetto e i segreti

Crea la directory del progetto, poi genera la tua chiave di crittografia; non lasciare che n8n ne inventi una in silenzio al primo avvio:

sudo mkdir -p /opt/n8n-compose
cd /opt/n8n-compose
openssl rand -hex 32

Copia subito l’output in un posto sicuro, fuori dal server. Poi inseriscilo, insieme a una password del database robusta, in un file .env protetto accanto al file compose (Docker Compose lo legge automaticamente). Sostituisci entrambi i valori segnaposto con i tuoi:

sudo tee /opt/n8n-compose/.env > /dev/null <<'EOF'
POSTGRES_PASSWORD=choose_a_strong_password
N8N_ENCRYPTION_KEY=paste_the_64_character_key_you_just_generated
EOF
sudo chmod 600 /opt/n8n-compose/.env

Il chmod 600 è importante: questo file contiene segreti, quindi solo il suo proprietario (root) deve poterlo leggere. Nel file compose, N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true applica lo stesso principio all’interno del container: secondo il riferimento delle variabili di sicurezza di n8n, fa sì che n8n provi a impostare i permessi 0600 sul proprio file di impostazioni.

Passaggio 6: Scrivi il file Docker Compose

Crea /opt/n8n-compose/docker-compose.yml (per esempio con sudo nano /opt/n8n-compose/docker-compose.yml) e incolla quanto segue, sostituendo n8n.example.com con il tuo dominio in entrambe le righe con l’URL e impostando il tuo fuso orario:

services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config

  n8n:
    image: docker.n8n.io/n8nio/n8n:2.36.7
    restart: unless-stopped
    expose:
      - "5678"
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_HOST=n8n.example.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - N8N_WEBHOOK_URL=https://n8n.example.com/
      - N8N_PROXY_HOPS=1
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - GENERIC_TIMEZONE=America/New_York
      - TZ=America/New_York
      - EXECUTIONS_DATA_MAX_AGE=168
    depends_on:
      postgres:
        condition: service_healthy
    volumes:
      - n8n_data:/home/node/.n8n

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

volumes:
  caddy_data:
  caddy_config:
  n8n_data:
  postgres_data:

Cinque dettagli meritano il loro posto:

• L’immagine è fissata a una versione specifica (2.36.7 è l’attuale release stabile mentre scriviamo, secondo la documentazione di installazione di n8n), quindi gli aggiornamenti avvengono solo quando lo decidi tu.
• n8n non pubblica alcuna porta sull’host. È raggiungibile dai container sulla rete Compose, incluso Caddy, ma non tramite una porta pubblicata sull’host, quindi l’editor è raggiungibile solo attraverso il reverse proxy, mai direttamente da internet.
• L’healthcheck costringe n8n ad attendere PostgreSQL. Un semplice depends_on attende solo l’avvio del container, non che il database accetti connessioni. Lo schema condition: service_healthy viene direttamente dal file compose Postgres di esempio di n8n, che distribuisce anch’esso PostgreSQL 18.
• La coppia N8N_WEBHOOK_URL / N8N_PROXY_HOPS è importante dietro un proxy. n8n normalmente costruisce gli URL dei webhook a partire da protocollo, host e porta, e la documentazione di n8n dice che questo non funziona dietro un reverse proxy; quindi imposti manualmente l’URL dei webhook affinché n8n possa “registrare gli URL dei webhook corretti presso i servizi esterni”, imposti N8N_PROXY_HOPS a 1 e ti assicuri che il proxy passi gli header X-Forwarded-For, X-Forwarded-Host e X-Forwarded-Proto. (La stessa pagina segnala che N8N_WEBHOOK_URL sostituisce la precedente WEBHOOK_URL, deprecata a partire da n8n 2.35.0.)
• TZ e GENERIC_TIMEZONE svolgono compiti diversi. Secondo la documentazione Docker di n8n, GENERIC_TIMEZONE regola i nodi di pianificazione come Schedule, mentre TZ imposta il fuso orario di sistema del container (quello riportato da comandi come date). Imposta entrambe sullo stesso valore.

(Parti con PostgreSQL fin dal primo giorno. n8n usa SQLite per impostazione predefinita, che va bene per i test, ma i modelli di hosting di n8n consigliano PostgreSQL per la produzione, e migrare in seguito è doloroso, nel senso di “avrei dovuto farlo bene fin dall’inizio”.)

Passaggio 7: Scrivi il Caddyfile

Crea /opt/n8n-compose/Caddyfile con il tuo dominio (di nuovo, sostituisci n8n.example.com):

n8n.example.com {
    reverse_proxy n8n:5678
}

Questa è tutta la configurazione del reverse proxy. Secondo la documentazione di Caddy sull’HTTPS automatico, Caddy ottiene e rinnova automaticamente un certificato attendibile pubblicamente, usando un’autorità emittente come Let’s Encrypt o ZeroSSL, e reindirizza HTTP su HTTPS, a condizione che il tuo record DNS A punti al server e che le porte 80 e 443 siano aperte (passaggi 1 e 3). Caddy è anche uno dei reverse proxy presenti negli esempi di hosting ufficiali di n8n.

Passaggio 8: Avvia e verifica

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

Aspetta che ps mostri il container postgres in stato healthy e n8n in esecuzione, poi controlla la porta d’ingresso da qualsiasi computer:

curl -fsS -o /dev/null -w '%{http_code}' https://n8n.example.com/

Un codice 2xx (o un reindirizzamento 3xx) significa che Caddy ha gestito la terminazione TLS e n8n ha risposto; se invece curl termina con un errore, bisogna controllare il DNS, il certificato o i container (sudo docker compose logs caddy e sudo docker compose logs n8n sono i primi posti da guardare). Apri https://n8n.example.com in un browser e crea il tuo account proprietario.

Passaggio 9: Aggiorna n8n in modo consapevole

n8n rilascia una nuova versione minore quasi ogni settimana, e le sue istruzioni di aggiornamento ti chiedono di controllare il changelog delle modifiche incompatibili prima di aggiornare. Quando sei pronto: modifica il tag di versione in docker-compose.yml, poi

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

Con un tag fissato, il solo pull non cambia nulla: sei tu a scegliere ogni aggiornamento cambiando il tag, ed è proprio questo lo scopo del pinning. Esegui un backup (passaggio 10) prima degli aggiornamenti di versione principale.

Passaggio 10: Pianifica i backup

Per un ripristino utilizzabile servono tre cose: il database PostgreSQL, il volume n8n_data e il file .env che fornisce la N8N_ENCRYPTION_KEY. La documentazione Docker di n8n è esplicita: anche se usi PostgreSQL, la cartella /home/node/.n8n (il nostro volume n8n_data) contiene comunque dati essenziali, incluso il materiale della chiave di crittografia. Esegui il backup di tutti e tre, e conserva docker-compose.yml e Caddyfile per poter ricostruire lo stack. Lo script qui sotto gestisce il database e il volume; la copia dei file di configurazione fuori dall’host viene subito dopo. Crea lo script come file di proprietà di root:

sudo tee /opt/n8n-compose/backup.sh > /dev/null <<'EOF'
#!/bin/bash
set -euo pipefail
cd /opt/n8n-compose
STAMP=$(date +%Y-%m-%d)
mkdir -p /opt/n8n-backups
docker compose exec -T postgres pg_dump -U n8n -d n8n > "/opt/n8n-backups/n8n-db-${STAMP}.sql"
docker run --rm -v n8n-compose_n8n_data:/data -v /opt/n8n-backups:/backup alpine \
  tar czf "/backup/n8n-data-${STAMP}.tar.gz" -C /data .
find /opt/n8n-backups -name 'n8n-db-*.sql' -mtime +30 -delete
find /opt/n8n-backups -name 'n8n-data-*.tar.gz' -mtime +30 -delete
EOF
sudo chmod 700 /opt/n8n-compose/backup.sh
sudo /opt/n8n-compose/backup.sh

Note sullo script: n8n-compose_n8n_data è il nome del volume che Compose crea per una directory di progetto chiamata n8n-compose; verifica il tuo con sudo docker volume ls e modificalo se è diverso. Le due righe find conservano 30 giorni di backup; imposta una conservazione diversa in base allo spazio disponibile e alle tue esigenze di ripristino.

Pianificalo dalla crontab di root. Il cron di root deve eseguire sempre e solo uno script di proprietà di root (chmod 700, con il .env a 600), mai un file che un altro utente può modificare. Esegui sudo crontab -e e aggiungi una riga per un’esecuzione giornaliera alle 3 di notte:

0 3 * * * /opt/n8n-compose/backup.sh

Lo script esegue il backup pianificato del database PostgreSQL e del volume n8n_data. Copia fuori dall’host il .env (che contiene la tua chiave di crittografia) e i file di Compose e Caddy, adesso e ogni volta che cambiano. Sul server, crea un archivio temporaneo protetto:

sudo tar -C /opt/n8n-compose -czf /home/deploy/n8n-config.tar.gz .env docker-compose.yml Caddyfile
sudo chown deploy:deploy /home/deploy/n8n-config.tar.gz
chmod 600 /home/deploy/n8n-config.tar.gz

Poi, dal tuo computer locale, scarica l’archivio di configurazione insieme ai backup ed elimina la copia temporanea sul server:

scp deploy@your_server_ip:/home/deploy/n8n-config.tar.gz .
scp -r deploy@your_server_ip:/opt/n8n-backups .
ssh deploy@your_server_ip 'rm /home/deploy/n8n-config.tar.gz'

Un backup che esiste solo sul server che protegge scompare insieme al server.

Passaggio 11: Testa un ripristino su un VPS di prova

Questa è una procedura di backup e ripristino che ti permette di verificare che i tuoi backup siano utilizzabili. Testa il ripristino su un VPS di prova nuovo, mai sul server di produzione. Crea un server usa e getta, ripeti lì il passaggio 4 (Docker) e copia i file del progetto (docker-compose.yml, Caddyfile, .env) e i backup datati più recenti negli stessi percorsi.

Per prima cosa, cambia l’hostname: inserisci un hostname di test (per esempio n8n-restore-test.example.com, con un record A che punta al VPS di prova) in N8N_HOST, N8N_WEBHOOK_URL e nel Caddyfile. Poi, sostituendo i nomi dei file datati con i tuoi:

cd /opt/n8n-compose
sudo docker compose create
sudo docker run --rm -v n8n-compose_n8n_data:/data -v /opt/n8n-backups:/backup alpine \
  sh -c "cd /data && tar xzf /backup/n8n-data-2026-08-25.tar.gz"
sudo docker compose up -d --wait postgres
sudo docker compose exec -T postgres psql -U n8n -d n8n < /opt/n8n-backups/n8n-db-2026-08-25.sql
sudo docker compose run --rm n8n unpublish:workflow --all
sudo docker compose up -d

La riga unpublish:workflow --all usa la Server CLI integrata di n8n per annullare la pubblicazione di ogni workflow ripristinato prima dell’avvio dell’istanza, così le pianificazioni e i trigger ripristinati non si attivano contro i tuoi sistemi di produzione dalla macchina di test. Concludi con lo stesso controllo curl del passaggio 8, sull’hostname di test.

Sii onesto con te stesso su cosa significa un controllo superato: conferma che il database e il volume sono stati ripristinati e che lo stack si avvia correttamente. Non mette alla prova i tuoi workflow tramite l’editor, quindi accedi all’istanza di test e controlla a campione quelli che non puoi permetterti di perdere.

Come Mantieni Sicura un’Istanza n8n Self-Hosted?

Un’istanza n8n self-hosted è sicura quanto il server su cui gira, e sei tu a controllare quel server.

La sicurezza si riduce a sei elementi. Nessuno di essi è complicato preso singolarmente, ma tralasciarne anche solo uno lascia una vera lacuna. La configurazione qui sopra implementa già i primi tre.

1. HTTPS tramite un reverse proxy. Non accedere mai all’editor di n8n tramite HTTP semplice. La configurazione di Caddy del passaggio 7 ottiene e rinnova automaticamente un certificato attendibile pubblicamente, usando un’autorità emittente come Let’s Encrypt o ZeroSSL, e reindirizza HTTP su HTTPS.
2. Firewall blindato. UFW consente solo SSH (22), HTTP (80) e HTTPS (443). Non esporre mai la porta predefinita di n8n, la 5678, direttamente su internet. Il file compose qui sopra lo garantisce non assegnando a n8n alcuna porta pubblicata sull’host, così solo i container sulla rete Compose possono raggiungerlo.
3. Isolamento della rete Docker. PostgreSQL e n8n comunicano tramite la rete Compose interna. La porta del database non viene mai pubblicata sull’host, quindi non è mai raggiungibile dall’esterno.
4. Autenticazione forte. Usa una password robusta per il proprietario e attiva l’autenticazione a due fattori; la guida alla sicurezza di n8n elenca la 2FA tra le protezioni consigliate per le istanze self-hosted.
5. Aggiornamenti regolari. Aggiorna il tag di versione nel file compose, poi esegui il pull e riavvia (passaggio 9). Leggi prima il changelog, perché gli aggiornamenti di n8n possono includere modifiche incompatibili.
6. Backup che hai davvero ripristinato. I passaggi 10 e 11 ti forniscono la pianificazione e il test. Un backup mai testato è una speranza, non un piano.

Un’altra cosa da tenere d’occhio che non riguarda strettamente la sicurezza, ma che farà una grande differenza. Per impostazione predefinita, n8n salva nel database l’input e l’output di ogni esecuzione. La pulizia automatica è attiva per impostazione predefinita: n8n elimina le esecuzioni più vecchie di 336 ore (14 giorni), oppure quando superi le 10.000 esecuzioni archiviate. Un’istanza molto attiva può comunque gonfiare PostgreSQL nel frattempo.

Se i tuoi workflow sono loquaci, restringi i limiti: imposta EXECUTIONS_DATA_MAX_AGE=168 per eliminare i dati di esecuzione più vecchi di sette giorni (il file compose qui sopra lo fa già), oppure evita del tutto di archiviare le esecuzioni riuscite con EXECUTIONS_DATA_SAVE_ON_SUCCESS=none.

Quali Sono i Compromessi tra Self-Hosting e n8n Cloud?

Il self-hosting di n8n ti offre un’istanza senza quote di esecuzione e il controllo sui dati che archivia, al costo di un piccolo VPS più la tua amministrazione. n8n Cloud ti offre zero manutenzione del server, con limiti di esecuzione in base al livello. La scelta dipende dal fatto che tu voglia possedere la tua infrastruttura di automazione o pagare qualcun altro per gestirla.

La documentazione di n8n lo espone così: “n8n consiglia il self-hosting agli utenti esperti. Gli errori possono portare a perdita di dati, problemi di sicurezza e downtime. Se non hai esperienza nella gestione dei server, n8n consiglia n8n Cloud.”

Ecco come si confrontano le due opzioni:

Fattore	Self-hosted	n8n Cloud
Costo mensile	La fattura del tuo VPS più l’eventuale dominio, lo spazio per i backup e i costi di amministrazione (DreamHost Stack 4: $8,99/mese per 3 mesi, poi $15,99/mese, prezzi di agosto 2026; stime di terze parti 2026 di ExpressTech: $4–8/mese)	€20–50 (con fatturazione annuale), in base al livello
Esecuzioni	Nessuna quota; la capacità dipende dalle risorse del tuo server	2.500 (Starter) o 10.000 (Pro)
Configurazione	La guida in 11 passaggi qui sopra	Pochi minuti
Manutenzione	Aggiornamenti, backup e monitoraggio sono a tuo carico	Gestita da n8n
Posizione dei dati	Il tuo server	Infrastruttura di n8n
Aggiornamenti	Manuali (aggiorna il tag, pull, riavvio)	Automatici
TLS	Caddy ottiene e rinnova automaticamente i certificati (autorità emittente come Let’s Encrypt o ZeroSSL)	Gestito per te
Scalabilità	Aggiungi RAM, o usa la modalità coda con worker Redis	Passa a un livello superiore del piano

Esiste anche una via di mezzo che vale la pena conoscere. Piattaforme gestite come PikaPods (circa $3,80/mese) ed Elestio (circa $17/mese, secondo il confronto di ExpressTech) eseguono n8n self-hosted senza che tu debba gestire il server. Questi servizi possono ridurre il lavoro di amministrazione del server, ma verifica chi si occupa di aggiornamenti di n8n, backup, monitoraggio e sicurezza.

Ma ecco il quadro generale. Su qualsiasi piano in hosting, la tua capacità di esecuzione è un livello di fatturazione, e i livelli li stabilisce la piattaforma. Prezzi, quote e funzionalità possono cambiare attorno ai workflow che hai già costruito.

Con il self-hosting, l’istanza e i dati che archivia si trovano su un’infrastruttura che controlli tu (i servizi collegati ricevono comunque ciò che i tuoi workflow inviano loro). Pieno controllo, piena responsabilità.

Fare la Scelta Finale

Il self-hosting ha senso quando si allineano tre cose:

1. Esegui abbastanza automazioni da risentire dei limiti di esecuzione del cloud
2. Vuoi che i dati dei tuoi workflow siano su un’infrastruttura che controlli
3. Tu (o qualcuno del tuo team) sei disposto a farti carico di aggiornamenti, backup e monitoraggio

Altrimenti, n8n Cloud è una scelta ragionevole. Pagare il piano Starter per non dover mai pensare ai log di Docker è un compromesso equo, soprattutto per un piccolo team che vuole semplicemente che le proprie automazioni funzionino.

Ma una volta che sei pronto a superare la soglia del self-hosting, i conti diventano rapidamente decisivi. Un VPS da 4 GB è un punto di partenza pratico, anche se non verificato con benchmark; la capacità in produzione dipende da concorrenza, volume di dati e nodi che usi, quindi monitora l’istanza e scalala man mano che la domanda cresce. Inizia in piccolo, potenzia man mano che i tuoi workflow crescono e mantieni il pieno controllo del tuo stack.

Quest’ultima parte conta più di quanto possa sembrare. Puoi sempre passare a un server più grande. È molto più difficile districarsi da una piattaforma SaaS dopo che ha cambiato i suoi prezzi attorno ai workflow che hai già costruito.

Domande Frequenti sul Self-Hosting di n8n

n8n è davvero gratuito in self-hosting?

Il software n8n è gratuito da eseguire sul tuo server con la Sustainable Use License. La Community edition self-hosted (la versione standard che n8n pubblica su GitHub) non prevede costi di licenza né di esecuzione n8n per gli usi consentiti, come l’automazione interna della tua azienda. La parte “gratuita” è il software; pagherai comunque il server, più l’eventuale dominio, lo spazio per i backup e il tempo di amministrazione.

La licenza vieta di vendere un prodotto, un servizio o un modulo il cui valore derivi interamente o in modo sostanziale dalle funzionalità di n8n. Consulta le FAQ sulla licenza di n8n se l’uso che hai in mente prevede di offrire ai clienti funzionalità basate su n8n.

Quali sono i requisiti minimi di sistema per n8n?

n8n pubblica un dimensionamento di esempio anziché un minimo rigido, e definisce quei valori indicativi (provengono dalla sua documentazione sul deployment OEM): circa 100 MB di memoria a riposo, un intervallo di memoria di esempio di 320 MB–2 GB e un database su SSD di 512 MB–4 GB. Come allocazione iniziale prudente, e non come minimo ufficiale di n8n, considera 2 GB per i test e 4 GB quando aggiungi PostgreSQL e workflow di produzione, poi monitora e aggiungi memoria quando la pressione diventa costante.

Il piano DreamHost VPS Hosting Stack 4 offre 4 GB di RAM con storage SSD NVMe e accesso root completo per eseguire applicazioni self-hosted come n8n. Consulta i piani di Hosting VPS per i dettagli.

Usa PostgreSQL invece di SQLite in produzione e preferisci lo storage SSD, perché n8n lo indica come best practice per il database.

Posso eseguire n8n in locale invece che su un VPS?

Sì, un solo comando Docker avvia n8n sul tuo computer, ed è un ottimo modo per testare i workflow prima di impegnarti con un server. Il problema sono i webhook: i workflow attivati da servizi esterni richiedono che la tua istanza sia raggiungibile da internet, cosa che un portatile dietro un router domestico non è per impostazione predefinita. Port forwarding, VPN e tunnel possono aggirare il problema, ciascuno con i propri compromessi in termini di configurazione e sicurezza.

n8n offre un servizio di tunnel per inoltrare i webhook a un’istanza locale, ma la sua documentazione Docker è schietta: il tunnel è “pensato solo per lo sviluppo e i test in locale” e non va usato in produzione. Per tutto ciò che gira senza sosta, usa un VPS.

Posso migrare da Zapier a n8n?

Non aspettarti un’importazione con un clic. Metti in conto di ricostruire i tuoi workflow nell’editor visuale di n8n anziché importarli da Zapier.

La buona notizia: n8n offre oltre 400 integrazioni, ma verifica ogni app, trigger e azione usati dai tuoi workflow attuali prima di pianificare la migrazione. I workflow semplici si ricostruiscono rapidamente; le sequenze complesse in più passaggi richiedono più tempo.

Come aggiorno un’istanza n8n self-hosted?

Modifica il tag di versione nel tuo docker-compose.yml impostando la release che vuoi, poi esegui docker compose pull seguito da docker compose up -d. Con un tag fissato come docker.n8n.io/n8nio/n8n:2.36.7, il solo pull non cambia nulla: sei tu a scegliere ogni aggiornamento cambiando il tag, ed è proprio questo lo scopo del pinning. (Se invece usi il tag latest, basta un pull e un riavvio, ma ogni riavvio diventa un aggiornamento a sorpresa.)

Esegui il backup del database PostgreSQL prima degli aggiornamenti di versione principale. Lo script di backup della guida qui sopra se ne occupa, oppure esegui pg_dump direttamente nel container PostgreSQL.

Gli aggiornamenti frettolosi rompono le cose, e n8n rilascia una nuova versione minore quasi ogni settimana. Le istruzioni di aggiornamento di n8n ti chiedono di controllare il changelog delle modifiche incompatibili prima di aggiornare, quindi leggilo prima di eseguire il pull. Il riavvio in sé è rapido; è la lettura del changelog che merita il tuo tempo.

n8n self-hosted è abbastanza sicuro per i dati aziendali?

Il self-hosting ti dà il controllo su dove n8n archivia le definizioni dei workflow, le credenziali e i dati di esecuzione. Tuttavia, i servizi collegati ricevono comunque i dati che i tuoi workflow inviano loro, e la protezione del server resta una tua responsabilità.

Segui la checklist in sei punti della sezione sulla sicurezza qui sopra: HTTPS, firewall, isolamento Docker, autenticazione forte con 2FA, aggiornamenti regolari e backup testati. Il team di n8n mantiene una guida alla sicurezza che copre ulteriori aspetti per la produzione, dagli audit di sicurezza all’autenticazione a due fattori.