n8n na własnym serwerze (self-hosted): instalacja w Dockerze, kopie zapasowe, aktualizacje i koszt

n8n self-hosted: co to znaczy i kiedy ma sens

Przy n8n na własnym serwerze administratorem jesteś Ty: odpowiadasz za serwer, aktualizacje i kopie. Licencja Community nic nie kosztuje, czas na utrzymanie już tak.

Self-hosting oznacza, że silnik automatyzacji działa na maszynie, którą sam wynajmujesz albo masz w firmie: na serwerze VPS, w chmurze publicznej albo na serwerze w biurze. Bez klucza licencyjnego uruchamia się bezpłatna edycja Community, która według dokumentacji producenta ma prawie pełny zestaw funkcji. Limity wykonań dokumentacja wiąże z planami subskrypcyjnymi, a cennik nie przypisuje edycji Community żadnego limitu, więc za wykonania przepływów nie płacisz; praktyczną granicą jest moc serwera.

Druga strona jest równie konkretna. Dokumentacja wymienia wiedzę potrzebną do utrzymania własnej instancji: konfigurację serwerów i kontenerów, zarządzanie zasobami i skalowaniem, zabezpieczanie serwera i aplikacji oraz konfigurację samej aplikacji. Producent poleca ten wariant doświadczonym użytkownikom, ostrzega, że błędy kończą się utratą danych, lukami i przestojami, a pozostałym zaleca swoją chmurę.

Cała droga w skrócie: serwer z Linuksem i Dockerem, subdomena z rekordem A, plik Docker Compose z reverse proxy, bazą PostgreSQL i n8n w przypiętej wersji, a w pliku .env stały klucz szyfrujący i polska strefa czasowa. Potem codzienna kopia bazy i folderu .n8n poza serwer, aktualizacja co najmniej raz w miesiącu i zewnętrzny monitoring adresu /healthz/readiness. Każdy z tych kroków opisuję niżej, z poleceniami do skopiowania.

Czym n8n jest jako narzędzie, opisuję w przewodniku n8n: co to jest i jak działa; tutaj tylko to, ile kosztuje postawienie go u siebie i jak to zrobić, żeby za rok działało jak pierwszego dnia. Ceny, polecenia, zmienne i limity pochodzą z dokumentacji i cenników producentów (n8n, PostgreSQL, home.pl); pełna lista źródeł jest pod artykułem.

• Kiedy własny serwer ma sensGdy dane nie mogą przechodzić przez infrastrukturę dostawcy platformy, gdy liczba wykonań przerasta plany chmurowe albo gdy potrzebujesz własnych węzłów i skryptów, których chmura nie uruchomi.
• Kiedy chmura wychodzi lepiejGdy nikt w firmie nie ma przypisanego czasu na aktualizacje, kopie i reagowanie na awarie. Zaoszczędzony abonament trzeba wtedy porównać z godzinami, które ktoś spędzi na gaszeniu pożarów.
• Błąd, przed którym przestrzegamInstalacja z poradnika w pół godziny, bez PostgreSQL, stałego klucza szyfrującego i kopii. Taka instancja działa, dopóki nie padnie dysk albo nie zawiedzie aktualizacja; wtedy nie ma jej z czego odtworzyć.

Licencja: co wolno za darmo, a za które funkcje trzeba zapłacić?

n8n jest udostępniane na licencji Sustainable Use License: hojnej dla firm, które automatyzują własne procesy, i surowej dla tych, które chciałyby odsprzedawać to narzędzie jako usługę.

Sustainable Use License pozwala używać i modyfikować oprogramowanie na wewnętrzne potrzeby firmy oraz do celów niekomercyjnych i osobistych. Według FAQ licencyjnego producenta w edycji Community wolno prowadzić na nim własną firmę, budować automatyzacje dla klientów na swojej instancji, o ile klienci nie mogą ich tworzyć ani edytować, i pobierać opłaty za wdrożenie, utrzymanie i szkolenia. Nie wolno hostować n8n jako usługi, w której klienci budują przepływy, pozwalać zewnętrznym użytkownikom budować lub konfigurować przepływy przez własny interfejs, API, MCP czy agenta AI ani forkować kodu, żeby wypuścić własny produkt do automatyzacji.

