Instalacja i hosting n8n

Moduł 1 · Poziom: początkującyCzas czytania: ~25 minDocker · VPS · Cloud

Zanim zbudujesz pierwszy workflow, potrzebujesz działającej instancji n8n. W tym module pokażę Ci wszystkie realne ścieżki - od najszybszego n8n Cloud, przez Dockera na własnym serwerze, po VPS, Raspberry Pi i Cloudflare Tunnel. Skupię się na tym, dlaczego dana opcja ma sens, a nie tylko na klikaniu po kroku.

Wymagania systemowe

n8n jest aplikacją Node.js i nie jest szczególnie wymagający, ale jest istotna różnica między "wystartuje" a "uciągnie produkcję". Poniżej rozdzielamy minimum do nauki od realnego minimum produkcyjnego - bo to dwa różne światy.

Wskaźnik	Wartość
RAM (nauka)	~512 MB - 1 GB
RAM (produkcja)	2 GB+
CPU	1-2 rdzenie
Dysk	kilka GB+

Wartości powyżej to praktyczne wskazówki, a nie sztywne wymaganie z dokumentacji. Sam silnik n8n jest lekki, ale apetyt na RAM rośnie wraz z liczbą równoległych wykonań, rozmiarem przetwarzanych danych (np. duże pliki, obszerne odpowiedzi API) i node'ami AI. Na słabej maszynie ciężki workflow potrafi przeciążyć pamięć i ubić proces - dlatego do produkcji warto mieć zapas.

Node.js? Nie Twój problem

n8n jest napisany w Node.js, ale w obrazie Dockera Node.js jest już w środku - nie instalujesz go, nie pilnujesz wersji i nie kolidujesz z innymi projektami na tej samej maszynie. To był zawsze jeden z argumentów za Dockerem, a od n8n 3.0 przestaje być argumentem, bo alternatywy nie ma.

Wersja Node.js ma znaczenie tylko wtedy, gdy nadal trzymasz starą instalację z npm - ta wymaga Node.js od 20.19 do 24.x (docs). Jeśli właśnie zastanawiasz się, czy zainstalować odpowiedniego Node.js, to sygnał, że idziesz ścieżką, która się kończy - przeskocz od razu do Dockera.

Baza danych: SQLite czy PostgreSQL?

n8n musi gdzieś trzymać Twoje workflow, wykonania i poświadczenia. Domyślnie używa SQLite - pliku w katalogu danych, bez stawiania osobnego serwera bazy. To świetne na start i do nauki. Do poważniejszych wdrożeń docs i społeczność rekomendują PostgreSQL: lepiej radzi sobie z większym obciążeniem, jest wymagany przy skalowaniu (tryb kolejkowy / queue mode) i ułatwia backupy.

Aspekt	SQLite (domyślnie)	PostgreSQL
Konfiguracja	Zero - działa od razu	Trzeba postawić serwer bazy
Dla kogo	Nauka, mała instancja, dom	Produkcja, większy ruch, zespół
Skalowanie (queue mode)	Nieodpowiednie	Wymagane
Backup	Kopia pliku / wolumenu	Standardowe narzędzia Postgresa
Wydajność pod obciążeniem	Ograniczona	Dużo lepsza

n8n Cloud - najszybszy start

Jeśli chcesz zobaczyć n8n w akcji w ciągu kilku minut i nie interesuje Cię administracja serwerem, n8n Cloud jest najprostszą drogą. To hostowana wersja prowadzona przez twórców n8n.

Co dostajesz

Zero instalacji i utrzymania instancji
Aktualizacje jednym kliknięciem do najnowszej wersji
Monitoring dostępności po stronie n8n
Zarządzane uwierzytelnianie OAuth (gotowe callbacki)
HTTPS i publiczny adres bez konfiguracji

Czego się spodziewać

Płatny abonament zamiast własnego serwera
Dane przechowywane u dostawcy (nie u Ciebie)
Mniejsza kontrola nad środowiskiem niż self-host
Usługa niedostępna w niektórych regionach (Rosja, Białoruś)

Docker i Docker Compose krok po kroku

To jest ta jedna droga zapowiedziana na początku modułu. Dostajesz gotowy obraz z odpowiednim Node.js w środku, izolację od reszty systemu oraz powtarzalność: ta sama komenda da ten sam efekt na laptopie, VPS-ie i Raspberry Pi. Od n8n 3.0 jest to również jedyny wspierany sposób self-hostingu, więc ucząc się tego, nie uczysz się niczego tymczasowego.

Dalej pokazuję dwie drogi do tego samego celu. Najszybsza to instalator, który zrobi wszystko za Ciebie. Najprostsza do zrozumienia to ręczna komenda docker run, przy której rozbieram każdy przełącznik na czynniki pierwsze. Jeśli chcesz tylko zobaczyć n8n - weź instalator. Jeśli chcesz wiedzieć, co się dzieje - przeczytaj obie.

Najszybszy start: instalator jednolinijkowy

