Găzduiește n8n pe un VPS cu Docker

n8n e genul de unealtă pe care începi s-o folosești puțin și prin care apoi treci, pe nesimțite, jumătate din operațiuni. În punctul ăla, „rulează pe locul cuiva în cloud, contorizat per execuție, cu cheile mele API pe serverele lor” începe să nu mai sune așa de bine. Găzduirea proprie le rezolvă pe toate trei — cost fix, fără plafon de execuții, iar cheile rămân pe o mașină pe care o deții. Cu Docker, e o treabă de cincisprezece minute.

De cât server are nevoie de fapt

Întâi cifrele cinstite, ca să nu cumperi prea mult sau prea puțin:

• ~2 GB RAM e punctul ideal — n8n plus baza lui de date Postgres plus workflow-uri obișnuite stau comod aici.
• 1 GB merge dacă workflow-urile sunt ușoare, dar vei observa la rulările mai mari.
• 4 GB, dacă faci execuții paralele grele sau treci payloaduri mari.

n8n nu e flămând de CPU în repaus; are vârfuri în timpul rulărilor. O mașină cu 2 nuclee ajunge pentru majoritatea configurărilor. (Mai multe despre potrivirea specificațiilor cu sarcina, în ghidul de dimensionare.)

Configurarea Docker

Pe o mașină Ubuntu/Debian proaspătă, instalează Docker:

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

Fă un folder și un docker-compose.yml — n8n cu un volum persistent și 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

Două lucruri de remarcat: volumele (n8n-data, db-data) sunt cele care îți țin workflow-urile în viață la reporniri și actualizări — nu sări peste ele. Iar n8n e legat de 127.0.0.1, nu de 0.0.0.0 — nu e expus direct pe internet. E intenționat; pasul următor se ocupă de acces în siguranță.

Acces: HTTPS sau tunel

• URL public (necesar pentru integrările OAuth și webhookuri): îndreaptă un subdomeniu spre server și rulează un reverse proxy (Caddy cere cel mai mic efort — HTTPS automat) în fața 127.0.0.1:5678. Aici se potrivește un plan cu IP dedicat, pentru că îți controlezi porturile și DNS-ul.
• Doar pentru tine, fără domeniu: sari peste proxy și ajungi la el printr-un tunel SSH — ssh -L 5678:127.0.0.1:5678 user@server, apoi deschizi localhost:5678. Merge bine pe un VPS NAT.

Închide-l bine și ține-l pornit

n8n îți ține cheile API și datele de acces, așa că mașina trebuie să fie strânsă: parcurge lista de securitate (chei SSH, firewall, fără autentificare cu parolă) înainte să pui date de acces reale. restart: always din fișierul compose înseamnă deja că Docker readuce n8n după o cădere sau o repornire — disponibilitatea e rezolvată.

Merită?

Fii cinstit cu tine despre volum. Dacă rulezi automatizări tot timpul, găzduirea proprie câștigă la cost (fix vs per execuție) și elimină orice limită de workflow-uri/rulări. Dacă declanșezi câteva fluxuri pe lună, un loc găzduit e mai puțină bătaie de cap. Dar argumentul controlului rămâne oricum: workflow-urile tale, datele tale, cheile tale — pe serverul tău, nu închiriate. Pentru cei mai mulți care au luat n8n în serios, ăsta e factorul decisiv.

O mașină de 2 GB, un fișier compose, un domeniu (sau un tunel) și îți rulezi propriul centru de automatizare — plătibil cu cripto, fără KYC, online în câteva minute.

Configurare gata făcută: vezi VPS pentru n8n — planul recomandat și un deploy cripto de un minut.