Autor: Matt Connor 2026-10-11

n8n na VPS: Docker Compose, Postgres i HTTPS

Q: Dlaczego moje webhooki w n8n nie działają?

Przyczyną jest niemal zawsze WEBHOOK_URL. Jeśli zmienna jest nieustawiona lub błędna, n8n generuje adresy webhooków na podstawie N8N_HOST:N8N_PORT, często zawierające :5678 lub localhost. Wyglądają one na poprawne, ale są nieosiągalne z Internetu, przez co żądania nie docierają do serwera. Należy ustawić WEBHOOK_URL=https://n8n.example.com/ i upewnić się, że węzeł wyświetla adres URL bez numeru portu. Drugą przyczyną jest wywoływanie produkcyjnego adresu URL workflow, który nie został opublikowany, co skutkuje błędem The requested webhook ... is not registered..

Q: Co muszę archiwizować w n8n?

Dwie rzeczy. N8N_ENCRYPTION_KEY z pliku .env, ponieważ każde zapisane poświadczenie jest nim szyfrowane, a jego utrata powoduje trwałą niemożność odczytu danych; należy skopiować ten klucz poza serwer w dniu jego utworzenia. Oraz pg_dump bazy danych Postgres zawierającej workflowy, historię i poświadczenia. Przywrócenie systemu wymaga obu elementów: tego samego klucza oraz zrzutu bazy.

Q: Jak bezpiecznie aktualizować n8n?

Przypnij konkretną wersję obrazu zamiast latest, najpierw wykonaj pg_dump, ponieważ n8n automatycznie uruchamia migracje przy starcie, zapoznaj się z informacjami o wydaniu pod kątem zmian powodujących niekompatybilność, a następnie zmień wersję i uruchom docker compose pull n8n && docker compose up -d n8n. Kontener jest elementem tymczasowym, więc w razie problemów przywróć poprzednią wersję obrazu i wykonaj restore z kopii zapasowej wykonanej przed aktualizacją.

Konfiguracja n8n z bazą Postgres oraz reverse proxy. Rozwiązanie problemów z WEBHOOK_URL, kluczem szyfrującym N8N_ENCRYPTION_KEY oraz błędami połączenia w kontenerach Docker.

Co budujesz

n8n to narzędzie do automatyzacji przepływów pracy: wizualny edytor, w którym wyzwalacz, webhook, harmonogram lub przesłanie formularza uruchamia łańcuch węzłów wywołujących API, przekształcających dane i zapisujących je w innych systemach. Stało się ono standardowym rozwiązaniem integrującym przepływy pracy agentów AI, ponieważ komunikuje się z każdym dostawcą modeli i bazą danych bez konieczności pisania własnego serwisu. Jedno docker run pozwala uzyskać działający edytor w dwie minuty. Ten przewodnik dotyczy pozostałych dziewięćdziesięciu procent: zapewnienia trwałości dzięki Postgres zamiast domyślnego pliku SQLite, dostępności przez HTTPS oraz – co jest najczęstszym błędem – sprawienia, by webhooki udostępniały adres URL osiągalny z zewnątrz.

Gotowy stos składa się z dwóch kontenerów w jednej sieci Docker: samego n8n oraz bazy danych Postgres przechowującej przepływy pracy i poświadczenia. Reverse proxy na hoście dokonuje terminacji TLS i przekazuje ruch do n8n na localhost, dzięki czemu nic nie jest wystawione na świat zewnętrzny poza tym proxy. Rozwiązanie to współistnieje z innymi usługami na liście self-hostingowej na rok 2026.

Wymagania wstępne i rzeczywiste ograniczenia

Potrzebny jest VPS z co najmniej 1 GB pamięci RAM. Należy zaplanować 2 GB, gdy workflow zaczną wykonywać rzeczywiste zadania, ponieważ wykonywanie zadań wraz ze środowiskiem Node.js zużywa pamięć. Zabicie kontenera przez mechanizm OOM w trakcie wykonywania to najgorszy sposób, aby się o tym przekonać. Na początek wystarczy 1 vCPU.

