Sei passaggi da un VPS nordico spoglio a un n8n con terminazione TLS sul proprio dominio — Docker Compose, Caddy, PostgreSQL, webhook che scattano davvero. Esecuzioni limitate dalla sua CPU, non da un piano tariffario, su una macchina che costa $3.90 al mese. Testato su Debian 12 con n8n 2.x.
Provisioning
VPS + un record A
Installare
get.docker.com
Compose
n8n + Caddy + Postgres
Primo avvio
Account owner + 2FA
Webhook
WEBHOOK_URL
Hardening
Pulizia, silenzio, backup
n8n è un motore di automazione dei workflow: una canvas visuale dove collega un trigger — un webhook, uno schedule, una nuova riga in un database, un messaggio in una coda — a una catena di nodi che chiamano API, trasformano dati, si ramificano su condizioni, eseguono JavaScript o Python arbitrari, e passano il risultato a qualsiasi cosa venga dopo. Diverse centinaia di nodi di integrazione sono inclusi di serie, più un nodo HTTP Request generico che copre tutto il resto. Dalla linea 1.x porta anche nodi AI Agent e LLM, motivo per cui gran parte di chi lo installa nel 2026 sta costruendo agenti piuttosto che la classica infrastruttura ETL.
La parte che conta prima di digitare un solo comando è la licenza, perché n8n non è open source nel senso OSI e la differenza non è accademica. Il nucleo viene distribuito sotto la Sustainable Use License: una concessione non esclusiva, senza royalty, valida in tutto il mondo, per usare, copiare, modificare e distribuire il software per finalità aziendali interne e per uso personale o non commerciale. Ciò che non concede è il diritto di far pagare altri per n8n o per un suo derivato — la clausola che esclude la costruzione di un prodotto «managed n8n» a pagamento sopra di esso. Separatamente, qualsiasi file che porti .ee. nel nome o .ee nel percorso è escluso interamente da quella licenza e richiede una n8n Enterprise License a pagamento.
In parole semplici: eseguire n8n su un VPS per automatizzare la propria azienda, il lavoro dei propri clienti erogato come servizio che presta, o la propria vita personale, rientra nella concessione gratuita e lo è sempre stato. Vendere n8n-come-prodotto-di-hosting no. Quasi ogni discussione su internet sul tema «n8n è davvero gratuito?» è fatta di due persone che parlano senza intendersi, ciascuna da un lato di questa linea.
Il lato dei costi. n8n Cloud ha un prezzo per esecuzione: il piano Starter è €20 al mese fatturati annualmente per 2 500 esecuzioni, Pro è €50 al mese per 10 000, Business è €667 al mese per 40 000. In self-hosting, il numero di esecuzioni non è affatto una voce a parte — è limitato da quanta CPU e memoria ha la macchina. Un workflow che interroga un'API ogni cinque minuti consuma da solo 8 640 esecuzioni al mese; su Cloud quel singolo workflow costringe già al tier Pro, mentre su un VPS da $3.90 è un errore di arrotondamento rispetto alla CPU a riposo.
| Opzione | Mensile | Esecuzioni incluse | Chi lo gestisce |
|---|---|---|---|
| n8n Cloud · Starter | €20 | 2 500 | n8n GmbH |
| n8n Cloud · Pro | €50 | 10 000 | n8n GmbH |
| n8n Cloud · Business | €667 | 40 000 | n8n GmbH |
| Self-hosted · VPS Sentinel | $3.90 | Limitato dalla CPU, non a consumo | Lei |
Prezzi Cloud come pubblicati su n8n.io ad agosto 2026, fatturati annualmente; la fatturazione mensile costa di più. Lo scambio non riguarda solo il denaro — l'auto-hosting sposta aggiornamenti, backup, rinnovo TLS e uptime dalla sua parte della linea.
La documentazione Docker Compose ufficiale di n8n indica come minimo 2 vCPU e 4 GB di RAM. Non è un numero di marketing: al di sotto di esso, il front-end dell'editor e un workflow moderatamente ramificato si contenderanno la memoria, e il primo payload JSON di grandi dimensioni farà terminare il container con un out-of-memory kill.
Sentinel · 2 vCPU, 4 GB, 120 GB NVMe, $3.90/mese. La scelta predefinita giusta. Esegue n8n, PostgreSQL e Caddy insieme con margine per un'istanza personale o di un piccolo team che effettua qualche centinaio di esecuzioni al giorno. La memoria a riposo si attesta intorno ai 700 MB tra i tre container.
Garrison · 4 vCPU, 8 GB, 240 GB NVMe, $7.90/mese. Il passo successivo quando aggiunge la modalità queue con Redis e uno o due container worker, quando i workflow tengono regolarmente in memoria payload di più megabyte, o quando vuole un margine comodo per workflow di AI-agent che si diramano in più rami paralleli.
Ravelin · 8 vCPU, 16 GB, 480 GB NVMe, $16.90/mese. Un'istanza per un team con migliaia di esecuzioni al giorno e lavoro pesante in dati binari — generazione di PDF, elaborazione di immagini, trascrizione audio. Qui i core dedicati contano perché questi carichi di lavoro dipendono dalla CPU piuttosto che dalle API.
Il disco è la parte che si dimentica. n8n memorizza l'input e l'output completi di ogni nodo di ogni esecuzione. Un workflow chiacchierone eseguito ogni minuto scrive centinaia di megabyte a settimana. I valori predefiniti fanno pulizia — EXECUTIONS_DATA_PRUNE è true, EXECUTIONS_DATA_MAX_AGE è 336 ore (quattordici giorni) e EXECUTIONS_DATA_PRUNE_MAX_COUNT è 10 000 — ma quattordici giorni di un'istanza intensa restano comunque tanto NVMe. Il passo 06 li restringe.
Nel pannello: Order → VPS → Sentinel, immagine Debian 12. Non è richiesto alcun indirizzo email per aprire l'account, non viene richiesto alcun documento d'identità in nessun momento, e la fattura si salda in Monero, Bitcoin, Lightning o uno qualsiasi degli altri asset supportati. Scelga il bastione in base alla latenza verso i servizi che automatizza, non verso se stesso — un server di automazione parla con le API molto più di quanto parli con lei.
Quindi crei il record DNS prima di toccare il server: un record A per n8n.example.com che punti all'IPv4 del VPS, e un record AAAA se usa IPv6. Questo va fatto per primo, perché Caddy chiede a Let's Encrypt un certificato nel momento in cui lo stack si avvia, e una richiesta di certificato per un nome che non si risolve fallisce — poi si ritira, e lei passa venti minuti a chiedersi perché il sito è irraggiungibile.
Conceda al DNS un minuto per propagarsi e lo confermi dalla propria macchina prima di continuare:
dig +short n8n.example.com
# → the IPv4 of your VPS, and nothing else
Prima che qualcosa sia in ascolto su una porta pubblica, esegua la checklist di hardening della prima ora — SSH solo a chiave, un firewall che consente solo 22, 80 e 443, e aggiornamenti di sicurezza automatici. Un server di automazione è un caveau di credenziali; merita l'ora intera.
Si colleghi via SSH e installi il Docker Engine con il plugin Compose v2:
apt update && apt install -y ca-certificates curl
curl -fsSL https://get.docker.com | sh
docker compose version
Lo script di convenienza installa Engine, CLI, containerd e il plugin Compose dal repository ufficiale di Docker. L'ultima riga dovrebbe stampare Docker Compose version v2 o superiore; se stampa «docker: 'compose' is not a docker command» ha installato il pacchetto docker.io più vecchio della distribuzione e dovrebbe rimuoverlo prima.
Esiste un installer n8n a una riga che avvolge tutto questo, e funziona. Questa guida scrive invece il file Compose a mano, perché tutto ciò che dovrà cambiare in seguito — la chiave di cifratura, il database, l'URL del webhook, la policy di retention, il numero di worker — vive in quel file, e uno stack che non si può leggere è uno stack che non si può riparare alle tre di notte.
Crei prima la directory e generi i due segreti. Li generi ora, in quest'ordine, e li incolli nel .env mano a mano — la chiave di cifratura in particolare deve esistere prima del primo avvio di n8n, non dopo.
mkdir -p /opt/n8n && cd /opt/n8n
openssl rand -hex 32 # → N8N_ENCRYPTION_KEY
openssl rand -hex 24 # → POSTGRES_PASSWORD
/opt/n8n/.env
DOMAIN=n8n.example.com
LETSENCRYPT_EMAIL=you@example.com
GENERIC_TIMEZONE=Europe/Stockholm
N8N_ENCRYPTION_KEY=paste_the_32_byte_hex_here
POSTGRES_DB=n8n
POSTGRES_USER=n8n
POSTGRES_PASSWORD=paste_the_24_byte_hex_here
Blocchi subito il file — contiene la chiave di ogni credenziale che l'istanza memorizzerà mai:
chmod 600 /opt/n8n/.env
/opt/n8n/docker-compose.yml
services:
caddy:
image: caddy:2-alpine
restart: unless-stopped
ports:
- "80:80"
- "443:443"
environment:
- DOMAIN=${DOMAIN}
- LETSENCRYPT_EMAIL=${LETSENCRYPT_EMAIL}
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile:ro
- caddy_data:/data
- caddy_config:/config
postgres:
image: postgres:16-alpine
restart: unless-stopped
environment:
- POSTGRES_DB=${POSTGRES_DB}
- POSTGRES_USER=${POSTGRES_USER}
- POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
volumes:
- pg_data:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
interval: 10s
timeout: 5s
retries: 10
n8n:
image: docker.n8n.io/n8nio/n8n:latest
restart: unless-stopped
depends_on:
postgres:
condition: service_healthy
environment:
- N8N_HOST=${DOMAIN}
- N8N_PORT=5678
- N8N_PROTOCOL=https
- N8N_EDITOR_BASE_URL=https://${DOMAIN}
- WEBHOOK_URL=https://${DOMAIN}/
- N8N_PROXY_HOPS=1
- N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
- GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
- TZ=${GENERIC_TIMEZONE}
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
- DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
- DB_POSTGRESDB_USER=${POSTGRES_USER}
- DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
- N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
- N8N_BLOCK_ENV_ACCESS_IN_NODE=true
- N8N_DIAGNOSTICS_ENABLED=false
- N8N_VERSION_NOTIFICATIONS_ENABLED=false
- N8N_PERSONALIZATION_ENABLED=false
volumes:
- n8n_data:/home/node/.n8n
volumes:
caddy_data:
caddy_config:
pg_data:
n8n_data:
/opt/n8n/Caddyfile
{$DOMAIN} {
encode zstd gzip
tls {$LETSENCRYPT_EMAIL}
reverse_proxy n8n:5678
}
Due decisioni progettuali che vale la pena nominare. Primo: n8n non pubblica alcuna porta. Solo Caddy si lega alle porte 80 e 443; n8n resta in ascolto sulla 5678 all'interno della rete Compose, dove nulla al di fuori dell'host può raggiungerlo. Un numero sorprendente di istanze n8n self-hosted è su internet pubblico sulla porta 5678 senza TLS davanti, e i motori di ricerca per servizi esposti le indicizzano. Secondo: il volume dati di n8n resta montato anche se ora PostgreSQL contiene i workflow — quella directory porta ancora le impostazioni dell'istanza, i file di log e gli asset per il controllo di versione.
Lo avvii:
cd /opt/n8n
docker compose up -d
docker compose logs -f caddy # watch the certificate being issued
Apra https://n8n.example.com. La prima schermata è la configurazione dell'account owner — email, password, nome. Non c'è più alcuna variabile d'ambiente per l'HTTP basic-auth da configurare; la gestione utenti è integrata in n8n fin dalla linea 1.x, e l'account che crea qui è il proprietario dell'istanza. Usi una password dal proprio password manager, poi vada direttamente su Settings → Personal → Two-factor authentication e la attivi. Questo login è la porta d'ingresso a ogni chiave API che incollerà mai in un nodo.
n8n cifra ogni credenziale memorizzata con N8N_ENCRYPTION_KEY. Se non la imposta, n8n ne genera una al primo avvio e la scrive dentro il volume dati. Ricrei quel volume — un docker compose down -v, una migrazione a un nuovo server, un ripristino andato male — e la nuova istanza genera una chiave diversa, ogni credenziale nel database diventa indecifrabile, e non c'è alcun percorso di recupero. Deve reinserire a mano ogni chiave API, token OAuth e password. Imposti la chiave esplicitamente, come fa questa guida, e ne conservi una copia fuori dal server.
Il posto giusto per quella copia è un password manager che controlla anche lei — la guida a Vaultwarden self-hosted ne copre uno, e il punto deliberato è che non dovrebbe vivere sulla stessa macchina di ciò che sblocca.
Verifichi che il database sia davvero PostgreSQL e non il fallback SQLite — se le variabili DB_ hanno un refuso, n8n si avvia silenziosamente su SQLite e lo scopre tre mesi dopo:
docker compose exec postgres psql -U n8n -d n8n -c '\dt' | head
# → a list of n8n tables (workflow_entity, credentials_entity, execution_entity…)
Un n8n che si avvia, mostra l'editor ed esegue un test manuale non è ancora un n8n funzionante. La metà che si rompe silenziosamente sono i webhook in entrata, e si rompe in modi che sembrano colpa del servizio terzo.
WEBHOOK_URL. Senza di essa, n8n costruisce gli URL dei webhook a partire da N8N_HOST e N8N_PORT e le fornisce qualcosa come http://localhost:5678/webhook/abc — che poi incolla in Stripe o GitHub, dove non potrà mai essere raggiunto. Il file Compose qui sopra imposta WEBHOOK_URL sulla radice HTTPS pubblica, che è ciò che l'editor mostrerà e ciò che il mondo esterno può effettivamente chiamare.
N8N_EDITOR_BASE_URL. L'URL pubblico che n8n usa per i link nelle email che invia — reset password, inviti utente. Un valore sbagliato qui significa un link d'invito che punta a localhost, il che si traduce in un ticket di supporto da un collega piuttosto che in un'integrazione rotta.
N8N_PROXY_HOPS. n8n legge l'IP del client da X-Forwarded-For, e si fida solo di tanti hop quanti ne indica questo numero. Con un reverse proxy davanti — il Caddy di questo stack — il valore è 1. Metta Cloudflare davanti a Caddy e diventa 2. Lo lasci al valore predefinito 0 e ogni richiesta sembra provenire dal proxy stesso, il che rompe silenziosamente i rate limit e qualsiasi logica basata sull'IP nei suoi workflow.
N8N_SECURE_COOKIE. Il valore predefinito è true, il che significa che il cookie di sessione viene inviato solo via HTTPS. È l'impostazione corretta e questo stack la soddisfa. Vale la pena saperlo perché spiega il sintomo classico di un primo tentativo su http semplice: il modulo di login accetta la password e poi la riporta al modulo di login, all'infinito. La soluzione è il TLS, non disattivare il flag.
Lo testi correttamente. Crei un workflow con un nodo Webhook, attivi il workflow, copi l'URL di produzione, quindi lo richiami da una macchina che non è il server:
curl -i https://n8n.example.com/webhook/<path>
# → HTTP/2 200, and a new execution visible in the editor
La distinzione che inganna tutti almeno una volta: l'URL di test resta in ascolto solo mentre si ha l'editor aperto con «Listen for test event» attivato. L'URL di produzione esiste solo quando il workflow è impostato su Active. Un webhook che funziona nell'editor e restituisce 404 in produzione è quasi sempre un workflow non attivo.
Conservazione. I valori predefiniti conservano quattordici giorni o 10 000 esecuzioni, a seconda di cosa arriva prima, con i dati completi di input e output per ogni nodo. Su un piccolo NVMe con un trigger schedulato molto attivo, è questo a riempire il disco. Aggiunga queste righe al blocco environment di n8n e riavvii:
- EXECUTIONS_DATA_PRUNE=true
- EXECUTIONS_DATA_MAX_AGE=168 # hours — one week
- EXECUTIONS_DATA_PRUNE_MAX_COUNT=5000
- EXECUTIONS_DATA_SAVE_ON_SUCCESS=none # keep failures, drop the noise
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none è il singolo vantaggio più grande su un'istanza ad alta frequenza: smette di scrivere i payload delle esecuzioni riuscite, pur continuando a memorizzare per intero ogni esecuzione fallita così da poterla debuggare. Lo mantenga su «all» mentre sta ancora costruendo il workflow, poi lo cambi una volta che il workflow è diventato noioso.
Silenzio. Il file Compose disattiva già la diagnostica, le notifiche di versione e il sondaggio di personalizzazione. Il chiamante in uscita rimasto è la galleria dei template, che effettua richieste verso api.n8n.io; imposti N8N_TEMPLATES_ENABLED=false se non vuole alcuna chiamata verso terzi. Se disattiva le notifiche di versione, si metta un promemoria mensile in calendario per leggere le release notes — un'istanza self-hosted che nessuno aggiorna è un esito peggiore di una che verifica le versioni.
Il nodo Code. N8N_BLOCK_ENV_ACCESS_IN_NODE=true, già presente nel file, impedisce alle espressioni e ai nodi Code di leggere le variabili d'ambiente del processo — che su questa macchina significa la password di PostgreSQL e la chiave di cifratura. Se non usa la REST API pubblica, aggiunga N8N_PUBLIC_API_DISABLED=true e chiuda anche quella superficie.
Backup — tutte e tre le parti, o nessuna. Un backup del solo database è inutile senza la chiave di cifratura, e la sola chiave non ripristina nulla. Faccia il backup del dump di PostgreSQL, del volume dati di n8n e del .env insieme, e conservi almeno una copia fuori dal server:
cd /opt/n8n
docker compose exec -T postgres pg_dump -U n8n n8n | gzip > backup-db-$(date +%F).sql.gz
docker run --rm -v n8n_n8n_data:/data -v "$PWD":/backup alpine \
tar czf /backup/backup-vol-$(date +%F).tar.gz -C /data .
cp .env backup-env-$(date +%F)
Il nome del volume è il nome del progetto Compose più il nome del volume; se la sua directory non si chiama n8n, esegua docker volume ls e usi ciò che vede. Metta le tre righe in un cron job, spedisca gli archivi altrove, e testi un ripristino almeno una volta — un backup non testato è una convinzione, non un backup.
Aggiornamenti. docker compose pull seguito da docker compose up -d. Faccia prima uno snapshot: n8n esegue le migrazioni del database all'avvio, e le migrazioni non sono progettate per essere annullate. Attraverso una versione major — il salto da 1.x a 2.x, per esempio — legga le release notes prima di fare il pull piuttosto che dopo, e consideri di fissare un tag immagine esplicito invece di :latest così che un riavvio automatico non la aggiorni mai a sua insaputa.
Per impostazione predefinita n8n gira in modalità regolare: lo stesso processo che serve l'editor e riceve i webhook esegue anche i workflow. È semplice ed è corretto finché un workflow lungo non inizia a far attendere gli altri. Il sintomo è inconfondibile — le esecuzioni restano in «running» per minuti, l'editor diventa lento, e un webhook che dovrebbe rispondere in 200 ms risponde in otto secondi.
La modalità queue divide il lavoro. L'istanza principale mantiene l'editor, i trigger e gli endpoint webhook; inserisce gli ID di esecuzione in Redis; processi worker separati li prelevano, caricano il workflow da PostgreSQL, lo eseguono e riportano l'esito tramite Redis. Da questa architettura derivano tre regole, e tutte e tre colpiscono chi le salta: ogni istanza deve condividere lo stesso database PostgreSQL, ogni istanza deve avere la stessa N8N_ENCRYPTION_KEY, e SQLite non è supportato affatto.
Le aggiunte al file Compose sono un servizio Redis e un servizio worker, che è la stessa immagine n8n eseguita con il comando worker:
redis:
image: redis:7-alpine
restart: unless-stopped
command: ["redis-server", "--save", "60", "1", "--appendonly", "no"]
volumes:
- redis_data:/data
n8n-worker:
image: docker.n8n.io/n8nio/n8n:latest
restart: unless-stopped
command: worker --concurrency=5
depends_on:
- redis
- postgres
environment:
# the SAME encryption key and the SAME database as the main instance
- EXECUTIONS_MODE=queue
- QUEUE_BULL_REDIS_HOST=redis
- N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
- DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
- DB_POSTGRESDB_USER=${POSTGRES_USER}
- DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
- GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
- TZ=${GENERIC_TIMEZONE}
Aggiunga EXECUTIONS_MODE=queue e QUEUE_BULL_REDIS_HOST=redis anche al servizio n8n principale — entrambi i lati devono concordare sulla modalità. Due opzioni vale la pena impostarle fin dal primo giorno: OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true, in modo che premere «Test workflow» nell'editor non blocchi il processo principale, e N8N_GRACEFUL_SHUTDOWN_TIMEOUT, che di default è 30 secondi e decide per quanto tempo un worker può terminare il proprio lavoro in corso durante un redeploy. Se i suoi workflow durano regolarmente più di mezzo minuto, lo alzi, altrimenti ogni deployment interrompe il lavoro in corso.
Non inizi da qui. La modalità queue aggiunge due parti mobili e una classe di guasti che la modalità regolare semplicemente non ha. Resti in modalità regolare finché non vede la coda crescere o un workflow bloccarne un altro, quindi aggiunga un singolo worker sulla stessa macchina prima di aggiungere una seconda macchina. Questa progressione — Sentinel in modalità regolare, Garrison con un worker, Ravelin con tre — copre tutto tranne un deployment davvero di grandi dimensioni.
La maggior parte delle guide al self-hosting tratta la scelta dell'host come una questione di prestazioni. Per un motore di automazione non lo è. Un'istanza n8n contiene due cose che quasi nient'altro tra ciò che si ospita da sé tiene insieme: un'unica tabella cifrata contenente le chiavi API, i token OAuth e le password di posta di ogni servizio che automatizza, e — proprio accanto — un grafo che descrive esattamente come funziona la sua organizzazione. Quale CRM. Quale flusso bancario. Quale fornitore. Quali clienti ricevono quale email, su quale trigger. Legga l'elenco dei workflow di un'azienda e avrà letto l'azienda.
Livello uno — chi l'host pensa che lei sia. Il livello applicativo qui è genuinamente buono: le credenziali sono cifrate a riposo, l'editor è dietro TLS e 2FA. Il livello che perde è quello sottostante. Un piano hosted conosce la sua entità legale, il suo indirizzo di fatturazione e la sua carta. Un hyperscaler conosce le stesse cose e le conserva per anni. Non è un'esposizione ipotetica; è la chiave di join tra «esiste un caveau cifrato» e «appartiene a questa azienda nominata». Una registrazione senza email e senza documento d'identità, saldata in Monero, rimuove la chiave di join, non il caveau.
Livello due — il disco. La cifratura a riposo aiuta solo contro chi non possiede anche la chiave, e in un'installazione predefinita la chiave si trova sullo stesso filesystem del database. Mantenga il .env in modalità 600, conservi una copia della chiave fuori dalla macchina, e preferisca un provider la cui giurisdizione non renda un data center un luogo comodo per notificare un atto giudiziario — che è l'intero argomento della guida sulle giurisdizioni nordiche.
Livello tre — l'IP di uscita. Ogni nodo HTTP Request parte dall'indirizzo del VPS, e quell'indirizzo porta con sé una reputazione. Le fasce IP degli hyperscaler sono le più aggressivamente rate-limited e bloccate da CAPTCHA su internet, perché è lì che vivono gli scraper; un workflow che fa scraping o polling inizierà a fallire su un IP AWS o DigitalOcean molto prima di quanto fallisca su una fascia nordica più tranquilla. n8n rispetta anche le variabili standard HTTP_PROXY, HTTPS_PROXY, ALL_PROXY e NO_PROXY, così la manciata di workflow che necessita di un'uscita diversa può essere instradata tramite un proxy SOCKS locale o Tor mentre tutto il resto passa diretto.
Un'altra porta d'accesso, nuova nella linea 2.x: n8n può esporre un server MCP a livello di istanza così che un agente AI possa richiamare i suoi workflow come tool. È genuinamente utile ed è anche un endpoint pubblico verso il suo livello di automazione, che merita lo stesso trattamento di ogni altro — veda la guida al server MCP remoto per il ragionamento su TLS, OAuth ed esposizione.
Il volume dati è stato ricreato e n8n ha generato una nuova chiave di cifratura. Niente recupera le vecchie credenziali. Imposti sempre N8N_ENCRYPTION_KEY esplicitamente e ne conservi una copia fuori dal server.
WEBHOOK_URL non è impostata, quindi n8n costruisce gli URL a partire da N8N_HOST. Imposti WEBHOOK_URL e N8N_EDITOR_BASE_URL all'indirizzo HTTPS pubblico e riavvii il container.
Sta raggiungendo l'editor su http semplice e il cookie di sessione sicuro viene rifiutato. Completi la configurazione TLS invece di impostare N8N_SECURE_COOKIE su false su un'istanza pubblica.
Quattordici giorni di dati completi di esecuzione da un trigger al minuto. Stringa EXECUTIONS_DATA_MAX_AGE e PRUNE_MAX_COUNT, e smetta di salvare le esecuzioni riuscite.
Il tag :latest più migrazioni del database che non si possono annullare. Fissi un tag esplicito, faccia uno snapshot prima di ogni pull, e legga le release notes tra le versioni major.
GENERIC_TIMEZONE ha come valore predefinito America/New_York, che raramente è ciò che si desidera. Imposti GENERIC_TIMEZONE e TZ sullo stesso fuso reale e riavvii.
Dieci domande che emergono prima, durante e dopo aver spostato un'istanza n8n sul proprio server.
Per le sue automazioni, sì. n8n viene distribuito sotto la Sustainable Use License: può usarlo, copiarlo, modificarlo e distribuirlo per finalità aziendali interne e per uso personale o non commerciale, gratuitamente. Ciò che la licenza vieta è far pagare altri per n8n o per un suo derivato — in pratica, rivendere «n8n hosting» come prodotto. I file con .ee. nel nome del file o .ee nel percorso della directory sono esclusi da quella licenza e richiedono una n8n Enterprise License a pagamento. Quindi: automatizzare la propria azienda su un VPS che si affitta rientra pienamente nella concessione gratuita; costruirci sopra un'attività di hosting n8n no.
La documentazione Docker Compose ufficiale di n8n indica un minimo di 2 vCPU e 4 GB di RAM. Corrisponde esattamente al tier Sentinel ($3.90/mese — 2 vCPU, 4 GB, 120 GB NVMe), che esegue comodamente n8n più PostgreSQL più Caddy per un'istanza personale o di piccolo team. Passi al Garrison (4 vCPU, 8 GB, $7.90/mese) quando aggiunge worker in modalità queue o esegue workflow che tengono in memoria payload di grandi dimensioni, e al Ravelin (8 vCPU, 16 GB, $16.90/mese) per un'istanza di team che effettua migliaia di esecuzioni al giorno con dati binari — PDF, immagini, audio.
SQLite è l'impostazione predefinita ed è genuinamente adeguato per una singola persona con una manciata di workflow. Passi a PostgreSQL quando ha esecuzioni concorrenti, quando la cronologia delle esecuzioni supera qualche centinaio di migliaia di righe, o quando prevede di scalare — e noti che la modalità queue non supporta affatto SQLite. Migrare in seguito significa esportare workflow e credenziali e reimportarli in un'istanza nuova, un pomeriggio che non le piacerà. Se c'è anche solo una possibilità di crescita, parta con PostgreSQL; il file Compose di questa guida lo fa già.
Ogni credenziale nel database diventa permanentemente illeggibile. n8n cifra le credenziali memorizzate — token OAuth, chiavi API, password SMTP — con quella chiave, e non esiste alcun meccanismo di recupero né alcun ticket di supporto che le riporti indietro. Deve reinserire ogni credenziale a mano. Questo è il modo più comune in assoluto in cui un'istanza n8n self-hosted viene distrutta: qualcuno ricrea il volume Docker, n8n genera una nuova chiave, e ogni workflow inizia a fallire tutto insieme con un errore di decifratura. Imposti la chiave esplicitamente nel proprio .env prima del primo avvio, e ne conservi una copia da qualche parte che non sia il server.
Quattro cause, in ordine di frequenza. (1) WEBHOOK_URL non è impostata, quindi l'editor le fornisce un URL http://localhost:5678/webhook/… che nessun servizio esterno può raggiungere — la imposti al proprio URL HTTPS pubblico. (2) Il workflow non è attivato; l'URL di test resta in ascolto solo mentre l'editor è aperto, l'URL di produzione esiste solo una volta che il workflow è attivo. (3) DNS o firewall: il record non si risolve, oppure le porte 80/443 sono chiuse. (4) Si trova dietro un ulteriore livello di proxy e non ha impostato N8N_PROXY_HOPS, quindi n8n legge l'IP client sbagliato. Faccia un test con un semplice curl da una macchina che non è il server.
Sì, ed è il pattern normale — un Caddy davanti, una rete Compose, n8n su un hostname e Vaultwarden, Nextcloud o SearXNG su altri. Due avvertenze. Memoria: n8n più PostgreSQL sta a riposo intorno ai 700 MB e un workflow pesante può superarlo ampiamente, quindi lasci margine. Raggio d'esplosione: il database di n8n è la cosa più densa di credenziali sulla macchina, quindi qualsiasi altra cosa che condivide quell'host eredita il suo profilo di rischio. Su un tier da $3.90/mese è ragionevole dare al motore di automazione un server tutto suo.
Per impostazione predefinita, tre endpoint. Telemetria anonima del prodotto (N8N_DIAGNOSTICS_ENABLED, predefinito true), il controllo di nuove versioni e aggiornamenti di sicurezza verso api.n8n.io (N8N_VERSION_NOTIFICATIONS_ENABLED, predefinito true), e il browser dei template dei workflow, che effettua richieste verso https://api.n8n.io (N8N_TEMPLATES_ENABLED, predefinito true). Nessuno di essi invia le sue credenziali o i dati dei workflow, ma tutti e tre annunciano che esiste un'istanza al suo IP. Imposti tutti e tre a false se vuole che la macchina sia silenziosa — perde la galleria dei template e il banner degli aggiornamenti, quindi tenga d'occhio le release da solo.
n8n Cloud Starter costa €20/mese fatturati annualmente per 2 500 esecuzioni; Pro è €50/mese per 10 000. Un VPS Sentinel è $3.90/mese e il numero di esecuzioni è limitato solo da CPU e RAM, il che per i tipici workflow webhook-e-API significa decine di migliaia. Il pareggio economico è immediato; il costo reale è operativo. Il self-hosting significa che possiede lei gli aggiornamenti, i backup, il rinnovo TLS e l'incidente da disco pieno alle tre di notte. La regola onesta: se non avrebbe aggiornato l'istanza da solo entro un mese da una release di sicurezza, paghi per Cloud. Se un docker compose pull mensile fa già parte della sua vita, faccia self-hosting.
Per via di cosa contiene un'istanza n8n. La tabella delle credenziali è un unico archivio cifrato delle chiavi API, dei token OAuth e delle password di posta per ogni servizio che automatizza, e il grafo dei workflow accanto ad essa è una mappa leggibile di come opera davvero la sua attività — quale CRM, quale flusso bancario, quale fornitore, quali clienti. Un sito statico non fa trapelare nulla di tutto ciò. Il livello applicativo lo protegge bene; è il livello dei metadati a farlo trapelare. Se la registrazione della macchina comporta la scansione di un passaporto e una carta, ha cifrato il caveau e scritto il proprio nome sulla porta. Un host no-KYC pagato in Monero mantiene i due livelli allineati.
Sì per la forma comune — un nodo AI Agent che chiama un'API di modello remota. Quel carico di lavoro dipende dall'I/O, attende il provider, e un Sentinel lo gestisce. Ciò che non ci sta è eseguire il modello stesso: un modello locale da 7B vuole circa 8 GB di RAM e una vera velocità di inferenza vuole una GPU, che questi tier non hanno. Punti n8n verso un endpoint remoto compatibile OpenAI e mantenga il VPS leggero. La guida gemella sull'esecuzione di un agente AI 24/7 copre il lato runtime — policy di riavvio, segreti, tetti di spesa e la trappola del crash-loop.
Sentinel (2 vCPU, 4 GB, 120 GB NVMe, $3.90/mese) soddisfa il minimo richiesto da n8n con margine per PostgreSQL e Caddy sulla stessa macchina. Nessuna email alla registrazione, nessun documento d'identità, esecuzioni illimitate.
Ultima revisione · 2026-08-24 · Fonti · Documentazione di hosting di n8n, n8n LICENSE.md (Sustainable Use License), pagina dei prezzi di n8n.io, documentazione upstream di Docker e Caddy · Cadenza · annuale
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Deploy your own MCP server on a no-KYC VPS — TLS, streamable HTTP, OAuth.
Host an MCP server with no ID — the privacy stack, crypto-paid.
Sposta l'agente fuori dal tuo laptop — dimensionamento, systemd, segreti, tetti di spesa.
LLM in locale con Ollama su CPU, senza GPU — cosa entra in 4, 8, 16 o 32 GB.