SSD Nodes Learn
Przewodniki Matt ConnorAutor: Matt Connor · Zaktualizowano 2026-07-24

Jak zainstalować n8n na VPS przez Docker

Instalacja n8n z Docker Compose i Postgres. Rozwiązanie problemów z WEBHOOK_URL oraz błędami encryption-key w celu zapewnienia pełnej łączności HTTPS.

Cel projektu

n8n to narzędzie do automatyzacji procesów (workflow automation). Jest to wizualny edytor, w którym wyzwalacz — webhook, harmonogram lub przesłanie formularza — uruchamia łańcuch węzłów (nodes). Węzły te wywołują interfejsy API, przekształcają dane i zapisują je w innych systemach. n8n stało się standardowym rozwiązaniem do łączenia procesów z agentami AI, ponieważ obsługuje każdego dostawcę modeli i baz danych bez konieczności pisania własnych usług. Jeden docker run uzyskuje działający edytor w dwie minuty. Niniejszy poradnik dotyczy pozostałych dziewięćdziesięciu procent konfiguracji: zapewnienia trwałości danych poprzez użycie Postgres zamiast domyślnego pliku SQLite, umożliwienia dostępu przez HTTPS oraz — co jest najczęstszym błędem — skonfigurowania webhooków tak, aby udostępniały adres URL dostępny z zewnątrz.

Gotowy stos technologiczny składa się z dwóch kontenerów w jednej sieci Docker: instancji n8n oraz bazy danych Postgres przechowującej workflowy i dane uwiertelniające. Reverse proxy na hoście kończy sesję TLS i przekazuje ruch do n8n na localhost, dzięki czemu żaden element nie jest wystawiony bezpośrednio na świat zewnętrzny poza tym proxy. Rozwiązanie to znajduje się na liście 2026 self-hosting shortlist.

Wymagania wstępne i ograniczenia

Wymagany jest serwer VPS z minimum 1 GB pamięci RAM. Należy zaplanować 2 GB po uruchomieniu rzeczywistych procesów, ponieważ procesy oraz środowisko Node.js zużywają dużo pamięci. Przerwanie działania kontenera przez mechanizm out-of-memory killer jest błędem krytycznym. Na początku wystarczy 1 vCPU.

Wymagany jest domena lub subdomena — np. n8n.example.com — z rekordem A wskazującym na publiczny adres IP serwera VPS, który musi być poprawnie rozwiązany przed wystąpieniem o certyfikat. Porty 80 i 443 muszą być otwarte dla proxy; port 5678 aplikacji n8n nie może być wystawiony bezpośrednio na internet. Wymagane są Docker Engine oraz wtyczka Compose. Jeśli docker compose version zwraca błąd docker: 'compose' is not a docker command, oznacza to użycie starego, samodzielnego pliku binarnego, a wtyczka jest sudo apt install docker-compose-plugin.

SQLite jest odpowiednie do testów, Postgres do rozwiązań produkcyjnych

Domyślną bazą danych n8n jest plik SQLite w lokalizacji /home/node/.n8n/database.sqlite. Rozwiązanie to jest wystarczające do testów — brak zamontowanego wolumenu spowoduje utratę danych przy pierwszym ponownym uruchomieniu kontenera, co stanowi istotną lekcję. Powodem przejścia na Postgres nie jest czysta wydajność; SQLite stosuje blokadę pojedynczego zapisu, przez co instancja uruchamiająca wiele workflow jednocześnie lub tryb kolejki (queue mode) generuje błędy SQLITE_BUSY: database is locked przy współbieżności. Postgres nie posiada takich ograniczeń, umożliwia czyste tworzenie kopii zapasowych za pomocą pg_dump i jest standardem przyjmowanym przez dokumentację n8n dla serwerów produkcyjnych. Późniejsza zmiana wymaga ręcznej migracji danych, dlatego w przypadku środowisk produkcyjnych należy od początku korzystać z Postgres.

DNS i firewall

Najpierw należy ustawić rekord oraz otworzyć porty. Zapobiegnie to błędowi podczas późniejszej konfiguracji certyfikatu, który wystąpi w przypadku braku możliwości rozwiązania nazwy.

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 należy otwierać portu 5678. Plik compose wiąże n8n z 127.0.0.1:5678, więc dostęp do usługi może mieć wyłącznie reverse proxy hosta. Otwarcie portu przez ufw allow 5678 zniesie tę izolację.

Plik Compose

Należy utworzyć katalog roboczy oraz docker-compose.yml. Stanowi to całą stertę (stack) — dwa serwisy, jedną prywatną 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:

Należy określić kilka kluczowych decyzji. DB_POSTGRESDB_HOST=postgres to nazwa serwisu, którą Docker rozwiązuje w sieci współdzielonej — nie jest to localhost, co wewnątrz kontenera n8n oznacza samo n8n. Użycie depends_on z condition: service_healthy zapobiega sytuacji, w której n8n próbuje połączyć się z Postgres przed jego uruchomieniem; bez tego n8n rozpoczyna pracę, nie odnajduje bazy danych i kończy proces. Nazwany wolumen n8n_data w lokalizacji /home/node/.n8n przechowuje klucz szyfrujący oraz (w przypadku SQLite) bazę danych — jest to jedyny katalog, którego nie wolno utracić. Należy przypisać obraz do konkretnej wersji, nigdy nie używać latest; powody podano w poniższej sekcji dotyczącej aktualizacji.

Plik secrets

Nigdy nie należy umieszczać haseł w pliku compose. Należy umieścić je w pliku .env obok niego, który jest automatycznie odczytywany przez Compose. Hasła należy generować w sposób losowy.

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

N8N_ENCRYPTION_KEY jest najważniejszym ciągiem znaków w tym procesie — jest to klucz, którym szyfrowane są wszystkie zapisane dane uwiertelniające. Należy ustawić go jawnie, zamiast pozwalać systemowi n8n na jego automatyczne wygenerowanie. Wartość wygenerowana przez użytkownika można zapisać i przywrócić. Gdy n8n zaszyfruje pierwsze dane uwiertelniające za pomocą tego klucza, zmiana klucza spowoduje, że wszystkie dane staną się niemożliwe do odszyfrowania — należy zatem ustawić go raz i nie zmieniać tej linii w przyszłości.

Zmienne env decydujące o działaniu webhooków

Cztery zmienne kontrolują sposób, w jaki n8n opisuje się na zewnątrz. Błędna konfiguracja tych zmiennych jest najczęstszym problemem zgłaszanym do wsparcia n8n.

  • N8N_HOST to publiczna nazwa hosta, n8n.example.com. Pozostawienie domyślnej wartości localhost przy użyciu proxy powoduje, że edytor próbuje załadować własne API z adresu localhost w przeglądarce użytkownika, co kończy się błędem.
  • N8N_PROTOCOL=https informuje n8n, że usługa jest obsługiwana przez TLS, co skutkuje oznaczeniem ciasteczka sesji Secure oraz generowaniem adresów URL https://.
  • N8N_PORT=5678 to port, na którym n8n nasłuchuje wewnątrz kontenera. Nie jest to port publiczny; port 443 jest obsługiwany przez proxy.
  • WEBHOOK_URL=https://n8n.example.com/ jest kluczową zmienną. n8n generuje adresy webhooków kopiowane do Stripe, GitHub lub innych zewnętrznych usług na podstawie tych wartości. Jeśli zmienna jest nieustawiona lub błędna, n8n używa N8N_HOST:N8N_PORT i podaje https://n8n.example.com:5678/webhook/... lub, co gorsza, http://localhost:5678/webhook/.... Adresy te są generowane bez błędów i wyglądają poprawnie, ale są nieosiągalne z internetu, przez co żądania od klienta nie docierają. Należy ustawić tę zmienną na dokładny publiczny adres base URL z ukośnikiem na końcu, a następnie potwierdzić, że węzeł webhook wyświetla adres URL bez numeru portu.

N8N_PROXY_HOPS=1 instruuje serwer Express w n8n, aby ufał jednemu proxy, co pozwala mechanizmom rate-limiting oraz funkcjom odczytującym IP klienta widzieć rzeczywisty adres, a nie adres proxy. Jedną zmienną, której celowo się nie ustawia, jest N8N_RUNNERS_ENABLED: task runners — czyli procesy uruchamiające logikę Code-node w oddzielnym piaskownicy (sandbox) — są domyślne od wersji 1.69 i są obowiązkowe w wersji 2.x, o której traktuje ten poradnik, zatem stara metoda opt-in jest przestarzała. Ustawienie tej zmiennej spowoduje jedynie wyświetlenie powiadomienia w logach z prośbą o jej usunięcie.

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:, nad którą znajduje się linia n8n ready on ..., port 5678. docker compose ps powinien wyświetlić oba kontenery Up, przy czym postgres musi być oznaczone jako (healthy). Jeśli n8n wpada w pętlę Restarting, należy sprawdzić logi — przyczyną jest najczęściej brak połączenia z bazą danych lub uprawnienia do wolumenu opisane poniżej.