Jeśli na tym serwerze ma działać również cięższa usługa, należy najpierw dobrać zasoby do jej wymagań. Typowym winowajcą jest biblioteka zdjęć, a rzeczywiste minimalne wymagania pamięci RAM PhotoPrism i Immich są znacznie wyższe niż wymagania n8n. To samo dotyczy serwera multimediów. Serwer Jellyfin wraz z przeglądarkowym interfejsem, takim jak Halcyon, który odtwarza bibliotekę na wzór wypożyczalni z lat 90., wykorzysta dostępną pamięć RAM i zapas zasobów na transkodowanie znacznie wcześniej, niż n8n zacznie je odczuwać.

Wymagana jest domena lub subdomena, na przykład n8n.example.com, z rekordem A wskazującym na publiczny adres IP serwera VPS, który musi być poprawnie rozwiązywany przed wysłaniem żądania o certyfikat. Porty 80 oraz 443 muszą być otwarte dla proxy; port 5678 używany przez n8n nie może być wystawiony na świat. Wymagane jest zainstalowanie Docker Engine oraz wtyczki Compose. Jeśli polecenie docker compose version zwraca błąd docker: 'compose' is not a docker command, oznacza to użycie starego, samodzielnego pliku binarnego, a wtyczka to sudo apt install docker-compose-plugin.

SQLite wystarcza do testów, Postgres jest zalecany dla usług o znaczeniu krytycznym

Domyślną bazą danych n8n jest plik SQLite znajdujący się w /home/node/.n8n/database.sqlite. Do wstępnych testów jest to rozwiązanie wystarczające; brak podmontowanego wolumenu oznacza utratę danych przy pierwszym odtworzeniu kontenera, co stanowi cenną lekcję. Powodem przejścia na Postgres nie jest surowa wydajność, lecz fakt, że SQLite stosuje blokadę pojedynczego zapisu. W rezultacie instancja wykonująca kilka przepływów pracy jednocześnie lub działająca w trybie kolejki, który z czasem stanie się potrzebny, zgłasza błąd SQLITE_BUSY: database is locked w warunkach współbieżności. Postgres nie posiada tego ograniczenia, pozwala na poprawne tworzenie kopii zapasowych za pomocą pg_dump i jest rozwiązaniem, które dokumentacja n8n zakłada w przypadku serwerów o znaczeniu krytycznym. Późniejsza zmiana wymaga ręcznej migracji danych, dlatego jeśli ten serwer jest istotny, należy rozpocząć pracę od Postgres.

DNS i zapora sieciowa

Skieruj rekord DNS i otwórz porty w pierwszej kolejności, aby późniejszy etap uzyskiwania certyfikatu nie zakończył się niepowodzeniem z powodu nazwy, która nie jest rozpoznawana.

dig +short n8n.example.com
curl -s ifconfig.me
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow OpenSSH
sudo ufw enable

Nie otwieraj portu 5678. Plik compose wiąże n8n z 127.0.0.1:5678, dzięki czemu tylko lokalny reverse proxy ma do niego dostęp, a ufw allow 5678 zniweczyłoby tę izolację.

Plik Compose

Utwórz katalog roboczy oraz plik docker-compose.yml. Poniżej znajduje się kompletny stos: dwie usługi, jedna prywatna sieć oraz dwa nazwane wolumeny.

services:
  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: n8n
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - n8n_net
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n -d n8n"]
      interval: 10s
      timeout: 5s
      retries: 5

  n8n:
    image: docker.n8n.io/n8nio/n8n:2.29.10
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.example.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.example.com/
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_PROXY_HOPS=1
      - GENERIC_TIMEZONE=Europe/London
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - n8n_data:/home/node/.n8n
    networks:
      - n8n_net
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  postgres_data:
  n8n_data:

networks:
  n8n_net:

Kilka decyzji wymaga bezpośredniego wyjaśnienia. DB_POSTGRESDB_HOST=postgres to nazwa usługi, którą Docker rozpoznaje wewnątrz współdzielonej sieci, w przeciwieństwie do localhost, które wewnątrz kontenera n8n oznacza samą aplikację n8n. Sekcja depends_on z condition: service_healthy zapobiega wyprzedzeniu bazy Postgres przez n8n podczas startu; bez tego n8n uruchamia się, nie znajduje bazy danych i kończy działanie. Nazwany wolumen n8n_data w lokalizacji /home/node/.n8n przechowuje klucz szyfrujący oraz, w przypadku SQLite, bazę danych – jest to katalog, którego utrata jest niedopuszczalna. Należy przypiąć obraz do konkretnej wersji, nigdy nie używać latest; powody zostały opisane w sekcji dotyczącej aktualizacji poniżej.

