n8n na VPS: Docker Compose, Postgres i HTTPS

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 wymagany w środowiskach produkcyjnych

Domyślną bazą danych n8n jest plik SQLite znajdujący się w /home/node/.n8n/database.sqlite. Rozwiązanie to sprawdza się podczas wstępnego testowania oprogramowania. Brak zamontowanego wolumenu powoduje utratę danych przy pierwszym odtworzeniu kontenera, co stanowi istotną lekcję dotyczącą trwałości danych. Przejście na Postgres nie wynika z samej wydajności; SQLite stosuje blokadę zapisu dla pojedynczego procesu, dlatego instancja wykonująca jednocześnie kilka przepływów pracy lub działająca w trybie kolejki, który docelowo będzie potrzebny, generuje błędy SQLITE_BUSY: database is locked w warunkach współbieżności. Postgres nie posiada tego ograniczenia, umożliwia poprawne tworzenie kopii zapasowych za pomocą pg_dump i jest bazą danych zakładaną w oficjalnej dokumentacji n8n dla serwerów produkcyjnych. Późniejsza zmiana wymaga ręcznej migracji danych, dlatego w przypadku systemów o znaczeniu krytycznym 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 zgłoszeń 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 czemu 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, bazując na tych wartościach. Jeśli zmienna jest nieustawiona lub błędna, n8n wraca do N8N_HOST:N8N_PORT i podaje https://n8n.example.com:5678/webhook/... lub, co gorsza, http://localhost:5678/webhook/.... Adresy te wyglądają poprawnie, nie generują błędów, 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 ze znakiem ukośnika 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: uruchamianie zadań (task runners), czyli wykonywanie logiki węzła Code w oddzielnym izolowanym procesie, jest standardem od wersji 1.69 i wymogiem od linii 2.x, na której bazuje ten poradnik, więc stara opcja jest przestarzała. Jeśli ją ustawisz, n8n jedynie zarejestruje w logach powiadomienie z zaleceniem jej usunięcia.

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 w praktyce

Otwórz https://n8n.example.com/, utwórz konto właściciela (następna sekcja) i zbuduj najprostszy workflow, który potwierdzi poprawność ścieżki: webhook na wejściu, wywołanie HTTP, odpowiedź na wyjściu.

1. Dodaj węzeł Webhook. Ustaw metodę na POST, a ścieżkę na hello. Zobaczysz 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, tylko gdy kliknięto Listen for test event; po tym czasie wygasa. Adres Production URL odpowiada zawsze, gdy workflow jest w stanie Active.
2. Dodaj za nim węzeł HTTP Request, skierowany na dowolne publiczne API typu JSON. Metoda GET dla https://api.github.com/zen zwróci jednowierszowy ciąg znaków, co jest wystarczające.
3. Dodaj węzeł Respond to Webhook i ustaw opcję Respond w węźle Webhook na "Using Respond to Webhook node", aby wywołujący otrzymał wynik z węzła HTTP.
4. Przełącz workflow w stan Active (prawy górny róg) i wywołaj go: curl -X POST https://n8n.example.com/webhook/hello. Powinieneś otrzymać z powrotem linię tekstu zen – to schemat POST na wejściu, wywołanie API, odpowiedź na wyjściu, czyli fundament większości rzeczywistych automatyzacji.

Wariant harmonogramowany zamienia węzeł Webhook na Schedule Trigger i wywołuje punkt końcowy modelu. Samodzielnie hostowany model z Ollama działającą na tym samym VPS to przejrzysty sposób na zbudowanie 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 okazjonalnie zmienia schemat bazy danych lub zachowanie węzłów, więc latest oznacza, że automatyczne pobranie obrazu może dostarczyć kompilację, która przeprowadzi migrację bazy danych w momencie uruchomienia. Należy przypiąć konkretną wersję, przeczytać informacje o wydaniu przed aktualizacją, ponieważ n8n wyszczególnia tam zmiany powodujące niekompatybilność, a następnie przeprowadzić aktualizację w sposób kontrolowany:

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 (major) są najbardziej krytyczne. 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 nie zostanie to przywrócone do false; to samo wydanie wprowadziło rygorystyczne uprawnienia dla pliku ustawień. 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ż dane uwierzytelniające są przechowywane w formie zaszyfrowanej przy użyciu klucza w .env, a dane znajdują się w Postgres, kontenery są traktowane jako tymczasowe: aktualizacja polega na ich zastąpieniu, a przywrócenie poprzedniej wersji na przypięciu wcześniejszego tagu i odtworzeniu zrzutu bazy danych.

Tryby awarii i towarzyszące im komunikaty

