Quanta RAM serve a n8n self-hosted?

Circa 2 GB è il comodo punto ideale per n8n più il suo database Postgres e i workflow normali. Gira in 1 GB se i workflow sono leggeri, ma lo sentirai durante le esecuzioni più grandi. Esecuzioni parallele pesanti o payload grandi — sali a 4 GB.

Mi serve Docker per fare self-hosting di n8n?

È di gran lunga il modo più facile — un file compose ti dà n8n, un database e storage persistente, e gli aggiornamenti sono un singolo pull. Puoi installare tramite npm invece, ma Docker ti risparmia i grattacapi di dipendenze e aggiornamenti.

Fare self-hosting di n8n è più economico di n8n cloud?

Se esegui un flusso costante di automazioni, sì — un VPS mensile fisso batte il prezzo per esecuzione, e non c'è limite di workflow o esecuzioni. Per una manciata di run al mese, un posto ospitato può essere più semplice. L'altro motivo per cui la gente fa self-hosting è il controllo: i tuoi dati e le tue chiavi API non lasciano mai il tuo server.

Mi serve un dominio per n8n?

Per i nodi basati su OAuth (Google, ecc.) e un HTTPS pulito, sì — punta un dominio al server e metti n8n dietro un reverse proxy con un certificato. Per uso puramente interno puoi raggiungerlo tramite un tunnel SSH senza dominio.

n8n può girare su un VPS NAT o mi serve un IP dedicato?

L'uso interno/tunnel-SSH funziona su una macchina NAT. Se vuoi un URL pubblico con il tuo dominio e HTTPS (necessario per alcune callback OAuth e webhook), un piano con IP dedicato è più adatto dato che controlli tutte le porte.

Fai self-hosting di n8n su un VPS con Docker

n8n è il tipo di strumento che inizi a usare leggermente e poi instradi silenziosamente metà delle tue operazioni attraverso. A quel punto "gira su un posto cloud di qualcuno, misurato per esecuzione, con le mie chiavi API che vivono sui loro server" inizia a sembrare meno bello. Il self-hosting sistema tutti e tre — costo fisso, nessun limite di esecuzioni, e le tue chiavi restano su una macchina che possiedi. Con Docker è un lavoro di quindici minuti.

Quanto server serve davvero

Prima i numeri onesti, così non compri troppo o troppo poco:

~2 GB di RAM è il punto ideale — n8n più il suo database Postgres più i workflow normali stanno comodamente qui.
1 GB funziona se i tuoi workflow sono leggeri, ma lo noterai sulle esecuzioni più grandi.
4 GB se fai esecuzioni parallele pesanti o spingi payload grandi.

n8n non è affamato di CPU a riposo; ha picchi durante le esecuzioni. Una macchina a 2 core va bene per la maggior parte dei setup. (Più sull'abbinare le specifiche al carico nella guida al dimensionamento.)

Il setup Docker

Su una macchina Ubuntu/Debian nuova, installa Docker:

curl -fsSL https://get.docker.com | sudo sh

Crea una cartella e un docker-compose.yml — n8n con un volume persistente e Postgres:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.yourdomain.com
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.yourdomain.com/
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=db
      - DB_POSTGRESDB_PASSWORD=change-me
    volumes:
      - ./n8n-data:/home/node/.n8n
    depends_on: [db]
  db:
    image: postgres:16
    restart: always
    environment:
      - POSTGRES_PASSWORD=change-me
      - POSTGRES_DB=n8n
    volumes:
      - ./db-data:/var/lib/postgresql/data

sudo docker compose up -d

Due cose che vale la pena sottolineare: i volumi (n8n-data, db-data) sono ciò che tiene vivi i tuoi workflow tra riavvii e aggiornamenti — non saltarli. E n8n è vincolato a 127.0.0.1, non a 0.0.0.0 — non è esposto direttamente a internet. È deliberato; il passo successivo gestisce l'accesso in sicurezza.

Accesso: HTTPS o un tunnel

URL pubblico (necessario per nodi OAuth e webhook): punta un sottodominio al server ed esegui un reverse proxy (Caddy è il meno faticoso — HTTPS automatico) davanti a 127.0.0.1:5678. È qui che si adatta un piano con IP dedicato, dato che controlli porte e DNS.
Solo per te, senza dominio: salta il proxy e raggiungilo tramite un tunnel SSH — ssh -L 5678:127.0.0.1:5678 user@server, poi apri localhost:5678. Funziona bene su un VPS NAT.

Blindalo e tienilo attivo

n8n contiene le tue chiavi API e credenziali, quindi la macchina deve essere blindata: fai la checklist di sicurezza (chiavi SSH, firewall, niente login con password) prima di metterci credenziali vere. restart: always nel file compose significa già che Docker riporta n8n dopo un crash o un riavvio — quello è il tuo uptime gestito.

Ne vale la pena?

Sii onesto con te stesso sul volume. Se esegui automazioni costantemente, il self-hosting vince sul costo (fisso vs per esecuzione) e rimuove ogni limite di workflow/run. Se attivi qualche flusso al mese, un posto ospitato è meno seccatura. Ma l'argomento del controllo regge comunque: i tuoi workflow, i tuoi dati, le tue chiavi — sul tuo server, non affittati. Per la maggior parte delle persone che sono diventate serie con n8n, è il fattore decisivo.

Una macchina da 2 GB, un file compose, un dominio (o un tunnel), e stai facendo girare il tuo hub di automazione — pagabile in crypto senza KYC, live in pochi minuti.

Configurazione pronta: vedi VPS per n8n — il piano consigliato e un deploy in crypto di un minuto.