Plik z sekretami

Nigdy nie umieszczaj haseł w pliku compose. Przechowuj je w pliku .env obok niego, który Compose odczytuje automatycznie, i generuj je tak, aby były rzeczywiście losowe.

printf 'POSTGRES_PASSWORD=%s\n'  "$(openssl rand -hex 24)" >  .env
printf 'N8N_ENCRYPTION_KEY=%s\n' "$(openssl rand -hex 32)" >> .env
chmod 600 .env

Wartość N8N_ENCRYPTION_KEY jest najważniejszym ciągiem znaków w tym miejscu; jest to klucz, którym szyfrowane są wszystkie przechowywane dane uwierzytelniające. Ustaw go jawnie, zamiast pozwalać n8n na samodzielne wygenerowanie wartości, ponieważ wygenerowany przez Ciebie klucz można zapisać i wykorzystać do przywrócenia danych. Gdy n8n zaszyfruje pierwsze dane uwierzytelniające tym kluczem, jego zmiana sprawi, że wszystkie dane staną się niemożliwe do odszyfrowania, dlatego ustaw go raz, teraz, i nigdy więcej nie modyfikuj tej linii.

Zmienne środowiskowe decydujące o działaniu webhooków

Cztery zmienne określają, w jaki sposób n8n przedstawia się światu zewnętrznemu. Ich błędna konfiguracja to najczęstsza przyczyna problemów zgłaszanych do wsparcia technicznego n8n.

N8N_HOST to publiczna nazwa hosta, n8n.example.com. Pozostawienie wartości domyślnej localhost za proxy powoduje, że edytor próbuje załadować własne API z localhost w Twojej przeglądarce, co kończy się niepowodzeniem.
N8N_PROTOCOL=https informuje n8n, że usługa jest serwowana przez TLS. Dzięki temu n8n oznacza ciasteczka sesji jako Secure i generuje adresy URL z https://.
N8N_PORT=5678 to port, na którym n8n nasłuchuje wewnątrz kontenera. Nie jest to port publiczny; proxy obsługuje port 443.
WEBHOOK_URL=https://n8n.example.com/ to zmienna, która sprawia najwięcej problemów. n8n generuje adresy webhooków, które wklejasz do Stripe, GitHub lub innych zewnętrznych serwisów, korzystając z tych wartości. Jeśli zmienna jest nieustawiona lub błędna, n8n używa wartości domyślnej N8N_HOST:N8N_PORT i przekazuje https://n8n.example.com:5678/webhook/... lub, co gorsza, http://localhost:5678/webhook/.... Adresy te są wyświetlane bez komunikatu o błędzie, wyglądają poprawnie, ale są nieosiągalne z Internetu, przez co żądania od zewnętrznych serwisów nigdy nie docierają do celu. Ustaw tę zmienną na dokładny publiczny bazowy adres URL z ukośnikiem na końcu, a następnie sprawdź, czy węzeł webhooka wyświetla adres URL bez numeru portu.

N8N_PROXY_HOPS=1 instruuje serwer Express w n8n, aby ufał jednemu proxy znajdującemu się przed nim. Dzięki temu mechanizmy ograniczania liczby żądań (rate-limiting) oraz funkcje odczytujące adres IP klienta widzą rzeczywisty adres, a nie adres proxy. Zmienną, której celowo nie należy tutaj ustawiać, jest N8N_RUNNERS_ENABLED. Mechanizm task runners, czyli uruchamianie logiki węzła Code w osobnym procesie odizolowanym od głównego, był opcjonalny w całej linii 1.x, gdzie zmienna domyślnie przyjmowała wartość false i należało ją ustawić na true. W n8n 2.0 mechanizm ten włączono domyślnie, dlatego w linii 2.x, której dotyczy ten poradnik, zmienna ta jest uznawana za przestarzałą, a dokumentacja n8n wskazuje, że nie ma potrzeby jej ustawiania.

Pierwsze uruchomienie

docker compose up -d
docker compose ps
docker compose logs -f n8n

Poprawne pierwsze uruchomienie kończy się linią Editor is now accessible via:, poprzedzoną linią n8n ready on ..., port 5678. Polecenie docker compose ps powinno wykazać działanie obu kontenerów Up, przy czym postgres będzie oznaczone jako (healthy). Jeśli n8n znajduje się w pętli Restarting, należy sprawdzić logi; przyczyną jest niemal zawsze połączenie z bazą danych lub uprawnienia do wolumenów, opisane poniżej.