TLS z reverse proxy

n8n komunikuje się za pomocą protokołu HTTP na porcie 5678; proces kończenia sesji HTTPS realizowany jest przez zewnętrzny komponent. Dostępne są dwa rozwiązania.

Jeśli działają już inne kontenery, należy umieścić n8n za reverse proxy Traefik, który automatycznie wystawia certyfikaty TLS przy użyciu odpowiednich etykiet — Traefik automatycznie żąda i odnawia certyfikat.

Jeśli jest to jedyna aplikacja na serwerze, prostszym rozwiązaniem jest wirtualny host nginx z certyfikatem Let's Encrypt. Należy użyć konfiguracji Certbot i nginx TLS 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" są obowiązkowe. n8n przesyła aktualizacje przebiegu wykonywania procesów do edytora za pomocą protokołu WebSocket. Bez tych dwóch linii strona logowania zostanie załadowana, a następnie zawiesi się z komunikatem o utracie połączenia. proxy_read_timeout 3600 zapobiega przerywaniu długotrwałych procesów po domyślnym czasie 60 sekund ustawionym w nginx. Nagłówek X-Forwarded-Proto $scheme jest powiązany z N8N_PROXY_HOPS=1: informuje on n8n, że oryginalne żądanie zostało przesłane przez HTTPS, mimo że proxy komunikuje się z aplikacją przez HTTP. Dzięki temu n8n nie uzna połączenia za niezabezpieczone i nie odrzuci własnych plików cookie.

Pierwszy proces roboczy w praktyce

Otwórz https://n8n.example.com/, utwórz konto właściciela (następna sekcja) i zbuduj najprostszy proces roboczy w celu weryfikacji ścieżki: odebranie webhooka, wywołanie HTTP oraz przesłanie odpowiedzi.

  1. Dodaj węzeł Webhook. Ustaw metodę na POST oraz ścieżkę, na przykład hello. Wyświetlane są dwa adresy URL: Test URL oraz Production URL — to najczęstsza przyczyna błędów typu "mój webhook nie działa". Test URL odpowiada na jedno wywołanie i tylko wtedy, gdy wybrany jest przycisk Listen for test event; po tym wywołaniu wygasa. Production URL odpowiada zawsze, gdy proces roboczy jest Active.
  2. Dodaj po nim węzeł HTTP Request, skierowany do dowolnego publicznego API JSON — żądanie GET do https://api.github.com/zen zwraca jednolinijkowy ciąg znaków, co jest wystarczające.
  3. Dodaj węzeł Respond to Webhook, a następnie w opcjach Respond węzła Webhook ustaw wartość "Using Respond to Webhook node", aby wywołujący otrzymał odpowiedź z węzła HTTP.
  4. Włącz status Active dla procesu roboczego (prawy górny róg) i wywołaj go: curl -X POST https://n8n.example.com/webhook/hello. Powinieneś otrzymać linię tekstu — odebranie POST, wywołanie API i wysłanie odpowiedzi; jest to schemat większości rzeczywistych automatyzacji.

W wariancie harmonogramowym węzeł Webhook zastępuje się węzłem Schedule Trigger i zamiast tego wywołuje się endpoint modelu — rozwiązanie typu self-hosted z Ollama running on the same VPS jest skutecznym sposobem na budowę nocnego podsumowywacza.

Zarządzanie użytkownikami, a nie basic auth

Starsze poradniki n8n zalecają ustawienie N8N_BASIC_AUTH_ACTIVE=true. Zmienne te zostały usunięte w wersji n8n 1.0 i obecnie nie pełnią żadnej funkcji. Obecnie uwierzytelnianie opiera się na koncie właściciela (owner account): podczas pierwszego uruchomienia edytora n8n wymusza utworzenie konta właściciela przy użyciu adresu e-mail i hasła. To zabezpieczenie jest obowiązkowe — tryb anonimowy nie istnieje. Należy utworzyć konto natychmiast po pierwszym uruchomieniu, przed udostępnieniem adresu URL innym osobom: w czasie między docker compose up a wysłaniem pierwszego formularza, instancja może zostać przejęta przez każdego, kto uzyska do niej dostęp. Dodatkowa warstwa basic-auth na reverse-proxy stanowi uzasadnione dodatkowe zabezpieczenie, jednak jest to drugi czynnik, a nie właściwe uwierzytelnianie.

Backups: najpierw klucz szyfrujący, potem baza danych