Dla polskiej firmy wniosek jest prosty. Jeśli automatyzujesz wyłącznie własne procesy, licencja Community Ci na to pozwala, a płatny plan kupujesz dopiero dla funkcji z tabeli niżej, takich jak SSO czy kontrola wersji w Gicie. Wykonawca może zainstalować i utrzymywać instancję na Twoim serwerze; według FAQ jest to dozwolone, o ile nie świadczy Ci jednocześnie hostingu. Polecam, żeby serwer i konto u dostawcy były zarejestrowane na Twoją firmę: wtedy przepływy i dane zostają u Ciebie także po zakończeniu współpracy z wykonawcą.

Płatne funkcje mają warunek, o którym cennik producenta mówi w części z pytaniami: klucz licencyjny Business i Enterprise musi raz dziennie łączyć się z serwerem licencji producenta i przekazuje między innymi liczbę wykonań produkcyjnych. Jeśli stawiasz instancję u siebie po to, żeby nie łączyła się z zewnątrz, uwzględnij to przed zakupem. Według tego samego cennika firmy zatrudniające mniej niż 20 osób mogą sprawdzić Start-up Plan, który obniża cenę planu Business o połowę.

Cenniki i przepisy się zmieniają. Linki do źródeł są na dole strony.

Edycje n8n na własnym serwerze według dokumentacji i cennika n8n. Ceny w euro przy płatności rocznej.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

Jaki serwer jest potrzebny i którą metodę instalacji wybrać?

Potrzebujesz Linuksa z Dockerem, subdomeny i otwartych portów 80 oraz 443. Metodę instalacji wybierasz między skryptem jednej linii a własnym plikiem Docker Compose.

Produkcyjną instalację n8n stawiasz dziś w Dockerze. Dokumentacja wymaga Docker Engine z Docker Compose w wersji 2 (sprawdzisz to poleceniem docker compose version), a dla pełnego zestawu z wbudowanym asystentem, którego kod uruchamia się w osobnej piaskownicy, podaje minimum 4 GB RAM i 2 vCPU. Taki serwer to rozsądny punkt startu także bez asystenta, bo zostawia zapas na PostgreSQL i reverse proxy.

Żeby instancja przyjmowała webhooki z internetu, potrzebuje stałego adresu. Dokumentacja zaleca osobną subdomenę, na przykład n8n.twojafirma.pl, z rekordem A wskazującym na adres IP serwera. Czym jest webhook i dlaczego potrzebuje publicznego adresu, tłumaczę w tekście webhook: co to jest.

Dokumentacja n8n zapowiada na październik 2026 r. ważną zmianę: wersja 3.0 będzie wymagać instalacji opartej na Dockerze i przestanie obsługiwać uruchamianie przez npm i npx. Istniejąca instalacja z npm na razie działa, ale aktualizacja do 3.0 oznacza przeprowadzkę do kontenera. Na Windowsie skrypt instalacyjny uruchamiasz w WSL.

Metody instalacji n8n na własnym serwerze według dokumentacji n8n.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

Instalacja n8n w Dockerze z PostgreSQL krok po kroku

Zestaw poniżej łączy dwa pliki z dokumentacji producenta: Docker Compose z Traefikiem, który sam pobiera certyfikat HTTPS i nim zarządza, oraz usługę PostgreSQL. Zamieniasz tylko domenę, adres e-mail i sekrety.

Do pliku z Traefikiem, który przekierowuje ruch z HTTP na HTTPS i publikuje aplikację tylko na 127.0.0.1, dokładam trzy ustawienia opisane w dokumentacji osobno: stały klucz szyfrujący, adres webhooków dla pracy za proxy i czyszczenie starych wykonań.

Dwie pułapki warto znać przed startem. Obraz postgres:18 domyślnie przechowuje dane w innym katalogu niż starsze wersje, dlatego linia PGDATA musi zostać; bez niej baza zapisze się poza wolumenem i po restarcie będzie pusta. Druga: jeśli zaczniesz na SQLite i później dopiszesz PostgreSQL, dane nie przeniosą się same, bo ta konfiguracja zakłada świeżą instancję. Bazę wybierz więc przed pierwszym przepływem.

Wolisz Nginx albo Caddy zamiast Traefika? Zadziałają, o ile na ostatnim proxy przed aplikacją ustawisz nagłówki X-Forwarded-For, X-Forwarded-Host i X-Forwarded-Proto, a w kontenerze zmienną N8N_PROXY_HOPS=1; tego dokumentacja wymaga przy każdym reverse proxy. Czy Twoje proxy przekazuje te nagłówki domyślnie, sprawdź w jego dokumentacji.