TLS z użyciem reverse proxy

Sama usługa n8n komunikuje się za pomocą zwykłego HTTP na porcie 5678; terminacja HTTPS odbywa się przed nią. Istnieją dwa przejrzyste rozwiązania.

Jeśli uruchomiono już kilka kontenerów, należy umieścić n8n za reverse proxy Traefik, który automatycznie wystawia certyfikaty TLS. Dzięki kilku etykietom Traefik samodzielnie żąda certyfikatu i zajmuje się jego odnawianiem.

Jeśli jest to jedyna aplikacja na serwerze, prostszym rozwiązaniem jest wirtualny host nginx z certyfikatem Let’s Encrypt. Należy skorzystać z konfiguracji TLS z użyciem Certbot i nginx dla Ubuntu 24.04, aby uzyskać certyfikat, a następnie zastosować poniższy blok serwera:

server {
    listen 443 ssl;
    server_name n8n.example.com;

    ssl_certificate     /etc/letsencrypt/live/n8n.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/n8n.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600;
        client_max_body_size 16m;
    }
}

Nagłówki Upgrade oraz Connection "upgrade" nie są opcjonalne. n8n przesyła aktualizacje wykonywanych procesów do edytora w czasie rzeczywistym za pośrednictwem WebSocket; bez tych dwóch linii strona logowania ładuje się, a następnie zawiesza z komunikatem o utracie połączenia. Dyrektywa proxy_read_timeout 3600 zapobiega przerywaniu długotrwałych procesów po domyślnym czasie 60 sekund w nginx. Nagłówek X-Forwarded-Proto $scheme jest uzupełnieniem N8N_PROXY_HOPS=1: informuje n8n, że oryginalne żądanie było typu HTTPS, mimo że proxy łączy się z aplikacją przez zwykłe HTTP. Dzięki temu n8n nie uznaje połączenia za niezabezpieczone i nie odrzuca własnego pliku cookie.

Pierwszy workflow, czyli przejście do praktyki

Otwórz https://n8n.example.com/, utwórz konto właściciela (kolejna sekcja) i zbuduj najprostszy workflow potwierdzający poprawność ścieżki: przychodzący webhook, wywołanie HTTP i odpowiedź wyjściowa.

Dodaj węzeł Webhook. Ustaw metodę na POST oraz ścieżkę, na przykład hello. Wyświetlone zostaną dwa adresy URL: Test URL oraz Production URL. To źródło połowy zgłoszeń typu "mój webhook nie działa". Adres Test URL odpowiada na jedno wywołanie, wyłącznie po kliknięciu Listen for test event, po czym wygasa. Adres Production URL zostaje zarejestrowany w momencie opublikowania workflow i od tego momentu odpowiada na żądania.
Dodaj za nim węzeł HTTP Request, wskazujący na dowolne publiczne API typu JSON. Metoda GET skierowana na https://api.github.com/zen zwróci jednowierszowy ciąg znaków, co jest wystarczające.
Dodaj węzeł Respond to Webhook i ustaw w węźle Webhook opcję Respond na "Using Respond to Webhook node", aby wywołujący otrzymał wynik działania węzła HTTP.
Kliknij Publish (prawy górny róg) i wywołaj workflow: curl -X POST https://n8n.example.com/webhook/hello. Powinieneś otrzymać w odpowiedzi sentencję zen. Schemat: żądanie POST, wywołanie API, odpowiedź wyjściowa – to podstawa większości rzeczywistych automatyzacji. Starsze poradniki zalecają przełączenie opcji Active; w n8n 2.0 zastąpiono ją przyciskami Publish oraz Unpublish.

Wariant oparty na harmonogramie zastępuje węzeł Webhook węzłem Schedule Trigger i wywołuje punkt końcowy modelu. Wykorzystanie modelu hostowanego lokalnie, zgodnie z instrukcją Ollama uruchomiona na tym samym VPS, to efektywny sposób na stworzenie nocnego generatora podsumowań.

Zarządzanie użytkownikami, a nie Basic Auth