Należy wykonać kopię zapasową dwóch elementów, które nie są wymienialne w ten sam sposób.

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. Workflow zapisane w Postgres są bezużyteczne bez tego klucza: przywrócenie bazy danych na nowym serwerze z innym kluczem uniemożliwi n8n odszyfrowanie jakichkolwiek poświadczeń. Nie ma możliwości odzyskania danych ani resetu klucza. Plik .env zawiera klucz; należy skopiować go poza serwer — najlepiej do menedżera haseł — natychmiast po utworzeniu. Jest to najważniejsza kopia zapasowa.

Baza danych Postgres, zawierająca workflow, historię wykonania oraz 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 cyklicznie i kopiować zrzut poza serwer. Aby przywrócić dane na nowym VPS: należy uruchomić stos, aby baza danych została utworzona, zatrzymać n8n, wczytać zrzut za pomocą psql, umieścić ten sam N8N_ENCRYPTION_KEY w .env i uruchomić n8n. Połączenie tego samego klucza ze zrzutem bazy danych tworzy działającą instancję; nowy klucz sprawia, że workflow nie mogą używać żadnych poświadczeń.

Upgrades: pin the tag

Plik compose celowo przypisuje wersję n8nio/n8n:2.29.10 zamiast latest. n8n wydaje nową wersję minoralną niemal co tydzień. Wprowadza ona zmiany w schemacie bazy danych lub zachowaniu węzłów. Użycie latest powoduje, że automatyczne pobranie obrazu może wywołać migrację bazy danych natychmiast po uruchomieniu. Należy przypisać konkretną wersję. Przed aktualizacją należy przeczytać release notes, gdzie n8n wymienia zmiany typu breaking changes. Aktualizację należy przeprowadzać świadomie:

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

Zmiany wersji majoralnej są najbardziej krytyczne. Przykładowo, linia 2.0 domyślnie zmieniła N8N_BLOCK_ENV_ACCESS_IN_NODE na true. Każdy węzeł Code odczytujący process.env straci dostęp do danych, dopóki nie zostanie ustawiony powrót do false. Ta sama wersja wprowadziła również restrykcyjne uprawnienia do pliku settings. Przed przejściem na nową wersję majoralną należy przeczytać 2.0 breaking-changes page. n8n automatycznie wykonuje niezbędne migracje bazy danych podczas startu. Z tego powodu wykonanie pg_dump przed aktualizacją jest obowiązkowe. Ponieważ dane uwierzytelniające są szyfrowane kluczem w .env, a dane znajdują się w Postgres, kontenery są nieodwracalne (disposable). Aktualizacja polega na ich zastąpieniu, a przywrócenie poprzedniej wersji odbywa się poprzez przypisanie poprzedniego tagu i przywrócenie zrzutu bazy danych.

Tryby awarii oraz wyświetlane komunikaty

The requested webhook "POST hello" is not registered. Błąd 404 występuje podczas wywołania webhooka, którego workflow nie jest w stanie Active, lub podczas wywołania ścieżki testowej, gdy nikt nie oczekuje na zdarzenie. Ścieżki testowe (/webhook-test/...) odpowiadają tylko wtedy, gdy przycisk "Listen for test event" jest aktywny; ścieżki produkcyjne (/webhook/...) odpowiadają tylko wtedy, gdy przełącznik workflow jest włączony. Błąd This webhook is not registered for GET requests. Did you mean to make a POST request? oznacza błędną metodę — węzeł oczekuje POST, a wysłano GET.

URL webhooka wyświetla :5678 lub localhost. Węzeł zwraca https://n8n.example.com:5678/webhook/... lub http://localhost:5678/.... WEBHOOK_URL jest nieustawione lub błędne, przez co n8n zbudowało adres na podstawie N8N_HOST:N8N_PORT zamiast publicznego adresu bazowego. Należy ustawić WEBHOOK_URL=https://n8n.example.com/, ponownie utworzyć kontener z flagą docker compose up -d, a port zostanie usunięty.

There was a problem loading init data w przeglądarce. Edytor został załadowany, ale nie może połączyć się z własnym API backendowym. W przypadku użycia proxy jest to prawie zawsze błędny N8N_HOST lub WEBHOOK_URL, brak nagłówków WebSocket Upgrade w proxy lub niezgodność N8N_PROTOCOL z metodą 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 oraz restart kontenera. Hasło wysyłane przez n8n nie zgadza się z hasłem użytym podczas inicjalizacji bazy danych. Przyczyna: Postgres odczytuje POSTGRES_PASSWORD tylko podczas inicjalizacji pustego katalogu danych. Po pierwszym uruchomieniu stosu należy zmienić POSTGRES_PASSWORD w .env; istniejący wolumen postgres_data nadal przechowuje stare hasło. Należy przywrócić oryginalne hasło lub, jeśli dane nie są potrzebne, usunąć docker compose down i docker volume rm wolumen postgres, a następnie uruchomić go ponownie.