1. Przygotuj serwer i DNSZainstaluj Docker Engine i Docker Compose w wersji 2, dodaj rekord A dla subdomeny i otwórz na zaporze porty 80 i 443.
2. Utwórz katalog i plik .envSekrety trzymasz w jednym pliku poza repozytorium. Klucz szyfrujący i hasło do bazy generujesz jako długie, losowe ciągi i od razu zapisujesz w menedżerze haseł.
3. Utwórz compose.yamlTrzy usługi: Traefik jako reverse proxy z certyfikatem, PostgreSQL ze sprawdzaniem gotowości i n8n z przypiętą wersją obrazu.
4. Uruchom i sprawdźWydaj polecenie docker compose up -d, a potem sprawdź docker compose ps oraz adresy /healthz i /healthz/readiness. Po pierwszym wejściu na subdomenę zakładasz konto właściciela instancji.
5. Zrób pierwszą kopię, zanim zbudujesz przepływSkopiuj plik .env w bezpieczne miejsce i wykonaj kopię według sekcji o kopiach zapasowych. Klucz szyfrujący z tego dnia będzie potrzebny przy każdym przywracaniu.

mkdir n8n-compose && cd n8n-compose
cat > .env <<'EOF'
DOMAIN_NAME=twojafirma.pl
SUBDOMAIN=n8n
GENERIC_TIMEZONE=Europe/Warsaw
SSL_EMAIL=admin@twojafirma.pl
# przypięta wersja stable; najnowszy numer podaje dokumentacja n8n
N8N_VERSION=2.41.6
N8N_ENCRYPTION_KEY=<długi-losowy-ciąg>
POSTGRES_USER=n8n
POSTGRES_PASSWORD=<długie-losowe-hasło>
POSTGRES_DB=n8n
EOF

cat > compose.yaml <<'EOF'
services:
  traefik:
    image: "traefik"
    restart: always
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.web.http.redirections.entryPoint.to=websecure"
      - "--entrypoints.web.http.redirections.entrypoint.scheme=https"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.mytlschallenge.acme.tlschallenge=true"
      - "--certificatesresolvers.mytlschallenge.acme.email=${SSL_EMAIL}"
      - "--certificatesresolvers.mytlschallenge.acme.storage=/letsencrypt/acme.json"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - traefik_data:/letsencrypt
      - /var/run/docker.sock:/var/run/docker.sock:ro

  postgres:
    image: postgres:18
    restart: always
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
      PGDATA: /var/lib/postgresql/data
    volumes:
      - db_storage:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -h localhost -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 5s
      timeout: 5s
      retries: 10

  n8n:
    image: n8nio/n8n:${N8N_VERSION}
    restart: always
    ports:
      - "127.0.0.1:5678:5678"
    labels:
      - traefik.enable=true
      - traefik.http.routers.n8n.rule=Host(`${SUBDOMAIN}.${DOMAIN_NAME}`)
      - traefik.http.routers.n8n.tls=true
      - traefik.http.routers.n8n.entrypoints=web,websecure
      - traefik.http.routers.n8n.tls.certresolver=mytlschallenge
      - traefik.http.middlewares.n8n.headers.SSLRedirect=true
      - traefik.http.middlewares.n8n.headers.STSSeconds=315360000
      - traefik.http.middlewares.n8n.headers.browserXSSFilter=true
      - traefik.http.middlewares.n8n.headers.contentTypeNosniff=true
      - traefik.http.middlewares.n8n.headers.forceSTSHeader=true
      - traefik.http.middlewares.n8n.headers.SSLHost=${DOMAIN_NAME}
      - traefik.http.middlewares.n8n.headers.STSIncludeSubdomains=true
      - traefik.http.middlewares.n8n.headers.STSPreload=true
      - traefik.http.routers.n8n.middlewares=n8n@docker
    environment:
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - N8N_HOST=${SUBDOMAIN}.${DOMAIN_NAME}
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - N8N_WEBHOOK_URL=https://${SUBDOMAIN}.${DOMAIN_NAME}/
      - N8N_PROXY_HOPS=1
      - NODE_ENV=production
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${GENERIC_TIMEZONE}
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - EXECUTIONS_DATA_PRUNE=true
      - EXECUTIONS_DATA_MAX_AGE=336
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  n8n_data:
  db_storage:
  traefik_data:
EOF

docker compose up -d
docker compose ps
curl -sf http://localhost:5678/healthz
curl -sf http://localhost:5678/healthz/readiness

Które zmienne środowiskowe ustawić od pierwszego dnia?

