n8n self-hosted — instalacja, bezpieczeństwo i RODO

n8n self-hosted to instalacja n8n na własnym serwerze firmy, w której przepływy, poświadczenia i historia wykonań pozostają w Twojej infrastrukturze.

n8n to narzędzie open source do automatyzacji w modelu low-code — buduje się w nim przepływy z gotowych klocków, a w razie potrzeby dopisuje kod. Ma ponad 400 gotowych integracji i ponad 70 węzłów AI, i można je uruchomić na dwa sposoby: jako n8n Cloud prowadzony przez producenta albo na własnym serwerze. Jeśli dopiero zaczynasz, zacznij od tekstu czym jest n8n; kwestie licencji i kosztów rozbieramy osobno w czy n8n jest darmowy.

Czy n8n jest bezpieczny?

Uczciwa odpowiedź brzmi: n8n self-hosted jest tak bezpieczny, jak środowisko, w którym go uruchomisz. Samo narzędzie ma to, czego się od niego oczekuje — szyfrowanie poświadczeń, konta użytkowników, uwierzytelnianie dwuskładnikowe, wbudowany audyt bezpieczeństwa. Ale przeniesienie automatyzacji na własny serwer nie jest zabiegiem, po którym „dane są bezpieczne". To zabieg, po którym odpowiedzialność za ich bezpieczeństwo przechodzi z dostawcy na Ciebie.

To rozróżnienie decyduje o wszystkim, co dalej. Instalacja n8n na zaniedbanym serwerze, wystawiona do internetu bez ograniczeń, jest mniej bezpieczna niż to samo n8n w chmurze producenta — mimo że dane formalnie „są u nas". Widzieliśmy takie instalacje i to nie jest rzadkość.

Co zyskujesz, a co przejmujesz

Najczęściej niedoceniany jest ostatni wiersz. Self-hosting nie jest decyzją narzędziową, tylko kadrową: ktoś w firmie albo po stronie partnera musi mieć ten serwer w zakresie obowiązków. Jeśli nikt go nie ma, instalacja żyje do pierwszej awarii albo do pierwszej luki, która nie została załatana.

Jak wygląda instalacja przez Docker