EACCES: permission denied, open '/home/node/.n8n/config' podczas startu. n8n działa jako użytkownik node (UID 1000) i nie ma uprawnień do zapisu w katalogu konfiguracyjnym. Problem występuje, gdy używany jest bind-mount folderu hosta (./n8n_data:/home/node/.n8n) należącego do użytkownika root. Należy użyć wolumenu nazwany wskazanego powyżej lub, w przypadku 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 samodzielnie naprawia go podczas uruchomienia — ten wpis w logach oznacza, że tryb został już skorygowany, najczęściej po użyciu bind-mount lub po przywróceniu pliku z luźnymi uprawnieniami. Akcja nie jest wymagana; należy ustawić N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false 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 zgadza się z N8N_ENCRYPTION_KEY w środowisku. Klucz w środowisku różni się od klucza zapisanego przez n8n w wolumenie danych podczas poprzedniego uruchomienia — najczęściej dzieje się tak, gdy n8n wygenerowało losowy klucz podczas wcześniejszego startu przy nieustawionej zmiennej, a następnie ustawiono inną. Należy przywrócić oryginalny klucz w .env lub, jeśli nie ma się wartościowych danych, usunąć plik config wewnątrz wolumenu n8n_data i pozwolić n8n na jego ponowne wygenerowanie — wiąże się to z utratą dostępu do istniejących danych uwierzytelniających.

Baner logowania o bezpiecznych plikach 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 n8n zostało uruchomione przez zwykły protokół HTTP — zazwyczaj poprzez bezpośrednie połączenie z adresem IP i portem zamiast przez proxy HTTPS. Należy łączyć się przez https://n8n.example.com/. Ustawienie N8N_SECURE_COOKIE=false jest dopuszczalne tylko wtedy, gdy użycie HTTPS jest niemożliwe, i nigdy nie należy tego robić na maszynie wystawionej na publiczny internet.

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

FAQ

Czy dla n8n należy używać SQLite czy Postgres?

SQLite (domyślne) jest odpowiednie do testowania n8n oraz dla instancji osobistych obsługujących jeden workflow naraz. Należy przejść na Postgres w przypadku systemów produkcyjnych: pojedynczy blok zapisu SQLite powoduje database is locked przy współbieżności, natomiast Postgres umożliwia poprawne tworzenie kopii zapasowych za pomocą pg_dump. Migracja jest procesem manualnym, więc w przypadku kluczowych systemów należy zacząć od Postgres.

Dlaczego webhoooki n8n nie działają?

Zazwyczaj jest to 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 — które wyglądają poprawnie, ale są nieosiągalne z internetu, przez co żądania od klienta nie docierają. Należy ustawić WEBHOOK_URL=https://n8n.example.com/ i upewnić się, że węzeł wyświetla adres URL bez portu. Drugą przyczyną jest wywoływanie webhooka, którego workflow nie jest w stanie Active, co skutkuje błędem The requested webhook ... is not registered..

Co należy wykonać w ramach kopii zapasowej n8n?

Dwie rzeczy. Plik N8N_ENCRYPTION_KEY z .env, ponieważ wszystkie zapisane dane uwierzytelniające są nim szyfrowane, a jego utrata uniemożliwia ich odczytanie — należy skopiować go z serwera w dniu utworzenia. Drugą rzeczą jest pg_dump bazy danych Postgres zawierającej workflowy, historię i dane uwierzytelniające. Przywracanie wymaga obu elementów: klucza oraz zrzutu bazy.

Jak skonfigurować HTTPS dla n8n?

n8n obsługuje protokół HTTP na porcie 5678; reverse proxy przed aplikacją terminują połączenie TLS. Należy przypisać n8n do 127.0.0.1:5678, aby dostęp miał tylko proxy, 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 zaktualizować n8n?

Zamiast używać latest należy użyć konkretnego tagu obrazu, najpierw wykonać pg_dump, ponieważ n8n automatycznie uruchamia migracje przy starcie, należy zapoznać się z release notes pod kątem zmian typu breaking changes, a następnie zmienić tag i uruchomić docker compose pull n8n && docker compose up -d n8n. Kontener jest ulotny, więc w razie problemów należy przywrócić poprzedni tag i wczytać zrzut wykonany przed aktualizacją.

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