Starsze poradniki dotyczące n8n zalecają ustawienie N8N_BASIC_AUTH_ACTIVE=true. Te zmienne zostały usunięte w n8n 1.0 i obecnie nic nie robią. Obecnie uwierzytelnianie opiera się na koncie właściciela: przy pierwszym otwarciu edytora n8n wymusza utworzenie konta właściciela z adresem e-mail i hasłem. Ta blokada jest obowiązkowa i nie ma trybu anonimowego. Konto należy utworzyć natychmiast po pierwszym uruchomieniu, zanim adres URL zostanie komukolwiek przekazany: między docker compose up a wysłaniem pierwszego formularza instancję może przejąć osoba, która jako pierwsza uzyska do niej dostęp. Warstwa Basic Auth na reverse proxy stanowi rozsądne dodatkowe zabezpieczenie, ale jest drugim mechanizmem kontroli dostępu, a nie właściwym uwierzytelnianiem. Konto właściciela i wszystkie pozostałe elementy opisane w tym poradniku działają w bezpłatnej edycji Community. Jeśli później potrzebni będą dodatkowi użytkownicy z granularnymi rolami lub obsługa SSO, warto przeczytać które funkcje n8n wymagają płatnej licencji, zanim plan zostanie oparty na tych funkcjach.

Kopie zapasowe: najpierw klucz szyfrujący, potem baza danych

Należy wykonać kopię zapasową dwóch elementów, które nie są w równym stopniu odtwarzalne.

N8N_ENCRYPTION_KEY. Każde poświadczenie przechowywane w n8n, tokeny API, hasła do baz danych, sekrety OAuth, jest szyfrowane w spoczynku za pomocą tego klucza. Workflows w Postgres są bezużyteczne bez niego: przywrócenie bazy danych na nową maszynę z innym kluczem uniemożliwi n8n odszyfrowanie jakiegokolwiek poświadczenia, bez możliwości odzyskania lub resetu. Plik .env przechowuje ten klucz; należy go skopiować poza serwer, najlepiej do menedżera haseł, w dniu jego utworzenia. Jest to kopia zapasowa, która ma kluczowe znaczenie.

Baza danych Postgres, zawierająca workflows, historię wykonań oraz same zaszyfrowane poświadczenia:

docker compose exec -T postgres pg_dump -U n8n -d n8n \
  | gzip > n8n-db-$(date +%F).sql.gz

Należy uruchamiać to polecenie zgodnie z harmonogramem i kopiować zrzut poza serwer. Aby przywrócić dane na nowym VPS: uruchom stos jeden raz, aby baza danych została utworzona, zatrzymaj n8n, załaduj zrzut za pomocą psql, umieść ten sam N8N_ENCRYPTION_KEY w .env i uruchom n8n. Ten sam klucz wraz ze zrzutem tworzą działającą instancję; nowy klucz oznacza workflows, które nie mogą użyć żadnego poświadczenia.

Aktualizacje: przypinanie tagu

Plik compose celowo przypina n8nio/n8n:2.29.10 zamiast latest. n8n wydaje nową wersję minor niemal co tydzień i okresowo zmienia schemat bazy danych lub działanie węzłów, dlatego latest oznacza, że automatyczne pobranie obrazu może dostarczyć wersję, która przeprowadzi migrację bazy danych w momencie uruchomienia. Należy przypiąć konkretną wersję, zapoznać się z informacjami o wydaniu przed aktualizacją, gdyż n8n wyszczególnia tam zmiany powodujące niekompatybilność, oraz przeprowadzać aktualizacje w sposób przemyślany:

docker compose exec -T postgres pg_dump -U n8n -d n8n | gzip > pre-upgrade.sql.gz
# edit the image tag in docker-compose.yml, then:
docker compose pull n8n
docker compose up -d n8n
docker compose logs -f n8n

Skoki między głównymi wersjami są najbardziej istotne. Linia 2.0 na przykład domyślnie zmieniła N8N_BLOCK_ENV_ACCESS_IN_NODE na true, więc każdy węzeł Code odczytujący process.env traci dostęp do danych, dopóki ustawienie nie zostanie przywrócone na false; to samo wydanie wprowadziło rygorystyczne uprawnienia dla pliku ustawień, domyślnie włączyło uruchamianie zadań (task runners) i zastąpiło przełącznik Activate w przepływach pracy przyciskiem Publish. Przed przekroczeniem granicy głównej wersji należy przeczytać stronę zmian powodujących niekompatybilność w 2.0. n8n automatycznie wykonuje niezbędne migracje bazy danych przy starcie, dlatego wykonanie kopii zapasowej pg_dump przed aktualizacją nie jest opcjonalne. Ponieważ poświadczenia są przechowywane w formie zaszyfrowanej przy użyciu klucza w .env, a dane znajdują się w Postgres, kontenery są nietrwałe: aktualizacja polega na ich zastąpieniu, a przywrócenie poprzedniej wersji na przypięciu wcześniejszego tagu i wgraniu zrzutu bazy danych.