Kilka zmiennych decyduje o tym, czy webhooki mają poprawny adres, harmonogram rusza o właściwej godzinie, a kopia daje się odtworzyć. Ustaw je przed pierwszym przepływem, nie po pierwszej awarii.

Najważniejsza jest N8N_ENCRYPTION_KEY. n8n szyfruje nią dane logowania do podłączonych aplikacji, zanim zapisze je w bazie. Jeśli jej nie ustawisz, aplikacja wygeneruje losowy klucz przy pierwszym starcie i zapisze go w pliku config w folderze .n8n. To działa, dopóki ten plik istnieje; po utracie wolumenu zostaje baza pełna zaszyfrowanych danych, których nikt nie odczyta.

Druga pułapka to strefa czasowa. Domyślna strefa to America/New_York, więc przepływ zaplanowany na 8:00 bez ustawienia GENERIC_TIMEZONE=Europe/Warsaw ruszy o 8:00 czasu nowojorskiego. GENERIC_TIMEZONE steruje węzłami harmonogramu, a TZ ustawia czas systemowy kontenera, z którego korzystają skrypty i polecenia. Ustaw obie na tę samą wartość.

Trzecia to adres webhooków. Aplikacja składa go z protokołu, hosta i portu, a za reverse proxy daje to błędny adres z portem 5678. Dlatego ustawiasz N8N_WEBHOOK_URL, która w wersji 2.35.0 zastąpiła starszą WEBHOOK_URL; stara nazwa z dawnych poradników nadal działa, ale zostawia w logu ostrzeżenie o wycofaniu.

Wybrane zmienne możesz też podawać z osobnych plików, dodając do nazwy przyrostek _FILE. Hasło do bazy nie stoi wtedy jawnie w zmiennych kontenera.

Zmienne środowiskowe n8n dla instancji produkcyjnej. Nazwy i wartości domyślne z dokumentacji n8n.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

SQLite czy PostgreSQL: którą bazę wybrać?

SQLite wystarczy do testów i nauki. Instancja, na której firma polega codziennie, powinna od początku stać na PostgreSQL.

Bez żadnej konfiguracji n8n zapisuje przepływy, dane logowania i historię wykonań w SQLite, w pliku ~/.n8n/database.sqlite. Dokumentacja mówi wprost: SQLite nadaje się do wypróbowania narzędzia, a instancja produkcyjna z więcej niż kilkoma użytkownikami albo przepływami pracującymi przez całą dobę powinna używać PostgreSQL.

Są trzy praktyczne powody, żeby nie odkładać tej decyzji. Tryb kolejki, czyli rozłożenie wykonań na wiele procesów, nie jest wspierany na SQLite. Przy SQLite miejsce po usuniętych wykonaniach nie wraca na dysk samo, tylko jest używane ponownie, a jego zwolnienie wymaga operacji VACUUM. I wreszcie dane z SQLite nie przeniosą się automatycznie, gdy dopiszesz PostgreSQL do działającej instalacji.

Wersje: według dokumentacji n8n wspierane są dwie najnowsze utrzymywane wersje główne PostgreSQL, czyli 17 i 18, oraz dodatkowo 16 dla zgodności. Ta sama dokumentacja przypomina, że projekt PostgreSQL co listopad wydaje nową wersję główną i wycofuje najstarszą, więc zakres przesuwa się co roku. Nie są wspierane bazy zgodne z PostgreSQL tylko z nazwy, takie jak AlloyDB, CockroachDB czy YugabyteDB, a Amazon Aurora ma status eksperymentalny.

Uwaga przy aktualizacji samej bazy. Przejście ze starszej wersji głównej PostgreSQL na 18 przez zmianę tagu obrazu kończy się błędem „database files are incompatible with server”. Dane zostają nienaruszone, ale potrzebujesz kopii przez pg_dumpall i procedury aktualizacji opisanej w dokumentacji PostgreSQL.

Jak zabezpieczyć panel, konta i dane logowania?

Instancja przechowuje zaszyfrowane dane logowania do podłączonych systemów i pozwala używać ich w przepływach. Dlatego dostęp do panelu chronisz tak samo jak dostęp do tych systemów.

Zacznij od tego, co widać z internetu. Z zewnątrz osiągalne są tylko porty reverse proxy, a sama aplikacja słucha na 127.0.0.1, jak w pliku powyżej. Adres, na który przychodzą webhooki, musi być publiczny. Jeśli jednak Twoje przepływy nie przyjmują niczego z zewnątrz, bo tylko odpytują systemy według harmonogramu, panel może w ogóle nie wychodzić poza sieć firmową albo VPN.