To miejsce, które w tym module wcześniej zajmowało npx n8n. n8n udostępnia skrypt, który sprawdza Dockera, tworzy katalog n8n, zapisuje konfigurację i podnosi instancję w Docker Compose:

curl -fsSL https://get.n8n.io | sh

Warunek jest jeden: działający Docker z pluginem Compose v2. Na Windowsie potrzebujesz terminala rozumiejącego skrypty powłoki - WSL z włączoną integracją Docker Desktop (Git Bash bywa, że wystarczy, ale n8n nie testuje go end-to-end). Skrypt jest pomyślany pod świeżą instalację, nie pod przerabianie istniejącej (docs).

Najprostszy start (jeden kontener, SQLite)

Najpierw tworzymy wolumen danych - to nazwane miejsce na dysku, w którym Docker trzyma dane n8n niezależnie od kontenera. Dzięki temu możesz skasować i odtworzyć kontener (np. przy aktualizacji), a Twoje workflow, poświadczenia i klucz szyfrowania zostaną.

docker volume create n8n_data

docker run -it --rm \
 --name n8n \
 -p 5678:5678 \
 -e GENERIC_TIMEZONE="Europe/Warsaw" \
 -e TZ="Europe/Warsaw" \
 -e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true \
 -v n8n_data:/home/node/.n8n \
 docker.n8n.io/n8nio/n8n

Po uruchomieniu otwórz http://localhost:5678. Co tu się właściwie dzieje?