The requested webhook "POST hello" is not registered. Błąd 404 podczas wywoływania webhooka, którego workflow nie jest w stanie Active, lub podczas wywoływania ścieżki testowej, gdy nikt nie oczekuje na połączenie. Ścieżki testowe (/webhook-test/...) odpowiadają tylko wtedy, gdy włączono opcję "Listen for test event"; ścieżki produkcyjne (/webhook/...) odpowiadają tylko wtedy, gdy przełącznik workflow jest włączony. 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 wygenerował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 numer portu zniknie.

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 przypadku pracy za proxy prawie zawsze oznacza to błędne N8N_HOST lub WEBHOOK_URL, brak nagłówków WebSocket Upgrade w konfiguracji proxy lub niedopasowanie N8N_PROTOCOL do sposobu połączenia. Należy zweryfikować cztery zmienne publiczne oraz upewnić się, że proxy przekazuje Upgrade i Connection.

password authentication failed for user "n8n" w logach, przy jednoczesnym restartowaniu kontenera. Hasło wysyłane przez n8n nie zgadza się z tym, 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 nie ma danych do zachowania, 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 może zapisać danych w swoim katalogu konfiguracyjnym. Problem dotyczy montowania folderu hosta (./n8n_data:/home/node/.n8n), którego właścicielem jest root. Należy użyć nazwanego wolumenu (jak pokazano powyżej) 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 naprawia to automatycznie podczas startu. 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 nieprawidłowymi uprawnieniami. Nie jest wymagane żadne działanie; 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 informuje, że klucz szyfrujący w pliku ustawień /home/node/.n8n/config nie pasuje do 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 dzieje się tak, gdy n8n wygenerowało losowy klucz przy wcześniejszym starcie (gdy zmienna była nieustawiona), a następnie ustawiono inną wartość. Należy przywrócić oryginalny klucz w .env lub, jeśli nie ma zapisanych ważnych poświadczeń, usunąć plik config wewnątrz wolumenu n8n_data i pozwolić n8n na jego ponowne wygenerowanie (należy pamiętać, że istniejące poświadczenia staną się nieczytelne).

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 powinno być stosowane tylko w przypadku braku możliwości użycia HTTPS i nigdy na serwerze wystawionym bezpośrednio do Internetu.

Aby umieścić model językowy wewnątrz workflow, zobacz budowanie workflow AI z Claude i n8n.

FAQ

Czy dla n8n wybrać SQLite czy Postgres?

SQLite (ustawienie domyślne) jest wystarczające do testowania n8n oraz dla instancji osobistej, w której uruchomiony jest jeden workflow naraz. W przypadku rozwiązań produkcyjnych należy przejść na Postgres: blokada zapisu w SQLite powoduje błąd database is locked przy współbieżności, a Postgres umożliwia poprawne tworzenie kopii zapasowych za pomocą pg_dump. Migracja w późniejszym terminie wymaga ręcznych działań, dlatego jeśli instancja jest istotna, należy rozpocząć pracę od Postgres.

Dlaczego webhooks 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 zweryfikować, czy węzeł wyświetla adres URL bez numeru portu. Drugą przyczyną jest wywołanie webhooka, którego workflow nie został przełączony w stan Active, co skutkuje błędem The requested webhook ... is not registered..

Co należy archiwizować w n8n?

Dwie rzeczy. Po pierwsze N8N_ENCRYPTION_KEY z pliku .env, ponieważ wszystkie zapisane poświadczenia są nim szyfrowane, a jego utrata uniemożliwia ich odczytanie; należy skopiować go z serwera w dniu utworzenia. Po drugie pg_dump bazy danych Postgres, zawierający workflowy, historię i poświadczenia. Przywracanie 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. Należy powiązać n8n z 127.0.0.1:5678, aby tylko proxy miało do niego dostęp, a następnie użyć Traefik z automatycznymi certyfikatami lub nginx z certyfikatem Let's Encrypt. Należy ustawić N8N_PROTOCOL=https oraz WEBHOOK_URL=https://your-host/ i upewnić się, że proxy przekazuje nagłówki WebSocket Upgrade, w przeciwnym razie edytor przestanie odpowiadać.

Jak bezpiecznie aktualizować n8n?

Należy przypiąć konkretną wersję obrazu zamiast latest, wykonać pg_dump przed aktualizacją, ponieważ n8n automatycznie uruchamia migracje przy starcie, zapoznać się z informacjami o wydaniu pod kątem zmian powodujących awarie, a następnie zmienić tag i uruchomić docker compose pull n8n && docker compose up -d n8n. Kontener jest elementem tymczasowym, więc w razie problemów można przywrócić poprzednią wersję, przypinając poprzedni tag i przywracając zrzut bazy wykonany przed aktualizacją.