Lista osób z prawem edycji przepływów to lista osób, które w złym scenariuszu wykonają kod na serwerze. Podatność CVE-2025-68613 pozwalała zalogowanemu użytkownikowi wykonać dowolny kod z uprawnieniami procesu n8n przez wyrażenia w przepływie. Dotyczyła wersji od 0.211.0 do wydań poprawionych 1.120.4, 1.121.1 i 1.122.0, a 11 marca 2026 r. amerykańska agencja CISA wpisała ją do katalogu podatności wykorzystywanych w atakach. Opis w NVD zaleca, by do czasu aktualizacji przepływy edytowały tylko w pełni zaufane osoby.

Konta i logowanie. Pierwsze konto zakładane po instalacji jest kontem właściciela instancji. Włącz na nim uwierzytelnianie dwuskładnikowe; wymuszenie 2FA dla wszystkich użytkowników to ustawienie z planów Business i Enterprise. Logowanie przez SSO (SAML, LDAP) także wymaga płatnej licencji, a w edycji Community przepływy i dane logowania widzi tylko właściciel instancji i ich autor, bo udostępnianie jest funkcją płatną.

RODO dotyczy przetwarzania danych, a nie produktów, więc self-hosting nie załatwia zgodności sam z siebie. Firma, od której wynajmujesz serwer, zwykle jest podmiotem przetwarzającym w rozumieniu art. 28 RODO, więc potrzebujesz z nią umowy powierzenia. Przepływ, który wysyła treść maila do API modelu językowego, wynosi dane poza serwer, a historia wykonań przechowuje dane z przepływów, często osobowe, więc EXECUTIONS_DATA_MAX_AGE ustaw świadomie. Więcej w przewodniku AI Act i RODO w małej firmie.

• Aktualna wersjaInstancja z bieżącymi poprawkami bezpieczeństwa i osoba, która śledzi biuletyny bezpieczeństwa producenta. Bez tego reszta listy niewiele daje.
• Wąskie grono edytorówPrawo tworzenia i edycji przepływów tylko dla osób, którym dałbyś dostęp do samego serwera. Pozostali dostają wyniki, nie edytor.
• Sekrety poza repozytoriumPlik .env z kluczem i hasłem do bazy nie trafia do Gita ani do maila; kopia klucza leży w menedżerze haseł, oddzielnie od serwera.

Kopia zapasowa: co dokładnie kopiować i jak ją odtworzyć?

Kopia n8n ma dwie części: bazę danych i folder .n8n z kluczem szyfrującym. Jedna bez drugiej nie odtworzy instancji.

Dokumentacja producenta definiuje pełną kopię precyzyjnie. Pierwsza część to folder .n8n, w Dockerze leżący w wolumenie zamontowanym pod /home/node/.n8n. Jest w nim plik config z kluczem szyfrującym, przy SQLite także sama baza, a przy zapisie danych binarnych na dysku również pliki z wykonań. Druga część to baza PostgreSQL, kopiowana narzędziami samej bazy. Jeśli pliki binarne trzymasz w S3 albo ładujesz własne węzły z katalogów wskazanych w N8N_CUSTOM_EXTENSIONS, one też wchodzą do kopii.

Eksport z wiersza poleceń, czyli n8n export:workflow i export:credentials z flagą --backup, daje czytelne pliki JSON z przepływami i danymi logowania. Wystarczy do przeniesienia przepływów między instancjami, ale nie odtworzy instancji: nie zawiera użytkowników i ich ról, historii wykonań, zmiennych ani ustawień instancji, w tym klucza szyfrującego. Po imporcie na czystą instancję aplikacja pokaże ekran zakładania właściciela, a zaimportowane przepływy będą domyślnie wyłączone.

Przy SQLite zatrzymaj n8n przed kopiowaniem folderu, bo kopia pliku bazy w trakcie zapisu bywa niespójna. Przy PostgreSQL zrzut pg_dump robisz na działającej bazie: według dokumentacji PostgreSQL daje spójny eksport także wtedy, gdy baza jest w tym czasie używana. Ta sama dokumentacja zastrzega jednak, że poza prostymi przypadkami pg_dump nie jest właściwym narzędziem do regularnych kopii baz produkcyjnych, i opisuje dwie inne metody: kopię na poziomie plików i ciągłą archiwizację. Przy jednej instancji z niewielką bazą polecam na start codzienny pg_dump, pamiętając, że w razie awarii tracisz wtedy dane z czasu od ostatniego zrzutu; gdy baza mocno urośnie albo taka strata byłaby dotkliwa, rozważ jedną z tych metod. Kopię trzymaj poza serwerem.