-p 5678:5678 - udostępnia port n8n z kontenera na Twoim komputerze. Port to numerowane "drzwi", przez które program jest widoczny w sieci - n8n używa numeru 5678.
-v n8n_data:/home/node/.n8n - montuje wolumen do katalogu danych n8n. To kluczowe dla trwałości: tu lądują baza SQLite, poświadczenia i klucz szyfrowania.
-e GENERIC_TIMEZONE / -e TZ - strefa czasowa (ważna dla node'ów harmonogramu, np. "codziennie o 7:00").
--rm - usuwa kontener po zatrzymaniu (dane i tak przeżyją w wolumenie). Do trwałego działania w tle używa się raczej -d zamiast -it --rm.

Docker Compose - wygodniej i pod produkcję

Pojedyncza długa komenda docker run jest okej do testu, ale w praktyce lepiej opisać całą konfigurację w pliku docker-compose.yml. Zyskujesz czytelność, łatwe aktualizacje i miejsce na dołożenie kolejnych usług (np. PostgreSQL czy reverse proxy). Uruchamiasz wszystko jedną komendą:

docker compose up -d

Oficjalne przewodniki "server setups" w docs n8n pokazują gotowe konfiguracje Compose (np. z Traefikiem jako reverse proxy, automatycznym SSL od Let's Encrypt oraz wolumenami n8n_data i traefik_data). To dobry szablon na pełne wdrożenie z własną domeną - wrócę do tego w sekcji o HTTPS.

Sandbox dla AI Assistant - najlepszy moment jest teraz

W n8n siedzi Assistant: wbudowany asystent, który buduje i poprawia workflow za Ciebie. Żeby cokolwiek zrobił, musi mieć gdzie uruchomić kod, który pisze - a n8n nie pozwala robić tego we własnym kontenerze. Tym "gdzieś" jest sandbox, czyli osobne, odcięte środowisko wykonawcze. Bez niego Assistant się nie włączy. To nie jest opcja do rozważenia, tylko warunek wstępny.

Czym Assistant jest i jak go używać, opisuję w Module 9. Tutaj liczy się jedno zdanie: skoro i tak piszesz plik Compose, dołóż sandbox od razu. Doklejanie go później to grzebanie w działającym stacku, a to kosztuje więcej nerwów niż napisanie o trzy usługi więcej za pierwszym razem.

Jak stawiasz n8n	Co z sandboxem
Instalator jednolinijkowy albo Compose wprost z docs n8n	masz go automatycznie, nic nie robisz
Własny `docker-compose.yml` (ten scenariusz)	dokładasz trzy usługi nakładką, niżej
Produkcja, nie chcesz trzymać sandboxa u siebie	provider `daytona`, czyli sandbox w chmurze

Nakładka zamiast przepisywania Compose

Docker Compose sam wczytuje plik docker-compose.override.yml, jeśli leży obok docker-compose.yml. Sekcje environment i depends_on z obu plików się scalają, więc nie ruszasz pliku, który działa, a wyłączenie sandboxa sprowadza się do zmiany nazwy jednego pliku, nie do cofania edycji.

Zapamiętaj tę technikę niezależnie od sandboxa. Przydaje się za każdym razem, gdy dokładasz coś do stacku, którego nie chcesz przepisywać.

Najpierw trzy sekrety w pliku .env obok Compose. Każdy zabezpiecza inną parę rozmówców: n8n z API sandboxa oraz runner z tym samym API.

cd /sciezka/do/n8n
gen() { openssl rand -base64 32 | tr -d '=+/' | cut -c1-40; }
printf 'SANDBOX_API_KEY=%s\nSANDBOX_RUNNER_REGISTRATION_TOKEN=%s\nSANDBOX_RUNNER_API_KEY=%s\n' \
  "$(gen)" "$(gen)" "$(gen)" > .env
chmod 600 .env

Potem sama nakładka. To jeden plik do skopiowania i nie musisz go czytać linijka po linijce, ale trzy rzeczy warto w nim zobaczyć, bo właśnie na nich wykłada się większość osób:

Nigdzie nie ma ports:. Usługi sandboxa rozmawiają z n8n po nazwach wewnątrz sieci Compose (http://sandbox-api:8080). Publikowanie portu na hoście niczego nie naprawia, a otwiera drogę do kontenera z uprawnieniami roota.
Nazwy usług są wpisane w certyfikaty. Usługa sandbox-certs wystawia je na sandbox-api i sandbox-runner-1, więc przemianowanie usługi rozwala szyfrowaną komunikację między nimi. To najczęstszy powód "na filmiku działało, u mnie nie".
Wersja obrazu n8n jest przypięta. Jeśli Twój Compose używa :latest, to docker compose up -d po dołożeniu nakładki byłoby przy okazji aktualizacją n8n. Wpisz tag, który faktycznie u Ciebie chodzi, i zrób te dwie rzeczy osobno.

Pełna nakładka docker-compose.override.yml do skopiowania

volumes:
  sandbox-tls:

services:
  # Wystawia certyfikaty dla pozostałych dwóch usług. Uruchamia się raz i kończy.
  sandbox-certs:
    image: ghcr.io/n8n-io/n8n-sandbox-service-api:1.2.0
    user: '0:0'
    entrypoint: ['sh', '-c']
    command:
      - >
        bootstrap-mtls.sh --out-dir /tls --api-san sandbox-api
        --control-san-prefix sandbox-runner --world-readable &&
        chown -R sandbox-api:sandbox-api /tls/api && chmod -R a+rX /tls
    environment:
      NUM_RUNNERS: '1'
    volumes:
      - sandbox-tls:/tls

  # Punkt, z którym rozmawia n8n.
  sandbox-api:
    image: ghcr.io/n8n-io/n8n-sandbox-service-api:1.2.0
    restart: unless-stopped
    depends_on:
      sandbox-certs:
        condition: service_completed_successfully
    environment:
      SANDBOX_API_KEYS: ${SANDBOX_API_KEY:?brak SANDBOX_API_KEY w .env}
      SANDBOX_API_RUNNER_REGISTRATION_TOKEN: ${SANDBOX_RUNNER_REGISTRATION_TOKEN:?brak tokenu}
      SANDBOX_API_RUNNER_API_KEY: ${SANDBOX_RUNNER_API_KEY:?brak klucza runnera}
      SANDBOX_API_GRPC_TLS_CERT_FILE: /tls/api/grpc-server.crt
      SANDBOX_API_GRPC_TLS_KEY_FILE: /tls/api/grpc-server.key
      SANDBOX_API_GRPC_TLS_CLIENT_CA_FILE: /tls/api/ca.crt
      SANDBOX_API_RUNNER_CONTROL_GRPC_TLS_CA_FILE: /tls/api/ca.crt
      SANDBOX_API_RUNNER_CONTROL_GRPC_TLS_CERT_FILE: /tls/api/control-grpc-api-client.crt
      SANDBOX_API_RUNNER_CONTROL_GRPC_TLS_KEY_FILE: /tls/api/control-grpc-api-client.key
      SANDBOX_API_RUNNER_CONTROL_GRPC_TLS_SERVER_NAME: sandbox-runner-1
    volumes:
      - sandbox-tls:/tls:ro
    healthcheck:
      test: ['CMD', 'wget', '-qO-', 'http://localhost:8080/healthz']
      interval: 5s
      timeout: 3s
      retries: 5
      start_period: 10s

  # Tu naprawdę uruchamia się kod Assistanta. Docker wewnątrz Dockera.
  sandbox-runner-1:
    image: ghcr.io/n8n-io/n8n-sandbox-service-runner-dind:1.2.0
    privileged: true
    restart: unless-stopped
    depends_on:
      sandbox-api:
        condition: service_healthy
    environment:
      SANDBOX_RUNNER_REGISTRATION_TOKEN: ${SANDBOX_RUNNER_REGISTRATION_TOKEN:?brak tokenu}
      SANDBOX_RUNNER_API_KEYS: ${SANDBOX_RUNNER_API_KEY:?brak klucza runnera}
      SANDBOX_RUNNER_API_GRPC_ADDR: sandbox-api:9090
      SANDBOX_RUNNER_HTTP_BASE_URL: http://sandbox-runner-1:8080
      SANDBOX_RUNNER_CONTROL_GRPC_LISTEN_ADDR: ':9091'
      SANDBOX_RUNNER_CONTROL_GRPC_ADVERTISE_ADDR: sandbox-runner-1:9091
      SANDBOX_RUNNER_ID: runner-1
      SANDBOX_RUNNER_DOCKER_SANDBOX_IMAGE: ghcr.io/n8n-io/n8n-sandbox-service-sandbox:latest
      SANDBOX_RUNNER_REGISTRATION_GRPC_CA_FILE: /tls/runner/ca.crt
      SANDBOX_RUNNER_REGISTRATION_GRPC_CERT_FILE: /tls/runner/grpc-client.crt
      SANDBOX_RUNNER_REGISTRATION_GRPC_KEY_FILE: /tls/runner/grpc-client.key
      SANDBOX_RUNNER_REGISTRATION_GRPC_SERVER_NAME: sandbox-api
      SANDBOX_RUNNER_CONTROL_GRPC_TLS_CERT_FILE: /tls/runner/control-grpc-server.crt
      SANDBOX_RUNNER_CONTROL_GRPC_TLS_KEY_FILE: /tls/runner/control-grpc-server.key
      SANDBOX_RUNNER_CONTROL_GRPC_TLS_CLIENT_CA_FILE: /tls/runner/ca.crt
    volumes:
      - sandbox-tls:/tls:ro

  # Twoja istniejąca usługa n8n - te wpisy dokleją się do tego, co już masz.
  n8n:
    image: n8nio/n8n:2.35.7 # wpisz wersję, która u Ciebie chodzi
    environment:
      N8N_ENABLED_MODULES: instance-ai
      N8N_INSTANCE_AI_SANDBOX_ENABLED: 'true'
      N8N_INSTANCE_AI_SANDBOX_PROVIDER: n8n-sandbox
      N8N_INSTANCE_AI_SANDBOX_IMAGE: ghcr.io/n8n-io/n8n-sandbox-service-sandbox:latest
      N8N_SANDBOX_SERVICE_URL: http://sandbox-api:8080
      N8N_INSTANCE_AI_SANDBOX_API_URL: http://sandbox-api:8080
      N8N_SANDBOX_SERVICE_API_KEY: ${SANDBOX_API_KEY:?brak SANDBOX_API_KEY w .env}
    depends_on:
      sandbox-api:
        condition: service_healthy

Na działającej instancji nie włączaj nakładki od razu. Wgraj ją najpierw pod nazwą docker-compose.override.yml.new, czyli nieaktywną, i zwaliduj bez dotykania stacku. Strażniki ${ZMIENNA:?komunikat} zgłoszą brakujący sekret po nazwie, zamiast pozwolić usłudze wstać z pustym kluczem:

docker compose -f docker-compose.yml -f docker-compose.override.yml.new config -q

Dopiero gdy komenda przejdzie bez słowa, zmień nazwę pliku na docelową.

Start i jedno sprawdzenie, które mówi najwięcej:

docker compose up -d
docker compose exec n8n wget -qO- http://sandbox-api:8080/healthz
# -> {"status":"ok"}

Kolejność wymuszają zależności: sandbox-certs kończy pracę, dopiero potem wstaje sandbox-api, a runner i n8n czekają, aż zgłosi się jako zdrowy. Odpowiedź {"status":"ok"} uzyskana z wnętrza kontenera n8n oznacza, że n8n widzi sandbox i infrastruktura jest gotowa. Reszta, czyli włączenie Assistanta i wybór modelu, dzieje się już w interfejsie - opisuję to w Module 9.

Uwaga na poradniki z npm

Sieć jest pełna artykułów, filmów i odpowiedzi czatów, w których n8n instaluje się komendą npm install n8n -g albo uruchamia przez npx n8n. Nie są złośliwe - są po prostu starsze niż decyzja n8n.

n8n zapowiedziało, że od wersji 3.0 self-hosting wymaga wdrożenia opartego o Dockera, a instalacje uruchamiane przez npm i npx n8n przestaną być wspierane. Wersja 3.0 planowana jest na październik 2026, a dokumentacja instalacji z npm nosi już dziś adnotację "npm-based installs are deprecated from n8n 3.0".

Co z tym zrobić, zależnie od tego, gdzie jesteś:

Czytasz właśnie taki poradnik - zamknij go i wróć do Dockera. Zaoszczędzisz sobie przeprowadzki.
Masz już taką instancję - dziś działa i nikt Ci jej nie wyłączy w nocy. Problem pojawi się przy pierwszej aktualizacji do 3.x, więc przenieś ją wcześniej - instrukcja jest zaraz niżej.
Chcesz tylko szybko obejrzeć n8n - zamiast npx n8n użyj instalatora jednolinijkowego.

Źródła: v3.0 Breaking changes · Install with npm

Migracja z npm na Dockera

Ta sekcja jest dla Ciebie, jeśli masz działającą instalację zrobioną kiedyś przez npm install n8n -g. Reszta może ją spokojnie pominąć.

Przypomnienie, czym te narzędzia są: npm to menedżer pakietów Node.js (pobiera i instaluje gotowe programy), a npx uruchamia taki program bez instalowania go na stałe.

Dlaczego to nie jest tylko kosmetyka

Instalacja z npm wiąże n8n z Node.js na Twoim hoście: to Ty pilnujesz wersji Node'a, kompilacji zależności natywnych i tego, żeby aktualizacja systemu niczego nie wywróciła. Obraz Dockera zdejmuje z Ciebie całą tę warstwę. Ubocznie znika też najczęstsza przyczyna zgłoszeń "u mnie nie działa" - różnice między maszynami.

Gdzie leżą Twoje dane

To jest cała tajemnica bezbolesnej przeprowadzki: n8n z npm i n8n z Dockera trzymają dane w tym samym miejscu, tylko widzianym z innej strony.

	npm	Docker
Katalog danych	`~/.n8n` na hoście	`/home/node/.n8n` w kontenerze
Co w nim jest	baza SQLite, plik `config` z kluczem szyfrowania, dane binarne	to samo
Gdzie fizycznie	dysk hosta	wolumen `n8n_data`

Migracja sprowadza się więc do przeniesienia zawartości ~/.n8n do wolumenu Dockera.

Przeprowadzka krok po kroku

Zatrzymaj n8n. Nie kopiuj bazy SQLite w trakcie pracy instancji - ryzykujesz niespójny plik.
Zrób kopię ~/.n8n. Cały katalog, razem z plikiem config. To w nim siedzi automatycznie wygenerowany N8N_ENCRYPTION_KEY - bez niego nie odszyfrujesz poświadczeń. Kopię trzymaj poza maszyną, dopóki migracja się nie uda.
Utwórz wolumen i wgraj do niego dane. Wolumen tworzysz komendą docker volume create n8n_data, a zawartość ~/.n8n przenosisz do zamontowanego /home/node/.n8n. Pilnuj właściciela plików - w obrazie n8n pracuje użytkownik node.
Uruchom kontener komendą z sekcji Najprostszy start, z tym samym wolumenem.
Sprawdź trzy rzeczy, zanim cokolwiek skasujesz: czy widzisz swoje workflow, czy poświadczenia się otwierają (to test klucza szyfrowania) i czy webhooki mają poprawne adresy.
Dopiero teraz usuń pakiet npm (npm uninstall -g n8n) i wyłącz stary autostart - usługę systemd, wpis w pm2 albo cokolwiek podnosiło n8n po restarcie. Zapomniany autostart to najczęstszy powód, dla którego po migracji "coś zajmuje port 5678".

Self-hosting na Raspberry Pi i mini PC

n8n da się uruchomić w domu na małym, energooszczędnym sprzęcie - to popularne rozwiązanie dla automatyzacji domowych i osobistych, gdzie zależy Ci na pełnej kontroli i braku opłat abonamentowych.

Raspberry Pi (najlepiej z większą ilością RAM-u) albo tani mini PC bez problemu udźwigną n8n do prywatnych workflow. Najprościej postawić n8n tak jak na każdej innej maszynie - przez Dockera (obraz wspiera architekturę ARM). Pamiętaj jednak o realiach domowego serwera:

Pamięć i dysk - wybierz wariant z większym RAM-em; jako nośnik wolimy dobry SSD/dysk niż słabą kartę microSD (mniej awarii, lepsza wydajność bazy).
Dostępność z zewnątrz - w domu zwykle nie masz publicznego, stałego IP ani otwartych portów. Tu najlepiej sprawdza się Cloudflare Tunnel (patrz sekcja "HTTPS, domena, reverse proxy i Cloudflare Tunnel" niżej), który udostępnia n8n po HTTPS bez przekierowań portów.
Backup - domowy sprzęt potrafi paść (zasilanie, karta). Regularnie kopiuj wolumen danych i klucz szyfrowania.

VPS i PaaS - gdzie postawić n8n w sieci

Gdy chcesz, by n8n działało 24/7 z publicznym adresem i sensownym uptime, najczęściej wynajmujesz VPS (własny serwer w chmurze) albo korzystasz z platformy PaaS (która część roboty bierze na siebie). Wybór to kompromis między ceną, kontrolą a wygodą.

VPS klasyczny

Pełna kontrola: Hetzner, cyber_Folks, Hostinger. Sam stawiasz Dockera, domenę i HTTPS

najtaniej za moc, ale wymaga administracji.

PaaS

Railway i podobne: deploy n8n "na klik", mniej grzebania w serwerze. Wygodniej, zwykle drożej za tę samą moc.

Mikrus i tanie VPS

Bardzo tanie, polskie maluchy do nauki i lekkich automatyzacji. Uwaga na zasoby - mało RAM-u przy cięższych workflow.

Każda z tych opcji ma inne mocne i słabe strony, inne ceny i inny poziom "zrób to sam". Zamiast streszczać je tu po łebkach, odsyłam do pełnego, regularnie aktualizowanego materiału.

HTTPS, domena, reverse proxy i Cloudflare Tunnel

Self-hostowane n8n prawie zawsze chcesz wystawić po HTTPS, na własnej domenie. To nie jest fanaberia - bez publicznego, bezpiecznego adresu nie zadziałają poprawnie webhooki ani logowanie OAuth do wielu usług.

Dlaczego OAuth wymaga publicznego HTTPS

Gdy łączysz n8n z usługą przez OAuth (Google, Slack, GitHub itd.), dostawca po zalogowaniu odsyła użytkownika na adres zwrotny (callback). Ten adres musi być publicznie dostępny i zwykle musi być po HTTPS - http://localhost nie zadziała, bo dostawca nie ma jak tam wrócić. Tak samo webhooki: zewnętrzna usługa musi móc "zapukać" do Twojego n8n z internetu.

Ścieżka A: VPS + domena + Let's Encrypt

Klasyczne wdrożenie produkcyjne. Masz VPS z publicznym IP, kierujesz na niego subdomenę (np. n8n.twojadomena.pl), a przed n8n stawiasz reverse proxy, które obsługuje HTTPS i certyfikat. Najczęstsze wybory to Traefik lub Caddy (automatyczny, darmowy certyfikat od Let's Encrypt) albo NGINX. W konfiguracji ustawiasz wtedy m.in.:

N8N_HOST - domena, pod którą działa n8n (np. n8n.twojadomena.pl).
N8N_PROTOCOL=https - protokół, którego n8n używa do budowania adresów.
WEBHOOK_URL - pełny publiczny adres bazowy webhooków.

Reverse proxy (np. Traefik) zajmie się wystawieniem TLS i automatycznym odnawianiem certyfikatu - gotowe szablony Docker Compose w docs n8n robią to za Ciebie.

Ścieżka B: lokalnie + Cloudflare Tunnel

Gdy n8n stoi w domu (Raspberry Pi, mini PC) i nie masz publicznego IP ani nie chcesz otwierać portów na routerze, świetnie sprawdza się Cloudflare Tunnel. Tunel tworzy szyfrowane połączenie wychodzące z Twojej maszyny do sieci Cloudflare i udostępnia n8n pod publiczną subdomeną po HTTPS - bez przekierowań portów i bez wystawiania IP. Dzięki temu OAuth i webhooki działają tak, jakbyś miał pełnoprawny serwer w sieci.

Klucz N8N_ENCRYPTION_KEY i zmienne środowiskowe

To prawdopodobnie najważniejsza sekcja całego modułu z perspektywy bezpieczeństwa i odzyskiwania danych. Zrozum ją zanim wpiszesz pierwsze poświadczenie do produkcyjnej instancji.

Co robi klucz szyfrowania

n8n szyfruje Twoje poświadczenia (klucze API, tokeny OAuth, hasła) przed zapisaniem ich do bazy. Do tego szyfrowania używa właśnie N8N_ENCRYPTION_KEY. Przy pierwszym uruchomieniu, jeśli nie podasz własnego klucza, n8n wygeneruje losowy klucz automatycznie i zapisze go w katalogu danych ~/.n8n (w Dockerze: /home/node/.n8n, czyli w Twoim wolumenie).

Jak ustawić własny klucz

Zamiast polegać na losowym kluczu z pliku, na produkcji warto ustawić własny, zanim uruchomisz n8n po raz pierwszy. Wygenerujesz mocny, losowy klucz np. tak (komenda openssl jest dostępna na Linux i macOS, a na Windows w "Git Bash"):

openssl rand -hex 32

Wynik podajesz n8n jako zmienną środowiskową - przy docker run przez -e, a w Compose w sekcji environment usługi:

docker run -d --name n8n \
 -p 5678:5678 \
 -e N8N_ENCRYPTION_KEY=<TWÓJ_WYGENEROWANY_KLUCZ> \
 -v n8n_data:/home/node/.n8n \
 docker.n8n.io/n8nio/n8n:2.36.7

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:2.36.7
    environment:
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}

W wariancie Compose sama wartość siedzi w pliku .env obok docker-compose.yml - dzięki temu klucz nie ląduje w pliku, który wrzucasz do repozytorium.

Inne ważne zmienne środowiskowe

n8n konfiguruje się głównie przez zmienne środowiskowe. Poza kluczem warto znać kilka podstawowych:

Zmienna	Do czego służy
`N8N_ENCRYPTION_KEY`	Klucz szyfrujący poświadczenia w bazie (opisany wyżej).
`DB_TYPE`	Typ bazy danych - domyślnie SQLite; dla Postgresa `postgresdb`.
`DB_POSTGRESDB_HOST` i pokrewne	Host, port, nazwa bazy, użytkownik i hasło połączenia z PostgreSQL.
`N8N_HOST`	Domena, pod którą działa n8n.
`N8N_PROTOCOL`	Protokół (np. `https`) używany do budowania adresów.
`WEBHOOK_URL`	Publiczny adres bazowy webhooków (ważne za reverse proxy).
`GENERIC_TIMEZONE` / `TZ`	Strefa czasowa - wpływa na node'y harmonogramu.

Aktualizacje i utrzymanie

n8n rozwija się szybko - nowe node'y, poprawki i funkcje pojawiają się często. Aktualizowanie jest proste, ale warto robić to świadomie, żeby uniknąć niespodzianek po zmianie wersji.

Aktualizacja w Docker Compose

Jeśli używasz Compose, aktualizacja to pobranie nowego obrazu i odtworzenie kontenera (dane zostają w wolumenie):

docker compose pull
docker compose up -d

Aktualizacja pojedynczego kontenera (docker run)

Przy klasycznym docker run pobierasz nowy obraz, zatrzymujesz i usuwasz stary kontener, a potem uruchamiasz nowy (na tym samym wolumenie):

docker pull docker.n8n.io/n8nio/n8n
docker stop n8n
docker rm n8n

Możesz też przypiąć konkretną wersję zamiast najnowszej, podając tag, np. docker.n8n.io/n8nio/n8n:2.36.7 (wersja stabilna na sierpień 2026) - przydatne, gdy chcesz kontrolować, na co dokładnie aktualizujesz.

Tag	Co dostajesz
`:stable`	najnowsze wydanie stabilne - to chcesz na produkcji
`:2.36.7`	konkretna, przypięta wersja - powtarzalne wdrożenia i świadome aktualizacje
`:beta`	najświeższe wydanie eksperymentalne - do testów, nie na produkcję

Numery wersji podane wyżej to stan na sierpień 2026 - aktualny stabilny tag sprawdzisz w release notes n8n.

Sprawdź się

Zanim ruszysz dalej, odpowiedz sobie na te pytania - na głos albo w dwóch zdaniach na kartce. Jeśli przy którymś się zawahasz, wróć do podlinkowanej sekcji.

Uczysz się i stawiasz pierwszą instancję lokalnie - dlaczego SQLite w zupełności wystarczy, a PostgreSQL na tym etapie byłby przerostem formy nad treścią? Jeśli nie masz pewności - Baza danych: SQLite czy PostgreSQL?.
Podczas aktualizacji kontenera docker run usuwasz stary kontener i uruchamiasz nowy w jego miejsce. Dlaczego to bezpieczne dla Twoich workflow i poświadczeń, o ile masz wolumen n8n_data, a katastrofalne bez niego? Jeśli nie masz pewności - Aktualizacja pojedynczego kontenera (docker run).
Twoje self-hostowane n8n działa na localhost bez żadnego tunelu ani domeny. Dlaczego logowanie przez Google czy Slack (OAuth) się nie uda, mimo że sama instancja działa poprawnie? Jeśli nie masz pewności - Dlaczego OAuth wymaga publicznego HTTPS.
Planujesz w przyszłości tryb kolejkowy (queue mode) z kilkoma workerami. Dlaczego wszystkie muszą mieć dokładnie ten sam N8N_ENCRYPTION_KEY, a nie każdy swój? Jeśli nie masz pewności - Jak ustawić własny klucz.
Kolega ma n8n postawione przez npm install n8n -g i pyta, czy musi coś robić. Dlaczego odpowiedź brzmi "dziś nie, ale przed październikiem 2026 tak", i który katalog jest w tej przeprowadzce ważniejszy niż sama baza? Jeśli nie masz pewności - Migracja z npm na Dockera.

Mini-zadanie: sprawdź, czy Twój wolumen naprawdę chroni dane

Potrzebujesz Dockera i kilkunastu minut.

Uruchom n8n w kontenerze z wolumenem n8n_data (komenda z sekcji Docker i Docker Compose krok po kroku).
Utwórz w edytorze pusty workflow z jednym node'em i zapisz go pod dowolną nazwą.
Zatrzymaj kontener (docker stop n8n) i usuń go (docker rm n8n).
Uruchom ponownie tę samą komendę docker run z tym samym wolumenem -v n8n_data:/home/node/.n8n.
Otwórz http://localhost:5678 - Twój workflow powinien tam nadal być. Gdybyś w kroku 1 pominął -v, po tym ćwiczeniu zniknąłby bezpowrotnie.

Co warto zapamiętać z tego modułu

Self-hosting stawiasz Dockerem - już teraz, bez wariantów. Od n8n 3.0 (październik 2026) npm install n8n i npx n8n przestają być wspierane.
Widzisz gdzieś poradnik z npm? Jest starszy niż decyzja n8n - nie idź tą drogą.
Masz instalację z npm? Przenieś zawartość ~/.n8n do wolumenu n8n_data - razem z plikiem config, bo w nim jest klucz szyfrowania.
Do nauki wystarczy mało zasobów i SQLite; do produkcji planuj 2 GB+ RAM i PostgreSQL.
n8n Cloud = najszybszy start bez administracji; self-host = kontrola i niższy koszt długofalowy.
Docker to jedyny wspierany self-host: pamiętaj o wolumenie n8n_data - bez niego tracisz dane.
OAuth i webhooki potrzebują publicznego HTTPS: VPS + domena + Let's Encrypt albo Cloudflare Tunnel.
Za reverse proxy ustaw WEBHOOK_URL, N8N_HOST i N8N_PROTOCOL.
N8N_ENCRYPTION_KEY szyfruje poświadczenia - utrata klucza = utrata poświadczeń. Backupuj go razem z bazą.
Aktualizuj świadomie: backup, release notes, docker compose pull && up -d.
Chcesz używać n8n Assistant? Sandbox jest wymagany - dołóż go nakładką docker-compose.override.yml od razu przy stawianiu instancji.

Częste pytania

Cloud czy self-hosting - od czego zacząć naukę?

Najszybszy start daje n8n Cloud (trial) albo lokalny Docker. Cloud ma zerową konfigurację i od razu działające OAuth, więc świetnie nadaje się do nauki. Gdy poczujesz się pewnie i będziesz chciał kontroli nad danymi oraz kosztami, przejdź na self-hosting przez Dockera.

Czy mogę jeszcze zainstalować n8n przez npm albo uruchomić przez npx?

W tym kursie nie - self-hosting idzie przez Dockera i tego wymagamy już teraz. Technicznie taka instalacja dziś jeszcze zadziała, ale n8n opisuje instalacje z npm jako przestarzałe od wersji 3.0, a sama wersja 3.0 planowana jest na październik 2026 - po niej self-hosting wymaga Dockera. Stawianie dziś instancji na npm oznacza więc zaplanowanie sobie przeprowadzki za kilka tygodni. Do szybkiego testu zamiast `npx n8n` użyj instalatora jednolinijkowego `curl -fsSL https://get.n8n.io | sh`, który stawia n8n w Docker Compose.

Mam n8n zainstalowane przez npm - co teraz zrobić?

Nie musisz działać tej nocy, ale zaplanuj przeniesienie przed wersją 3.0. Kolejność: zatrzymaj n8n, zrób kopię katalogu `~/.n8n` (baza SQLite, plik `config` z kluczem szyfrowania), wgraj tę zawartość do wolumenu Dockera `n8n_data` zamontowanego w `/home/node/.n8n`, uruchom kontener i sprawdź, czy widzisz swoje workflow oraz czy poświadczenia się odszyfrowują. Dopiero po udanym teście usuń pakiet npm.

Po restarcie zniknęły mi workflow i poświadczenia - dlaczego?

Najczęściej dlatego, że kontener uruchomiono bez wolumenu danych. Upewnij się, że masz `-v n8n_data:/home/node/.n8n` (lub odpowiedni wpis w Compose). Dane n8n - baza, poświadczenia, klucz szyfrowania - żyją w tym wolumenie, nie w samym kontenerze.

Czy potrzebuję własnej domeny i HTTPS?

Do nauki lokalnej nie. Ale gdy chcesz używać webhooków albo logowania OAuth do zewnętrznych usług, potrzebujesz publicznego adresu po HTTPS. Na VPS-ie zrobisz to przez reverse proxy z Let's Encrypt, a w domu najwygodniej przez Cloudflare Tunnel.

Co się stanie, jeśli zgubię N8N_ENCRYPTION_KEY?

Nie odszyfrujesz istniejących poświadczeń zapisanych w bazie - trzeba będzie wprowadzić je ponownie. Dlatego klucz traktuj jak hasło: przechowuj go bezpiecznie i backupuj razem z bazą danych. Na produkcji najlepiej ustawić własny klucz zmienną środowiskową, zanim uruchomisz instancję po raz pierwszy.

Czy muszę dokładać sandbox, żeby korzystać z n8n Assistant?

Tak, jeśli hostujesz n8n samodzielnie. Assistant pisze kod i musi go gdzieś uruchomić, a n8n nie pozwala robić tego we własnym kontenerze - bez sandboxa funkcja się nie włączy. Instalator jednolinijkowy `curl -fsSL https://get.n8n.io | sh` stawia sandbox automatycznie. Przy własnym pliku `docker-compose.yml` dokładasz trzy usługi przez `docker-compose.override.yml`, bez ruszania pliku bazowego. Doliczyć trzeba około 4 GB RAM i 2 rdzenie, bo sandbox uruchamia Dockera wewnątrz Dockera.

Jak bezpiecznie aktualizować n8n?

Najpierw backup (wolumen/baza + klucz), potem przeczytaj release notes pod kątem zmian łamiących zgodność, a następnie w Compose: `docker compose pull` i `docker compose up -d`. Na ważnych instancjach nie przeskakuj wielu wersji naraz i testuj po aktualizacji.

Następny krok

Moduł 2: Interfejs i 1. workflowInterfejs n8n i budowa pierwszego działającego workflow krok po kroku.

Utknąłeś w tym module albo coś jest nieaktualne? Napisz do mnie - poprawię materiał.

made with ❤️ by aitomate.pl - Łukasz Podgórski