Dokumentacja n8n wskazuje dwie drogi: instalację przez npm (opisaną jako dobrą do „lokalnego developmentu, testów lub prostych wdrożeń na jednym serwerze") oraz Dockera — polecanego dla „odizolowanych środowisk, łatwych aktualizacji i powtarzalnych wdrożeń". Dla firmy właściwy jest Docker.

Polecenie startowe z oficjalnej dokumentacji, z uzupełnioną strefą czasową:

docker volume create n8n_data

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

Po uruchomieniu panel jest dostępny pod adresem http://localhost:5678. Trzy rzeczy warto z tego wyczytać:

• Port 5678: to domyślny port n8n i pierwsza decyzja bezpieczeństwa — czy i komu go udostępniasz.
• Wolumin n8n_data: katalog /home/node/.n8n przechowuje bazę, klucz szyfrujący i logi instancji. Bez tego woluminu restart kontenera kasuje wszystko.
• Baza domyślna: n8n używa SQLite (plik ~/.n8n/database.sqlite) do zapisu poświadczeń, przepływów i historii wykonań; PostgreSQL konfiguruje się opcjonalnie przez zmienne środowiskowe.

To polecenie jest punktem wyjścia, nie wdrożeniem produkcyjnym. Flaga --rm usuwa kontener po zatrzymaniu, a instalacja nie ma jeszcze ani HTTPS, ani reverse proxy. Produkcyjnie idzie się dalej: Docker Compose, PostgreSQL zamiast SQLite i proxy przed instancją.

Wymagania sprzętowe — czego dokumentacja nie podaje

Tu muszę napisać coś, czego zwykle się nie pisze: w dokumentacji instalacyjnej n8n nie znaleźliśmy podanych minimalnych wymagań sprzętowych — ani RAM, ani CPU, ani miejsca na dysku (stan na 5 sierpnia 2026). Nie podamy więc liczb, których nie da się zweryfikować u źródła, bo w internecie krąży ich sporo i wzajemnie się wykluczają.

Co da się powiedzieć uczciwie: zapotrzebowanie n8n zależy nie od samego narzędzia, tylko od tego, ile przepływów działa równolegle, jak często się uruchamiają i jak duże paczki danych przez nie przechodzą. Przepływ odpalany raz dziennie i przepływ obsługujący webhooki ze sklepu to dwa różne serwery. Praktyczne podejście: zacznij od małej maszyny, włącz monitoring zużycia pamięci i skaluj po pomiarze, a nie przed nim. Gdy liczba wykonań rośnie, pierwszym krokiem jest zwykle przejście z SQLite na PostgreSQL, a nie dokładanie RAM-u.

Co ustawić, zanim przepuścisz przez n8n pierwsze dane produkcyjne

Dokumentacja n8n ma osobny rozdział o bezpieczeństwie i warto go przejść jak listy kontrolnej. Najważniejsze pozycje:

• HTTPS przez reverse proxy: n8n zaleca postawienie przed instancją reverse proxy (np. Traefik) lub load balancera, który zajmie się także odnawianiem certyfikatów.
• Uwierzytelnianie dwuskładnikowe: włącz 2FA dla wszystkich kont z dostępem do panelu — to konta, które widzą wszystkie poświadczenia firmy.
• Wyłączenie publicznego API: jeśli przepływy nie wymagają wywołań programistycznych z zewnątrz, publiczne API należy wyłączyć.
• Ochrona przed SSRF: ustawienie kontrolujące, do jakich hostów i zakresów adresów mogą łączyć się węzły przepływu.
• Blokowanie wybranych węzłów: możesz zablokować typy węzłów, których w Twoim środowisku nie powinno być (np. wykonujących kod lub polecenia systemowe).
• Rotacja klucza szyfrującego: n8n pozwala okresowo wymieniać klucz szyfrujący poświadczenia i inne dane wrażliwe.
• Ukrywanie danych wykonań: wejścia i wyjścia węzłów można ukryć w logach wykonań, żeby historia nie stała się drugą kopią danych osobowych.
• Audyt bezpieczeństwa: n8n ma wbudowane narzędzie do przeglądu ryzyk we własnej instancji — warto uruchomić je przed startem i cyklicznie potem.

Osobno o kluczu szyfrującym, bo to element najczęściej pomijany w planach awaryjnych. n8n generuje losowy klucz przy pierwszym uruchomieniu i zapisuje go w katalogu ~/.n8n; można go też narzucić zmienną N8N_ENCRYPTION_KEY. Tym kluczem szyfrowane są poświadczenia przed zapisem do bazy. Wniosek jest prosty i kosztowny, gdy się go pominie: kopia bazy bez kopii klucza nie pozwoli odtworzyć żadnego połączenia.

Pięć błędów, które widzimy najczęściej

• Panel wystawiony do internetu bez ograniczenia dostępu. Interfejs n8n na publicznym adresie, dostępny dla każdego, kto zna URL. Minimum to ograniczenie po adresach IP, VPN albo dostęp tylko przez sieć firmową.
• Brak HTTPS. Logowanie do panelu po nieszyfrowanym połączeniu oznacza, że hasło administratora podróżuje otwartym tekstem.
• Klucze API wklejone w treść przepływu. Klucze do zewnętrznych API trzyma się w magazynie poświadczeń, nie w polach węzła ani w notatkach scenariusza. W treści przepływu są widoczne przy każdym eksporcie i w każdej historii wykonania.
• Kopia zapasowa, której nikt nie odtworzył. Backup, który nie został raz przećwiczony, jest założeniem, nie zabezpieczeniem.
• Instalacja bez właściciela. Serwer postawiony przez zewnętrznego wykonawcę i pozostawiony bez osoby odpowiedzialnej za aktualizacje przestaje być aktualizowany mniej więcej po trzech miesiącach.

Kopie zapasowe — co właściwie trzeba kopiować

Kompletna kopia instalacji n8n obejmuje trzy rzeczy: bazę danych (SQLite lub PostgreSQL), zawartość katalogu .n8n razem z kluczem szyfrującym oraz konfigurację uruchomieniową, czyli plik Compose i zmienne środowiskowe. Pominięcie któregokolwiek z nich zamienia odtwarzanie w rekonstrukcję.

Rytm, który stosujemy: kopia raz na dobę, przechowywana poza serwerem, na którym stoi n8n, oraz test odtworzenia raz na kwartał — czyli realne postawienie instancji z kopii i sprawdzenie, czy przepływy się uruchamiają. Kwartał to kompromis, nie dogmat; przy przepływach krytycznych dla sprzedaży sensowniejszy jest test miesięczny.

n8n a RODO — co self-hosting zmienia, a czego nie rozstrzyga

Tu potrzebne jest zastrzeżenie: nie jesteśmy kancelarią i poniższe uwagi są opisem technicznych konsekwencji, nie oceną prawną.

Co self-hosting realnie zmienia: dane przetwarzane w przepływach nie trafiają na serwery producenta narzędzia. W praktyce oznacza to o jeden podmiot mniej w łańcuchu przetwarzania — nie musisz układać powierzenia przetwarzania z dostawcą platformy automatyzacji, bo platforma stoi u Ciebie. Zyskujesz też pełną kontrolę nad tym, jak długo przechowywana jest historia wykonań, a to ona bywa niezauważonym archiwum danych osobowych: przepływ przetwarzający zgłoszenia z formularza zapisuje ich treść w logach wykonań, jeśli mu tego nie wyłączysz.

Czego self-hosting nie rozstrzyga: pozostają wszystkie inne podmioty, do których przepływ się łączy — CRM, dostawca poczty, model AI. Pozostaje pytanie o podstawę przetwarzania, o zakres danych przepuszczanych przez automatyzację i o rejestr czynności przetwarzania. Self-hosting nie jest odpowiedzią na żadne z nich.

Czy konkretna konfiguracja jest zgodna z RODO, to kwestia do ustalenia z inspektorem ochrony danych albo prawnikiem — z dokumentacją tego, jakie dane przez przepływ przechodzą i gdzie się zatrzymują. Ta dokumentacja jest łatwa do zrobienia i zwykle to od niej zaczynamy. Szerzej o tym piszemy w tekście o bezpieczeństwie danych przy automatyzacji i AI.

Węzły AI: dane mogą wyjść mimo self-hostingu

To najmniej oczywista rzecz w całym artykule. n8n stojące na Twoim serwerze nie oznacza, że wszystkie dane zostają u Ciebie. Jeśli przepływ zawiera węzeł AI wywołujący model przez API zewnętrznego dostawcy, treść wysłana do tego modelu opuszcza Twoją infrastrukturę — dokładnie tak samo, jak w wariancie chmurowym. Self-hosting chroni to, co n8n przetwarza lokalnie; nie chroni tego, co przepływ świadomie wysyła na zewnątrz.

Praktyczna konsekwencja: przy przepływach z AI trzeba osobno zdecydować, co do modelu trafia. Najtańszy zabieg to ograniczenie ładunku — wysyłanie fragmentu treści zamiast całego dokumentu, bez danych identyfikujących, jeśli zadanie ich nie wymaga. Alternatywą jest model uruchomiony lokalnie, ale to już inna klasa wymagań sprzętowych.

Kiedy wybrać chmurę zamiast własnego serwera

Nie będziemy udawać, że self-hosting jest zawsze lepszy. Dla większości małych firm bez zaplecza technicznego n8n Cloud jest właściwą odpowiedzią i mówimy to również wtedy, gdy oznacza mniejsze wdrożenie po naszej stronie.

Wybierz chmurę, jeśli: nikt w firmie nie administruje serwerami, automatyzacje nie przetwarzają danych szczególnie wrażliwych, a liczy się czas uruchomienia. Rozważ własny serwer, jeśli: masz wymagania compliance albo zapisy w umowach z klientami ograniczające miejsce przetwarzania, przetwarzasz dane, które nie powinny wychodzić poza firmę, albo już utrzymujesz własną infrastrukturę i dołożenie kolejnej usługi nic nie zmienia organizacyjnie.

U nas podstawowa instalacja produkcyjna — Docker Compose, PostgreSQL, HTTPS, kontrola dostępu i kopie zapasowe — to zwykle 3–5 dni roboczych, licząc konfigurację i testy odtworzenia. Uruchomienie samego kontenera do sprawdzenia narzędzia zajmuje mniej niż godzinę i od tego warto zacząć, zanim zapadnie decyzja.

Klucze do zewnętrznych API trzymamy w magazynie poświadczeń, nie w treści scenariuszy — to zasada, którą stosujemy u siebie i we wdrożeniach klientów. Firmom z wymaganiami compliance stawiamy n8n na ich własnym serwerze.

Podsumowanie

Self-hosting n8n to dobra decyzja wtedy, gdy jest decyzją świadomą: wiesz, kto aktualizuje serwer, kto trzyma kopie i kiedy ostatnio je odtworzono. Bez tych trzech odpowiedzi „dane są u nas" jest hasłem, nie zabezpieczeniem.

Jeśli chcesz zobaczyć, co takie przepływy w ogóle potrafią, zebraliśmy je w tekście o przykładach automatyzacji w n8n. Jeśli decyzja dotyczy konkretnego procesu w Twojej firmie, zaczynamy zwykle od jego rozrysowania — tak wygląda automatyzacja procesów od strony współpracy, a przy wielu systemach naraz sensowniejszym punktem wyjścia bywają integracje systemów.