Kopia, której nikt nie odtworzył, jest założeniem, a nie kopią. Art. 32 ust. 1 RODO wymienia wśród środków bezpieczeństwa zdolność do szybkiego przywrócenia dostępności danych osobowych po incydencie oraz regularne testowanie skuteczności zabezpieczeń. Polecam raz na kwartał odtworzyć kopię na osobnym serwerze i sprawdzić, czy dane logowania się odszyfrowują.

1. Zatrzymaj n8nZatrzymaj sam kontener aplikacji poleceniem docker compose stop n8n. Baza działa dalej, bo to do niej wczytasz zrzut.
2. Odtwórz folder .n8nRozpakuj archiwum do wolumenu n8n, razem z katalogami własnych węzłów, jeśli ich używasz.
3. Odtwórz bazę PostgreSQLWczytaj zrzut narzędziem pg_restore do czystej bazy o tej samej nazwie.
4. Przywróć konfiguracjęPlik .env z tym samym N8N_ENCRYPTION_KEY i danymi połączenia z bazą. Bez niego instancja nie połączy się z bazą ani nie odszyfruje danych.
5. Uruchom i sprawdźUruchom stos poleceniem docker compose up -d, zaloguj się i ręcznie uruchom jeden przepływ, który korzysta z zapisanych danych logowania. Jeśli się wykona, klucz i baza do siebie pasują.

mkdir -p backup
# 1. Przepływy i dane logowania jako JSON (do migracji, nie zamiast kopii)
docker compose exec -T n8n n8n export:workflow --backup --output=/home/node/.n8n/backups/workflows/
docker compose exec -T n8n n8n export:credentials --backup --output=/home/node/.n8n/backups/credentials/
# 2. Baza PostgreSQL: spójny zrzut w formacie custom, skompresowany
docker compose exec -T postgres pg_dump -U n8n -Fc n8n > backup/n8n-db-$(date +%F).dump
# 3. Folder .n8n: plik config z kluczem szyfrującym, pliki binarne i eksport z kroku 1
docker run --rm --volumes-from "$(docker compose ps -q n8n)" -v "$(pwd)/backup":/backup ubuntu \
  tar czf /backup/n8n-folder-$(date +%F).tar.gz /home/node/.n8n

Jak aktualizować obraz Dockera i co zmienia wersja 3.0?

Producent wydaje nową wersję n8n w większości tygodni i zaleca, żeby aktualizować co najmniej raz w miesiącu. Każdą aktualizację zaczynaj od kopii, bo powrót do starszego obrazu nie cofnie zmian w bazie.

Obrazy n8n wychodzą w dwóch liniach: stable do produkcji i beta, czyli najnowsze wydanie, które bywa niestabilne. Gdy pisałem ten przewodnik, dokumentacja podawała wersję stable 2.41.6 i beta 2.42.2. Producent zaleca aktualizować często, co najmniej raz w miesiącu, bo przeskakiwanie wielu wersji naraz zwiększa ryzyko kłopotliwej aktualizacji, i przed każdą czytać informacje o wydaniu pod kątem zmian łamiących zgodność.

Dlatego w pliku .env wersja jest przypięta, a aktualizacja to świadoma zmiana jednej linii. n8n przy starcie migruje bazę tylko do przodu, więc powrót do starego tagu obrazu nie cofnie migracji. Planem powrotu jest kopia sprzed aktualizacji, nie sam stary numer wersji.

n8n 3.0, zaplanowane na październik 2026 r., to wersja główna ze zmianami, które wymagają działania. Najważniejsze dla instancji firmowej: tylko Docker, bez npm i npx. Przy pierwszym starcie katalog ~/.n8n/binaryData dostanie nazwę ~/.n8n/storage, a jeśli istnieją oba, n8n nie wystartuje, więc własny wolumen pod starą ścieżką trzeba przenieść albo wskazać zmienną N8N_STORAGE_PATH. Tryb przechowywania plików w pamięci znika, a takie instancje przejdą na zapis na dysku. Domyślny limit czasu zadań węzła Code (zmienna N8N_RUNNERS_TASK_TIMEOUT) spada z 300 do 60 sekund, a znikają starsze węzły, między innymi Function, Item Lists, Cron, Interval i Read Binary File.