Tryby awaryjne i odpowiadające im komunikaty

The requested webhook "POST hello" is not registered. Błąd 404 podczas wywoływania webhooka, którego workflow nie został opublikowany, lub podczas wywoływania ścieżki testowej, gdy nikt nie oczekuje na zdarzenie. Ścieżki testowe (/webhook-test/...) odpowiadają tylko wtedy, gdy wybrano opcję "Listen for test event"; ścieżki produkcyjne (/webhook/...) odpowiadają dopiero po opublikowaniu workflow. Pokrewny błąd This webhook is not registered for GET requests. Did you mean to make a POST request? oznacza użycie niewłaściwej metody; węzeł oczekuje POST, a wysłano GET.

Adres URL webhooka zawiera :5678 lub localhost. Węzeł wyświetla https://n8n.example.com:5678/webhook/... lub http://localhost:5678/.... Zmienna WEBHOOK_URL jest nieustawiona lub błędna, więc n8n zbudowało adres na podstawie N8N_HOST:N8N_PORT zamiast publicznego adresu bazowego. Należy ustawić WEBHOOK_URL=https://n8n.example.com/, odtworzyć kontener za pomocą docker compose up -d, a port przestanie być widoczny w adresie.

There was a problem loading init data w przeglądarce. Edytor załadował się, ale nie może połączyć się z własnym API backendu. W środowisku za proxy jest to niemal zawsze wynik błędnego N8N_HOST lub WEBHOOK_URL, braku nagłówków WebSocket Upgrade w konfiguracji proxy lub niedopasowania N8N_PROTOCOL do sposobu nawiązywania połączenia. Należy zweryfikować cztery zmienne publiczne oraz upewnić się, że proxy przekazuje Upgrade oraz Connection.

password authentication failed for user "n8n" w logach, połączone z restartem kontenera. Hasło wysyłane przez n8n nie zgadza się z hasłem, z którym zainicjalizowano bazę danych. Pułapka: Postgres odczytuje POSTGRES_PASSWORD tylko podczas inicjalizacji pustego katalogu danych. Po uruchomieniu stosu zmiana POSTGRES_PASSWORD w .env nie przyniesie efektu, ponieważ istniejący wolumen postgres_data nadal przechowuje stare hasło. Należy przywrócić pierwotne hasło lub, jeśli dane nie są wymagane, wykonać docker compose down i docker volume rm wolumenu postgres, a następnie uruchomić usługę od nowa.

EACCES: permission denied, open '/home/node/.n8n/config' przy starcie. n8n działa jako użytkownik node (UID 1000) i nie ma uprawnień do zapisu w katalogu konfiguracyjnym. Problem dotyczy montowania folderów hosta (./n8n_data:/home/node/.n8n), których właścicielem jest root. Należy użyć nazwanego wolumenu (zgodnie z powyższym przykładem) lub, w przypadku konieczności użycia bind mount, najpierw wykonać sudo chown -R 1000:1000 ./n8n_data.

Permissions 0644 for n8n settings file /home/node/.n8n/config are too wide. Changing permissions to 0600.. Od wersji 2.x n8n domyślnie wymusza 0600 na pliku ustawień i automatycznie naprawia to przy starcie. Ten wpis w logu oznacza, że uprawnienia zostały skorygowane, co często zdarza się po użyciu bind mount lub przywróceniu pliku z kopii zapasowej z nadmiarowymi uprawnieniami. Działanie nie jest wymagane; ustawienie N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false należy stosować tylko wtedy, gdy system plików faktycznie nie obsługuje uprawnień.

