Jak self-hostować n8n (przewodnik 2026)

Self-hosting n8n daje pełną platformę automatyzacji workflow bez limitów wykonań i pełną własność danych. Ten przewodnik uczciwie przechodzi przez prawdziwą konfigurację Docker, Docker Compose i PostgreSQL, a potem pokazuje 30-sekundowy skrót, jeśli wolisz w ogóle pominąć administrację serwerem.

Co oznacza „self-hosting n8n”?

n8n to narzędzie do automatyzacji workflow o dostępnym kodzie źródłowym. W przeciwieństwie do n8n Cloud, czyli hostowanego SaaS prowadzonego przez zespół n8n, self-hosting oznacza, że ty uruchamiasz aplikację n8n na infrastrukturze, którą kontrolujesz. Samo oprogramowanie jest darmowe na licencji fair-code, ale moc obliczeniowa, baza, pamięć i transfer potrzebne, by utrzymać je działające 24/7, nie są darmowe. Self-hosting to właściwy wybór, gdy chcesz brak limitów wykonań, pełną kontrolę nad danymi i dostępem, nieograniczoną liczbę workflow oraz możliwość używania węzłów community i własnego kodu bez bramki w postaci planu SaaS.

Wymagania systemowe n8n

n8n lekko startuje, ale skaluje się wraz z tym, jak ciężkie są twoje workflow. Realistyczne minimum:

• CPU: 1 vCPU wystarcza do lekkiego użytku; 2+ vCPU przy wielu równoległych wykonaniach.
• RAM: 1–2GB dla n8n. Workflow przetwarzające duże ładunki (pliki, obrazy, duży JSON) potrzebują więcej.
• Baza danych: PostgreSQL jest mocno zalecany w produkcji. Domyślne SQLite działa do testów, ale słabo radzi sobie ze współbieżnością, a trudniej z niego bezpiecznie zrobić backup.
• Pamięć: Kilka GB wystarcza na start; historia wykonań i dane binarne rosną z czasem.
• Sieć: Publiczny endpoint HTTPS (port 443), żeby przychodzące webhooki i callbacki OAuth działały.

Szczegółowe omówienie dopasowane do rozmiarów planów znajdziesz w naszym Przewodnik po wymaganiach serwera n8n.

Opcja 1: wdróż n8n z Dockerem

Najszybszy sposób uruchomienia n8n na własnej maszynie lub VPS to oficjalny obraz Docker. Świetnie nadaje się do lokalnego testu, ale pamiętaj, że używa SQLite i nie ma TLS, więc nie nadaje się do produkcji:

docker volume create n8n_data

docker run -it --rm \
  --name n8n \
  -p 5678:5678 \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

Otwórz http://localhost:5678, utwórz konto właściciela i masz działające n8n. Do czegokolwiek poważnego przejdź na Docker Compose z PostgreSQL.

Opcja 2: Docker Compose z PostgreSQL

Produkcyjna konfiguracja łączy n8n z dedykowaną bazą PostgreSQL, kluczem szyfrującym oraz poprawnym hostem i adresami webhooków. Zapisz to jako docker-compose.yml:

services:
  postgres:
    image: postgres:16
    restart: always
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: change-me
      POSTGRES_DB: n8n
    volumes:
      - pgdata:/var/lib/postgresql/data

  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "5678:5678"
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: change-me
      N8N_HOST: n8n.example.com
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://n8n.example.com/
      N8N_ENCRYPTION_KEY: a-long-random-string
    depends_on:
      - postgres
    volumes:
      - n8ndata:/home/node/.n8n

volumes:
  pgdata:
  n8ndata:

Następnie uruchom docker compose up -d. Kilka rzeczy ma znaczenie: ustaw mocny N8N_ENCRYPTION_KEY (szyfruje zapisane dane logowania, a jego utrata oznacza ponowne wpisanie każdego z nich), wskaż WEBHOOK_URL na swoją prawdziwą publiczną domenę HTTPS i nigdy nie wystawiaj portu 5678 bezpośrednio do internetu bez reverse proxy przed nim.

Czego pomijają poradniki o self-hostingu

Uruchomienie n8n to łatwe 20%. Utrzymanie go w bezpieczny sposób to pozostałe 80% i tu gołe VPS zaczyna gryźć:

• Certyfikaty TLS: Potrzebujesz HTTPS dla webhooków i OAuth. Oznacza to Caddy, Traefik lub Nginx plus Let's Encrypt, a odnowienie certyfikatu nie może się nie udać.
• Webhooki i reverse proxy: Przychodzące webhooki wymagają stabilnego publicznego adresu URL i poprawnych nagłówków proxy, bo inaczej wyzwalacze po cichu przestaną działać.
• Backupy: Twoje workflow, dane logowania i historia wykonań są w PostgreSQL. Potrzebujesz zautomatyzowanych, przetestowanych backupów bazy danych, bo nieprzetestowany backup to nie backup.
• Aktualizacje: n8n wydaje często aktualizacje. Ty odpowiadasz za pobieranie nowych obrazów, czytanie informacji o zmianach łamiących kompatybilność i migrację bazy danych.
• Dostępność: Pojedynczy VPS to pojedynczy punkt awarii. Jeśli host zrestartuje się o 2 w nocy, twoje zaplanowane workflow i webhooki staną, dopóki tego nie zauważysz.

Najczęściej zadawane pytania