Przed przejściem na 3.0 otwórz w ustawieniach instancji raport migracji (Settings, Migration Report), który wskazuje zmiany dotyczące właśnie Twojej instancji; n8n 2.x zapisuje też przy starcie w logu ostrzeżenie o każdym wycofywanym ustawieniu, którego używasz. Na tej podstawie planuję aktualizację: najpierw kopia i lista przepływów do poprawy, potem zmiana wersji.

# 1. Kopia według sekcji o kopiach zapasowych
# 2. W pliku .env: N8N_VERSION=<nowa-wersja-stable>
docker compose pull
docker compose down
docker compose up -d
# 3. Baza połączona i zmigrowana?
curl -sf http://localhost:5678/healthz/readiness

Tryb kolejki z Redisem i monitoring: kiedy są potrzebne?

Na start wystarcza jeden proces n8n. Tryb kolejki dokładasz dopiero wtedy, gdy wykonania zaczynają się wzajemnie blokować; monitoring ustawiasz od pierwszego dnia.

W trybie kolejki główna instancja obsługuje harmonogramy i webhooki, ale nie wykonuje przepływów. Tworzy wykonanie i przekazuje jego identyfikator do Redisa, skąd bierze je pierwszy wolny proces roboczy, czyli worker. Worker pobiera przepływ z bazy, wykonuje go, zapisuje wynik i daje znać przez Redisa. Workery dokładasz i odejmujesz według obciążenia.

Warunki są twarde. Ustawiasz EXECUTIONS_MODE=queue na głównej instancji i na każdym workerze, a ten sam N8N_ENCRYPTION_KEY musi trafić do wszystkich procesów, bo inaczej workery nie odczytają danych logowania. Potrzebujesz PostgreSQL, bo na SQLite ten układ nie jest wspierany. Pliki binarne nie mogą wtedy leżeć na lokalnym dysku, więc trafiają do bazy albo do S3, a zewnętrzny magazyn plików to funkcja płatna. Worker domyślnie wykonuje 10 zadań równolegle; producent zaleca nie schodzić poniżej 5, bo wiele workerów z małą współbieżnością wyczerpuje pulę połączeń z bazą.

Kiedy to ma sens? Gdy długie przepływy, na przykład przetwarzanie dokumentów przez model AI, opóźniają krótkie, albo gdy webhooki przychodzą falami. Przy kilkunastu przepływach uruchamianych co kilka minut tryb kolejki to dodatkowe usługi do utrzymania i kopiowania bez realnej korzyści. Sam tryb kolejki jest w bezpłatnej edycji Community; płatny jest dopiero układ z wieloma instancjami głównymi (multi-main), dostępny na własnym serwerze w planie Enterprise. Cennik n8n wpisuje tryb kolejki do planu Business, ale w porównaniu z planami chmurowymi; dokumentacja edycji instalowanych na własnym serwerze wprost zaznacza, że Community go obejmuje.

Monitoring zaczynasz od trzech adresów. /healthz zwraca kod 200, gdy instancja jest osiągalna, ale nic nie mówi o bazie. /healthz/readiness zwraca 200 dopiero wtedy, gdy baza jest połączona i zmigrowana. /metrics podaje szczegółowe dane o stanie instancji po ustawieniu N8N_METRICS=true i działa tylko na własnym serwerze, nie w chmurze n8n. Na workerach punkt zdrowia włączasz zmienną QUEUE_HEALTH_CHECK_ACTIVE=true.

Sprawdzanie musi przychodzić spoza serwera. Przepływ błędów w n8n powiadomi o nieudanym wykonaniu, ale nie o tym, że leży cała instancja, więc /healthz/readiness odpytuje zewnętrzna usługa monitorująca. Jak działa przepływ błędów z węzłem Error Trigger, opisuję w porównaniu n8n, Make czy Zapier.

# główna instancja i każdy worker
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
QUEUE_BULL_REDIS_PORT=6379
N8N_ENCRYPTION_KEY=<ten-sam-klucz-we-wszystkich-procesach>
# worker: ten sam obraz n8n, inne polecenie; domyślna współbieżność to 10
n8n worker --concurrency=5

Ile to kosztuje i kiedy chmura wychodzi taniej?

Rachunek ma dwie pozycje: serwer i godziny pracy przy jego utrzymaniu. Ceny z cennika n8n i oferty home.pl zestawiam w tabeli pod tą sekcją, a tu wyjaśniam, od czego zależy wynik.