Mismatching encryption keys, pełny komunikat wskazuje, że klucz szyfrujący w pliku ustawień /home/node/.n8n/config nie zgadza się z N8N_ENCRYPTION_KEY w środowisku. Klucz w środowisku różni się od tego, który n8n zapisał w wolumenie danych podczas poprzedniego uruchomienia. Najczęściej wynika to z wygenerowania losowego klucza przy wcześniejszym starcie, gdy zmienna nie była ustawiona, a następnie późniejszego zdefiniowania własnego klucza. Należy przywrócić oryginalny klucz w .env lub, jeśli nie ma zapisanych poświadczeń, usunąć plik config wewnątrz wolumenu n8n_data i pozwolić n8n na jego ponowne wygenerowanie, akceptując fakt, że istniejące poświadczenia staną się niemożliwe do odczytania.

Baner logowania dotyczący bezpiecznych plików cookie: Your n8n server is configured to use a secure cookie, however you are either visiting this via an insecure URL, or using Safari. Ustawiono N8N_PROTOCOL=https, ale połączenie z n8n nastąpiło przez zwykłe HTTP, zazwyczaj poprzez bezpośrednie wywołanie adresu IP i portu zamiast przez proxy HTTPS. Należy łączyć się przez https://n8n.example.com/. Ustawienie N8N_SECURE_COOKIE=false należy stosować tylko w przypadku braku możliwości użycia HTTPS i nigdy na serwerze wystawionym bezpośrednio do Internetu.

Aby dodać model językowy do workflow, zobacz budowanie workflow AI z Claude i n8n.

FAQ

Czy do n8n użyć SQLite czy Postgres?

SQLite (ustawienie domyślne) jest wystarczające do testowania n8n oraz dla instancji osobistych, w których uruchamiany jest jeden workflow naraz. W przypadku rozwiązań produkcyjnych należy przejść na Postgres: blokada pojedynczego zapisu w SQLite powoduje database is locked przy współbieżności, a Postgres umożliwia poprawne tworzenie kopii zapasowych za pomocą pg_dump. Późniejsza migracja wymaga ręcznych działań, więc jeśli instancja jest istotna, należy od początku korzystać z Postgres.

Dlaczego moje webhooki w n8n nie działają?

Przyczyną jest niemal zawsze WEBHOOK_URL. Jeśli zmienna jest nieustawiona lub błędna, n8n generuje adresy webhooków na podstawie N8N_HOST:N8N_PORT, często zawierające :5678 lub localhost. Wyglądają one na poprawne, ale są nieosiągalne z Internetu, przez co żądania nie docierają do serwera. Należy ustawić WEBHOOK_URL=https://n8n.example.com/ i upewnić się, że węzeł wyświetla adres URL bez numeru portu. Drugą przyczyną jest wywoływanie produkcyjnego adresu URL workflow, który nie został opublikowany, co skutkuje błędem The requested webhook ... is not registered..

Co muszę archiwizować w n8n?

Dwie rzeczy. N8N_ENCRYPTION_KEY z pliku .env, ponieważ każde zapisane poświadczenie jest nim szyfrowane, a jego utrata powoduje trwałą niemożność odczytu danych; należy skopiować ten klucz poza serwer w dniu jego utworzenia. Oraz pg_dump bazy danych Postgres zawierającej workflowy, historię i poświadczenia. Przywrócenie systemu wymaga obu elementów: tego samego klucza oraz zrzutu bazy.

Jak umieścić n8n za HTTPS?

n8n obsługuje zwykły protokół HTTP na porcie 5678; reverse proxy przed nim dokonuje terminacji TLS. Powiąż n8n z 127.0.0.1:5678, aby tylko proxy miało do niego dostęp, a następnie użyj Traefik z automatycznymi certyfikatami lub nginx z certyfikatem Let's Encrypt. Ustaw N8N_PROTOCOL=https oraz WEBHOOK_URL=https://your-host/ i upewnij się, że proxy przekazuje nagłówki WebSocket Upgrade, w przeciwnym razie edytor przestanie odpowiadać.

Jak bezpiecznie aktualizować n8n?

Przypnij konkretną wersję obrazu zamiast latest, najpierw wykonaj pg_dump, ponieważ n8n automatycznie uruchamia migracje przy starcie, zapoznaj się z informacjami o wydaniu pod kątem zmian powodujących niekompatybilność, a następnie zmień wersję i uruchom docker compose pull n8n && docker compose up -d n8n. Kontener jest elementem tymczasowym, więc w razie problemów przywróć poprzednią wersję obrazu i wykonaj restore z kopii zapasowej wykonanej przed aktualizacją.

#n8n #automation #docker #self-hosting #https