Serwer. Przykładowy VPS z oferty home.pl o parametrach z sekcji o wymaganiach, czyli z 4 GB RAM i 2 vCPU, oraz jego cenę znajdziesz w tabeli. W konfiguratorze tej oferty jako centrum danych wybrany jest Berlin, a automatyczna kopia zapasowa nie wchodzi w standard, więc kopie robisz sam albo dokupujesz. U każdego dostawcy sprawdź te same dwie rzeczy: w którym kraju stoi serwer i czy kopia jest w cenie.

Abonament w chmurze. Plany Starter i Pro różnią się między innymi liczbą wykonań w miesiącu i liczbą wykonań równoległych; limity i ceny obu są w tabeli. Plan Business jest według cennika dostępny obecnie tylko na własnym serwerze, więc powyżej Pro w chmurze zostaje Enterprise z wyceną indywidualną. Dane planów hostowanych producent przechowuje w Unii Europejskiej, na serwerach we Frankfurcie.

Cennik n8n podaje przykład: przepływ uruchamiany co 5 minut to około 8,6–⁠8,9 tys. wykonań miesięcznie. Z tych liczb wynika, że jeden taki przepływ przekracza limit Startera i mieści się w Pro, a dwa takie przepływy wychodzą już poza Pro. W edycji Community na własnym serwerze nie płacisz za wykonania osobno; płacisz za serwer, który musi je udźwignąć.

Godziny to comiesięczna aktualizacja, przegląd biuletynów bezpieczeństwa, kontrola kopii, kwartalny test odtworzenia, aktualizacje systemu i reakcja na awarię. Policz je tak: miesięczne godziny utrzymania razy stawka osoby, która je wykona, plus koszt serwera, i porównaj z abonamentem dla Twojej liczby wykonań. Sam doradzam chmurę, gdy ruch mieści się w Starterze, a własny serwer z wyznaczoną osobą do utrzymania, gdy wykonań są dziesiątki tysięcy miesięcznie albo dane muszą zostać u Ciebie.

Chmura n8n a własny serwer: opłaty i obowiązki. Ceny z cennika n8n i oferty home.pl; kwoty n8n w euro przy płatności rocznej, przelicz je po bieżącym kursie.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

Co dalej po instalacji: kto i jak utrzymuje instancję?

Postawienie instancji to jednorazowa praca, a utrzymanie trwa tak długo, jak działają przepływy. Zanim zaczniesz, ustal, kto odpowiada za cztery powtarzalne zadania.

Te zadania może przejąć Twój pracownik albo wykonawca, bo licencja, jak opisałem wyżej, pozwala wykonawcy utrzymywać instancję na serwerze klienta. Jeśli nikt nie może wziąć ich na siebie, to właśnie ta sytuacja, w której doradzam chmurę n8n zamiast własnego serwera.

Jak wygląda wdrożenie od strony firmy, od wyboru pierwszego procesu po przekazanie, opisuję w przewodniku wdrożenie n8n w firmie, a zakres prac, który biorę na siebie, w usłudze automatyzacje AI i n8n. Jeśli zastanawiasz się, czy Twoje przepływy powinny stać na własnym serwerze, napisz, jakie procesy chcesz zautomatyzować, jak często się powtarzają i z którymi systemami mają się łączyć. Odpowiadam w ciągu jednego dnia roboczego. Pracuję z Mikołowa, zdalnie w całej Polsce; postawię instancję na Twoim serwerze albo uczciwie powiem, że chmura n8n wyjdzie Ci taniej.

• Co miesiącAktualizujesz instancję do bieżącej wersji stable, ale dopiero po kopii i po przeczytaniu informacji o wydaniu oraz raportu migracji.
• Po każdym biuletynie bezpieczeństwaSprawdzasz, czy poprawka dotyczy Twojej wersji, a jeśli tak, aktualizujesz od razu, bez czekania na comiesięczny termin.
• Codziennie i raz na kwartałKopia bazy i folderu .n8n codziennie trafia automatycznie poza serwer, a raz na kwartał ktoś odtwarza ją na osobnej maszynie i sprawdza, czy dane logowania się odszyfrowują.
• Monitoring na bieżącoInstancję sprawdza z zewnątrz usługa monitorująca, która odpytuje adres /healthz/readiness, a przepływ błędów powiadamia o nieudanych wykonaniach konkretną osobę.

Pytania i odpowiedzi