Kompletny przewodnik instalacji n8n w wersji self-hosted na serwerze FreeBSD. Opisuję krok po kroku proces konfiguracji wysoce wydajnego i bezpiecznego środowiska systemowego. Wykorzystywane technologie obejmują: FreeBSD, firewall PF, Nginx jako reverse proxy, SSL oraz Redis z włączonym trybem Queue Mode. Rozwiązanie stosuję produkcyjnie we własnych projektach.
Jeden z moich przykładowych workflow n8n pracujący na serwerze FreeBSD przygotowanym według tego przewodnika: zadanie zautomatyzowanej analizy konkurencji wykorzystujące OpenAI do przetwarzania danych pobranych przez API Reddit.
n8n to potężne narzędzie typu workflow automation (jak Zapier czy Make), pozwalające tworzyć proste automatyzacje między aplikacjami po złożone procesy z logiką warunkową, AI, webhookami i transformacją danych. n8n oprócz płatnych planów subskrypcyjnych oferuje również możliwość instalacji na własnym serwerze.
Szczegółowe założenia przewodnika oraz wykorzystane technologie:
- n8n działający jako usługa systemowa FreeBSD – automatyczne uruchamianie, restarty i integracja z systemem
- Firewall PF z ochroną przed atakami – wielowarstwowa ochrona przed skanowaniem portów, atakami bruteforce na SSH i DDoS
- Najnowsza wersja Node.js LTS – stabilne środowisko uruchomieniowe z długoterminowym wsparciem
- Nginx jako reverse proxy z SSL/TLS – bezpieczna, szyfrowana komunikacja zgodna z najlepszymi praktykami branżowymi
- Automatyczne odnawianie certyfikatów Let’s Encrypt
- Redis i tryb Queue Mode dla zwiększenia wydajności – szybsze wykonywanie workflow i niezawodne kolejkowanie
n8n na FreeBSD – schemat ideowy rozwiązania uwzględniający instalację i konfigurację firewalla PF, Node.js, Redis, Nginx wraz z certyfikatem SSL.
FreeBSD dla n8n
FreeBSD od dawna jest moim systemem pierwszego wyboru dla serwera produkcyjnego z racji swojej niezawodności, bezpieczeństwa i przewidywalności. FreeBSD ma przemyślaną architekturę gdzie kernel i userland są rozwijane jako spójna całość. System zużywa mniej zasobów niż typowy Linux z systemd i całym ekosystemem. Stąd właśnie mój wybór FreeBSD jako bazy dla n8n.
n8n Self Hosted
Darmowa wersja n8n czyli self-hosted i licencja Sustainable Use License obejmuje użytek osobisty, małe firmy poniżej określonego limitu pracowników lub przychodów, organizacje non-profit oraz projekty edukacyjne. To rozwiązanie zapewnia pełną kontrolę nad instalacją i danymi, co jest szczególnie ważne z perspektywy bezpieczeństwa i prywatności. Jedynym realnym ograniczeniem jest brak możliwości uruchomienia własnej konkurencyjnej usługi hostingu n8n dla innych firm, ale dla normalnego użytku produkcyjnego jest to w pełni funkcjonalne i darmowe rozwiązanie.
Założenia i wymagania systemowe dla n8n
n8n jest zaskakująco lekką aplikacją i nawet typowy VPS jest w zupełności wystarczający do jej uruchomienia. Minimalne wymagania są naprawdę niskie – n8n może działać już na 512MB RAM i pojedynczym rdzeniu CPU. Oczywiście to absolutne minimum, przy którym system będzie działał, ale bardzo wolno, szczególnie przy bardziej skomplikowanych workflow. Parametry mojego VPS to: 2 × vCPU AMD EPYC 3GHz+, 8 GB RAM, 250GB NVMe i łącze 1Gb/s.
n8n to aplikacja Node.js, która w stanie spoczynku (bez wykonywania workflow) zajmuje około 150-300MB RAM. Prawdziwe obciążenie pojawia się dopiero podczas pracy. Jeśli automatyzacje przetwarzają duże pliki, wykonują złożone transformacje danych lub komunikują się z wieloma API jednocześnie, wtedy zapotrzebowanie na zasoby oczywiście wzrasta.
Konfiguracja z Redis, którą zalecam, znacząco poprawia wydajność. Redis działa jako bufor i menadżer kolejek, co pozwala n8n efektywniej zarządzać wieloma równoległymi workflow. Sam Redis jest również bardzo lekki – zazwyczaj zajmuje około 30-50MB RAM w podstawowej konfiguracji. Dzięki trybowi Queue Mode, n8n będzie lepiej zarządzał zasobami, rozdzielając pracę na osobne workery i unikając przeciążenia serwera.
Konfiguracja firewalla PF
Firewall, w tym przypadku PF nie jest opcjonalny dla instalacji produkcyjnej n8n – jest fundamentem bezpieczeństwa. n8n często przechowuje wrażliwe dane – credentiale do różnych usług API, tokeny dostępowe, informacje o workflow które mogą zawierać logikę biznesową. PF zapewnia, że jedynymi otwartymi portami są te, które naprawdę muszą być dostępne z zewnątrz – czyli w naszej konfiguracji: 22 dla SSH i 80 / 443 dla ruchu HTTP / HTTPS przez Nginx. Wszystkie inne porty są domyślnie zablokowane.
PF jest ekstremalnie szybki, wydajny i ma bardzo czytelną składnię konfiguracji. W przeciwieństwie do niektórych innych rozwiązań firewalli, PF działa na poziomie jądra FreeBSD, co daje mu doskonałą wydajność – nawet przy intensywnym ruchu sieciowym narzut jest minimalny.
Tworzenie pliku konfiguracyjnego PF
Utwórz lub edytuj plik /etc/pf.conf wraz z poniższą konfiguracją:
# Plik: /etc/pf.conf
# Makra
ext_if="vtnet0" # Zmień na nazwę właściwego interfejsu sieciowego
tcp_services = "{ 22, 80, 443 }"
icmp_types = "{ echoreq, unreach }"
# Opcje
set block-policy drop
set skip on lo0
# Czyszczenie
scrub in all
# Domyślne reguły
block all
pass out quick on $ext_if keep state
# Anti-spoofing
antispoof quick for $ext_if
# Zezwolenie na SSH, HTTP i HTTPS
pass in quick on $ext_if proto tcp to ($ext_if) port $tcp_services keep state
# Zezwolenie na ICMP (ping)
pass in quick on $ext_if inet proto icmp icmp-type $icmp_types keep state
# Rate limiting dla SSH (ochrona przed bruteforce)
pass in quick on $ext_if proto tcp to ($ext_if) port 22 \
keep state (max-src-conn 15, max-src-conn-rate 5/3, \
overload <bruteforce> flush global)
# Tabela dla IP prowadzących atak
table <bruteforce> persist
block quick from <bruteforce>
# Odrzucenie prób łączenia się z internetu do adresów prywatnych/specjalnych
table <rfc6890> { 0.0.0.0/8 10.0.0.0/8 100.64.0.0/10 127.0.0.0/8 169.254.0.0/16 \
172.16.0.0/12 192.0.0.0/24 192.0.0.0/29 192.0.2.0/24 192.88.99.0/24 \
192.168.0.0/16 198.18.0.0/15 198.51.100.0/24 203.0.113.0/24 \
240.0.0.0/4 255.255.255.255/32 }
block in quick on egress from <rfc6890>
block return out quick on egress to <rfc6890>
Włączenie i uruchomienie PF przy starcie systemu:
sysrc pf_enable="YES"
sysrc pflog_enable="YES"
Sprawdzenie składni konfiguracji:
pfctl -nf /etc/pf.conf
Uruchomienie PF:
service pf start
service pflog start
Instalacja Node.js
n8n jest zbudowany w oparciu o Node.js – środowisko uruchomieniowe JavaScript po stronie serwera. Node.js znany jest z wysokiej wydajności dzięki asynchronicznemu modelowi I/O oraz silnikowi V8 od Google.
n8n wymaga Node.js w wersji 18.x lub nowszej. Zainstalujemy najnowszą stabilną wersję LTS:
pkg install -y node24 npm-node24
Weryfikacja instalacji:
node --version
npm --version
Instalacja n8n
n8n zostanie zainstalowany w systemie globalnie:
npm install -g n8n
Weryfikacja instalacji:
n8n --version
Ze względów bezpieczeństwa, utworzymy dedykowanego użytkownika systemowego, mającego tylko te uprawnienia, które są absolutnie niezbędne do działania aplikacji. Ułatwia to teżaudyt bezpieczeństwa – w logach wyraźnie będzie widoczne, co dokładnie robi proces n8n, wśród działań innych usług.
pw useradd n8n -m -s /usr/sbin/nologin -c "n8n Workflow Automation"
Następnie tworzymy katalog danych n8n:
mkdir -p /home/n8n/.n8n
chown -R n8n:n8n /home/n8n/.n8n
Konfiguracja zmiennych środowiskowych n8n
n8n konfiguruje się poprzez zmienne środowiskowe w pliku /home/n8n/.n8n/.env. n8n automatycznie wczytuje ten plik przy starcie. To standard w ekosystemie Node.js – prosty format key=value bez żadnych dodatkowych poleceń.
# Plik: /home/n8n/.n8n/.env
# Podstawowa konfiguracja
N8N_HOST=0.0.0.0
N8N_PORT=5678
N8N_PROTOCOL=https
WEBHOOK_URL=https://NAZWA_TWOJEJ_DOMENY/
N8N_EDITOR_BASE_URL=https://NAZWA_TWOJEJ_DOMENY/
# Lokalizacja
GENERIC_TIMEZONE=Europe/Warsaw
# Logowanie
N8N_LOG_LEVEL=info
N8N_LOG_OUTPUT=console,file
N8N_LOG_FILE_LOCATION=/home/n8n/.n8n/logs/
# Zarządzanie wykonaniami
EXECUTIONS_DATA_SAVE_ON_ERROR=all
EXECUTIONS_DATA_SAVE_ON_SUCCESS=all
EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=true
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168
Wyjaśnienie kluczowych zmiennych:
N8N_HOST=0.0.0.0– n8n będzie nasłuchiwał na wszystkich interfejsach sieciowych. Ponieważ jesteśmy za firewallem PF i Nginx reverse proxy, jest to bezpieczne. Alternatywnie można użyć 127.0.0.1 (tylko localhost), ale wymaga to dodatkowej konfiguracji Nginx.N8N_PORT=5678– port wewnętrzny, na którym działa n8n. Ten port nie jest dostępny z zewnątrz dzięki firewall, dostęp odbywa się tylko przez Nginx przez porty 80 i 443.N8N8N_PROTOCOL=https– informuje n8n, że dostęp odbywa się przez HTTPS. To ważne dla poprawnego generowania webhooków i linków.WEBHOOK_URL– bazowy URL dla webhooków. Wiele integracji n8n używa webhooków do otrzymywania danych od zewnętrznych usług w czasie rzeczywistym.GENERIC_TIMEZONE– strefa czasowa dla logów i schedulera. Ustawienie właściwej strefy zapewnia, że zaplanowane workflow uruchamiają się o odpowiednich godzinach lokalnych.N8N_LOG_LEVEL– poziom logowania. Opcje: error, warn, info, verbose, debug. “info” to dobry balans między szczegółowością a czytelnością logów.EXECUTIONS_DATA_SAVE_ON_ERROR/SUCCESS=all– zapisuje kompletne dane wykonań, co ułatwia debugowanie. Alternatywy to none (nie zapisuj) lub save (zapisz tylko do bazy, nie do plików). Dla środowisk produkcyjnych all daje najlepszy wgląd w działanie workflow.EXECUTIONS_DATA_PRUNE=true+EXECUTIONS_DATA_MAX_AGE=168– automatycznie usuwa wykonania starsze niż 168 godzin (7 dni). Zapobiega rozrastaniu się bazy danych.
Musimy również ręcznie dodać katalog i pliki dziennika logów n8n:
mkdir -p /home/n8n/.n8n/logs
chown -R n8n:n8n /home/n8n/.n8n
Konfiguracja usługi systemowej dla n8n
Kolejny krok na utworzenie usługi systemowej (daemona) rc.d dla system init FreeBSD: /usr/local/etc/rc.d/n8n. W przeciwieństwie do systemd używanego w Linuxie, rc.d FreeBSD charakteryzuje się prostotą i przejrzystością. Między innymi właśnie dlatego wybieram FreeBSD.
Dlaczego w ogóle tworzymy usługę systemową?
- Automatyczne uruchamianie n8n przy starcie serwera
- Łatwe zarządzanie przez standardowe komendy service
- Automatyczne restarty w przypadku awarii (dzięki opcji -r w daemon)
- Spójne logowanie do plików systemowych
- Integracja z systemem zarządzania procesami FreeBSD
Tworzymy i edytujemy plik /usr/local/etc/rc.d/n8n, który uruchomi domyślną konfigurację z pliku /home/n8n/.n8n/.env. Proszę zwrócić uwagę, że tworzymy usługę dostosowaną do konfiguracji n8n uruchamianej na poziomie użytkownika n8n, którego wcześniej utworzyliśmy już w systemie.
#!/bin/sh
# PROVIDE: n8n
# REQUIRE: LOGIN DAEMON NETWORKING
# KEYWORD: shutdown
. /etc/rc.subr
name="n8n"
rcvar="n8n_enable"
load_rc_config $name
: ${n8n_enable:="NO"}
pidfile="/var/run/n8n.pid"
start_cmd="n8n_start"
stop_cmd="n8n_stop"
status_cmd="n8n_status"
n8n_start()
{
echo "Starting n8n"
touch /var/run/n8n.pid
/usr/sbin/daemon -p /var/run/n8n.pid -o /var/log/n8n.log \
su -m n8n -c "cd /home/n8n && \
HOME=/home/n8n \
PATH=/usr/local/bin:/usr/bin:/bin \
/bin/sh -c 'set -a; . /home/n8n/.n8n/.env; set +a; exec /usr/local/bin/n8n start'"
}
n8n_stop()
{
echo "Stopping n8n"
# Zabij wszystkie procesy n8n użytkownika n8n
pkill -u n8n -f "node.*n8n"
# Poczekaj chwilę
sleep 2
# Wyczyść PID file
rm -f /var/run/n8n.pid
# Sprawdź czy zatrzymane
if pgrep -u n8n -f "node.*n8n" > /dev/null; then
echo "Force killing n8n"
pkill -9 -u n8n -f "node.*n8n"
sleep 1
fi
echo "n8n stopped"
}
n8n_status()
{
# Sprawdź czy proces działa (szukaj node z n8n)
if pgrep -u n8n -f "node.*n8n" > /dev/null; then
pid=$(pgrep -u n8n -f "node.*n8n")
echo "${name} is running as pid ${pid}"
sockstat -l | grep ${pid} | grep 5678
return 0
else
echo "${name} is not running"
return 1
fi
}
run_rc_command "$1"
Nadajemy uprawnienia wykonywania dla usługi systemowej n8n:
chmod +x /usr/local/etc/rc.d/n8n
Tworzymy plik logów usługi systemowej i uprawnień zapisu dla użytkownika n8n:
touch /var/log/n8n.log
chown n8n:n8n /var/log/n8n.log
Włączamy uruchomienie usługi n8n przy starcie systemu:
sysrc n8n_enable="YES"
Instalacja i konfiguracja Redis
Redis (Remote Dictionary Server) to zaawansowana baza danych typu klucz-wartość przechowująca dane w pamięci RAM. Jest jedną z najpopularniejszych baz NoSQL używanych do cachingu, sesji użytkowników i kolejek zadań.
Jak Redis przyspiesza n8n?
- Kolejkowanie zadań – n8n używa biblioteki Bull (opartej na Redis) do zarządzania kolejką wykonań workflow
- Cache – często używane dane są przechowywane w Redis zamiast odczytywać je wielokrotnie z dysku
- Sesje – informacje o sesjach użytkowników są przechowywane w szybkiej pamięci
- Współdzielenie stanu – w instalacjach multi-instance (klastrowych) Redis synchronizuje stan między instancjami
Redis przechowuje wszystkie dane w RAM, co daje mikro-sekundowe czasy dostępu – setki razy szybciej niż tradycyjne bazy danych. Jednak oznacza to też, że Redis wymaga odpowiedniej ilości pamięci.
Instalacja Redis:
pkg install -y redis
Włączenie Redis przy starcie systemu i uruchomienie:
sysrc redis_enable="YES"
service redis start
Weryfikacja działania Redis w systemie:
redis-cli pingPolecenie powinno zwrócić: PONG
Podstawowa konfiguracja Redis
Domyślnie Redis będzie używany jako baza danych w pamięci. W późniejszym kroku (Optymalizacja n8n dzięki Redis i trybowi Queue Mode) skonfigurujemy go jako queue i cache dla n8n.
Na początku edytujemy plik /usr/local/etc/redis.conf:
# Plik: /usr/local/etc/redis.conf:
maxmemory 2gb
maxmemory-policy allkeys-lru
timeout 300
tcp-keepalive 60
i restartujemy Redis:
service redis restart
Wyjaśnienie parametrów konfiguracji Redis:
maxmemory 2gb– ogranicza użycie pamięci Redis do 2 GB. To ochrona przed wykorzystaniem całej dostępnej pamięci RAM, co mogłoby spowodować problemy z systemem. Dla małych i średnich instalacji n8n 2 GB RAM będzie zupełnie wystarczające, powinno obsłużyć ponad 100 worklow.maxmemory-policy allkeys-lru– określa strategię usuwania danych gdy Redis osiągnie limit pamięci. LRU (Least Recently Used) usuwa najrzadziej używane klucze. To dobra domyślna polityka dla cache. Alternatywne opcje to:volatile-lru– usuwa najrzadziej używane spośród kluczy z TTLnoeviction– zwraca błędy gdy pamięć jest pełna (nie zalecane dla n8n)
timeout 300– rozłącza nieaktywne połączenia klientów po 300 sekundach (5 minutach). Zapobiega gromadzeniu się “martwych” połączeń, które zużywałyby zasoby.tcp-keepalive 60– wysyła pakiety TCP keepalive co 60 sekund. Pomaga wykryć zerwane połączenia sieciowe i utrzymuje połączenia aktywne przez firewalle, które mogłyby je zamykać z powodu braku aktywności.
Domyślnie Redis nasłuchuje tylko na localhost (127.0.0.1), co jest bezpieczne i wystarczające dla prezentowanej konfiguracji.
Konfiguracja n8n do pracy z Redis
Mamy już skonfigurowany Redis w systemie. Następnie konfigurujemy n8n do pracy z Redis. W tym celu ponownie edytujemy plik /home/n8n/.n8n/.env i dodajemy na końcu nowe linie:
# Włączenie cache Redis
N8N_CACHE_ENABLED=true
CACHE_REDIS_HOST=localhost
CACHE_REDIS_PORT=6379
CACHE_REDIS_DB=1
Kolejny przykładowy workflow n8n pracujący na serwerze FreeBSD przygotowanym wg tego przewodnika. Workflow jest zmodyfikowaną wersją rozwiązania analizy konkurencji zaprezentowanego powyżej. W tym przypadku wykorzystuje Google Gemini AI do przetwarzania danych pobranych przez API Reddit.
Instalacja Nginx
Nginx to jeden z najpopularniejszych serwerów web na świecie, obsługujący ponad 30% witryn internetowych. Został zaprojektowany z myślą o wysokiej wydajności i niskim zużyciu zasobów. W naszej konfiguracji wykorzystujemy Nginx jako reverse proxy czyli serwer pośredniczący między klientami (przeglądarkami) operującymi na porcie 80/443 a serwerem aplikacji n8n na porcie 5678. Prościej: klienci łączą się z reverse proxy, który następnie przekazuje żądania do n8n.
Kluczowe zalety Nginx reverse proxy:
- Obsługa SSL/TLS – Nginx zajmuje się szyfrowaniem, odciążając n8n z tego zadania
- Bezpieczeństwo – n8n nie jest bezpośrednio dostępny z internetu
- Load balancing – możliwość rozdzielania ruchu między wiele instancji n8n i/lub np. serwer www bazujący na Apache
- Caching – przyspieszenie poprzez cache statycznych zasobów
- Kompresja – zmniejszenie transferu danych przez gzip
- Rate limiting – ochrona przed nadmiernym ruchem
- Łatwiejsze zarządzanie certyfikatami – jeden punkt zarządzania SSL
- Multi-hosting – możliwość hostowania wielu aplikacji na jednym serwerze
W profesjonalnych instalacjach Nginx często obsługuje tysiące połączeń jednocześnie przy minimalnym zużyciu zasobów – zazwyczaj poniżej 10 MB RAM.
Instalacja Nginx:
pkg install -y nginx
Szczegółową konfigurację Nginx dla n8n przeprowadzimy w części Konfiguracja Nginx jako reverse proxy dla n8n, teraz jednak dodamy do głównego pliku ustawień Nginx (/usr/local/etc/nginx/nginx.conf) dodatkowe parametry bezpieczeństwa – Rate Limiting Zones dla n8n:
# Plik: /usr/local/etc/nginx/nginx.conf
http {
include mime.types;
default_type application/octet-stream;
# DODAJ PONIŻSZE DEFINICJE RATE LIMITING ZONES
limit_req_zone $binary_remote_addr zone=login_global:10m rate=5r/s;
limit_req_zone $binary_remote_addr zone=api_global:10m rate=50r/s;
#...
#(reszta konfiguracji)Wyjaśnienie zmiennych:
zone=login_global:10m– 10MB pamięci do śledzenia adresów IP (ok. 160k adresów)zone=api_global:10m– 10MB pamięci do śledzenia adresów IP (ok. 160k adresów)rate=5r/s– maksymalnie 5 żądań na sekundę (300/min) dla endpointów logowaniarate=50r/s– maksymalnie 50 żądań na sekundę (3000/min) dla ogólnego API
Do Rate Limiting Zones odwołamy się w osobnym pliku konfiguracji n8n (opisuję w Konfiguracja Nginx jako reverse proxy dla n8n).
Na koniec tej części dodajmy jeszcze włączenie Nginx przy starcie systemu:
sysrc nginx_enable="YES"
Konfiguracja Nginx – współpraca z certyfikatem SSL
Domyślna instalacja Nginx we FreeBSD tworzy tylko katalog /usr/local/etc/nginx/. Stworzymy strukturę plików dla dodatkowych plików konfiguracyjnych:
mkdir -p /usr/local/etc/nginx/conf.d
Wprowadzamy zmiany w głównej konfiguracji Nginx tak, by przy jego starcie wczytywane były dodatkowe pliki konfiguracyjne. Edytujemy plik /usr/local/etc/nginx/nginx.conf. W sekcji http dodajemy dodatkową linię:
# Plik: /usr/local/etc/nginx/nginx.conf
http {
include mime.types;
default_type application/octet-stream;
# NALEŻY DODAĆ PONIŻSZĄ LINIĘ:
include /usr/local/etc/nginx/conf.d/*.conf;
# ... reszta konfiguracji
}
Teraz musimy stworzyć tymczasową konfigurację dla serwera Nginx by uzyskać certyfiakt SSL dla naszej domeny. Tworzymy i edytujemy plik /usr/local/etc/nginx/conf.d/temp.conf:
# Plik: /usr/local/etc/nginx/conf.d/temp.conf
server {
listen 80;
server_name YOUR_DOMAIN_NAME;
root /usr/local/www;
location /.well-known/acme-challenge/ {
try_files $uri =404;
}
}
Weryfikujemy konfigurację Nginx i uruchamiamy serwer:
nginx -t
service nginx start
Konfiguracja certyfikatu SSL
Dopiero od tego momentu, kiedy Nginx z tymczasową konfiguracją działa jako serwer web możemy wygenerować sertyfikat SSL dla naszej domeny.
Nginx natywnie obsługuje szyfrowanie SSL/TLS. Od wersji 1.25+ istnieje moduł ngx_http_acme_module, który pozwala Nginx bezpośrednio komunikować się z Let’s Encrypt bez zewnętrznych narzędzi. Jednak nie jest dostępny w standardowym pakiecie drzewa portów FreeBSD i wymaga kompilacji Nginx ze źródeł z flagą –with-http_acme_module. Dlatego upraszczając, nasza konfiguracja będzie bazować na Let’s Encrypt z Certbot, który automatyzuje proces uzyskiwania i odnawiania certyfikatów.
Dlaczego SSL/TLS jest kluczowy?
- Szyfrowanie danych – chroni hasła, credentials API i wrażliwe dane przed podsłuchem.
- Integralność – zapewnia, że dane nie zostały zmodyfikowane w tranzycie.
- Wymóg wielu API – wiele nowoczesnych API wymaga HTTPS dla webhooków.
Instalacja i użycie Certbot we FreeBSD do weryfikacji naszego serwera przez Let’s Encrypt i uzyskania darmowego certyfikatu SSL:
pkg install -y py311-certbot py311-certbot-nginx
certbot certonly --webroot \
-w /usr/local/www \
-d NAZWA_TWOJEJ_DOMENY \
--email adress@NAZWA_TWOJEJ_DOMENY \
--agree-tos \
--no-eff-email
Po skonfigurowaniu i uzyskaniu certyfikatów, możemy zrobić test:
openssl s_client -connect NAZWA_TWOJEJ_DOMENY:443 -servername NAZWA_TWOJEJ_DOMENY
oraz sprawdzić datę ważności certyfikatu:
echo | openssl s_client -connect NAZWA_TWOJEJ_DOMENY:443 2>/dev/null | openssl x509 -noout -dates
Automatyczne odnawianie certyfikatu SSL
Certyfikaty Let’s Encrypt są ważne 90 dni. To krótszy okres niż w tradycyjnych CA (zwykle rok lub więcej), ale jest celowy – wymusza automatyzację odnawiania i zmniejsza okno czasowe na wypadek kompromitacji klucza. Dodajemy zadanie cron dla automatycznego odnawiania:
crontab -ei dodajemy następującą linię:
0 3 * * * /usr/local/bin/certbot renew --quiet --post-hook "service nginx reload"Uruchamiamy zadanie codziennie o 3:00 w nocy (czas wybrany celowo, gdy ruch jest najmniejszy). Jeśli nasz serwer będzie obsługiwał więcej certyfikatów parametr renew sprawdza je wszystkie i odnawia tylko te, które wygasają w ciągu 30 dni. Certbot sam decyduje, czy odnowienie jest potrzebne.
Możemy również przetestować proces odnowienia bez faktycznego odnowienia certyfikatu poleceniem:
certbot renew --dry-runTo symuluje cały proces i informuje o potencjalnych problemach. Zalecam uruchomienie tego testu zaraz po konfiguracji.
Ostatnim krokiem jest weryfikacja konfiguracji Nginx i uruchomienie wraz z obługą certyfikatu SSL:
nginx -t
service nginx reload
Teraz możemy usunąć tymczasową konfigurację Nginx:
rm /usr/local/etc/nginx/conf.d/temp.conf
Konfiguracja Nginx jako reverse proxy dla n8n
Kiedy Nginx wraz z właściwą domeną obsługują już certyfikat SSL, możemy stworzyć dedykowaną konfigurację dla n8n w Nginx, tworząc i edytując plik /usr/local/etc/nginx/conf.d/n8n.conf:
# Plik: /usr/local/etc/nginx/conf.d/n8n.conf
upstream n8n_backend {
server 127.0.0.1:5678;
keepalive 64;
}
server {
listen 80;
server_name NAZWA_TWOJEJ_DOMENY;
# Przekierowanie HTTP na HTTPS
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl;
http2 on;
server_name NAZWA_TWOJEJ_DOMENY;
# Ścieżki do certyfikatów SSL (skonfigurujemy w następnym kroku)
ssl_certificate /usr/local/etc/letsencrypt/live/NAZWA_TWOJEJ_DOMENY/fullchain.pem;
ssl_certificate_key /usr/local/etc/letsencrypt/live/NAZWA_TWOJEJ_DOMENY/privkey.pem;
# Konfiguracja SSL
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
# Nagłówki bezpieczeństwa
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
# Logi
access_log /var/log/nginx/n8n_access.log;
error_log /var/log/nginx/n8n_error.log;
# Limity rozmiaru
client_max_body_size 50M;
# Użycie rate limiting zosnes z nginx.conf
location /rest/login {
limit_req zone=login_global burst=3 nodelay;
limit_req_status 429;
proxy_pass http://n8n_backend;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location /rest/ {
limit_req zone=api_global burst=20 nodelay;
limit_req_status 429;
proxy_pass http://n8n_backend;
proxy_http_version 1.1;
# WebSocket support
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location /webhook/ {
limit_req zone=api_global burst=50 nodelay;
limit_req_status 429;
proxy_pass http://n8n_backend;
proxy_http_version 1.1;
# WebSocket support
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location / {
proxy_pass http://n8n_backend;
proxy_http_version 1.1;
# Nagłówki proxy
proxy_set_header Connection '';
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
# WebSocket support
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
# Timeouty
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
# Buforowanie
proxy_buffering off;
proxy_cache_bypass $http_upgrade;
}
}Warte odnotowania pozycje konfiguracji:
upstream n8n_backend– definiuje backend server (n8n). Blok upstream pozwala na definiowanie wielu serwerów dla load balancingu. keepalive 64 utrzymuje do 64 otwartych połączeń do backendu, redukując overhead tworzenia nowych połączeń.ssl_ciphers– lista algorytmów szyfrowania. Preferujemy nowoczesne szyfry ECDHE z GCM (Galois/Counter Mode), które oferują perfect forward secrecy – nawet jeśli prywatny klucz serwera wycieknie w przyszłości, wcześniejsza komunikacja pozostaje bezpieczna.client_max_body_size 50M– maksymalny rozmiar przesyłanych plików. n8n może przetwarzać duże pliki w workflow, więc 50 MB to rozsądna wartość. Dostosuj według potrzeb.WebSocket support– n8n używa WebSocket do real-time communication między przeglądarką a serwerem. Nagłówki Upgrade i Connection są kluczowe dla prawidłowego działania interfejsu n8n.proxy_buffering off– wyłącza buforowanie odpowiedzi. Dla aplikacji real-time jak n8n, chcemy natychmiastowego przesyłania danych bez czekania na bufor.location /rest/login,location /rest/,location /webhook/– ta konfiguracje implementują warstwową ochronę rate limiting dla różnych endpointów n8n, gdzie każda lokacja ma limit dopasowany do jej ryzyka i oczekiwanego wzorca użycia:- Endpoint
/rest/loginma najostrzejszą ochronę – tylko 10 żądań na minutę z burst=3, ponieważ to najbardziej wrażliwy punkt ataku. Próby brute-force haseł zawsze zaczynają się właśnie tutaj, więc drastyczne ograniczenie liczby prób logowania z jednego adresu IP skutecznie uniemożliwia automatyczne ataki słownikowe. Burst=3 oznacza że pozwalamy na trzy szybkie próby (np. pomyłka w haśle), ale potem limit jest bezwzględny. - Ogólne API
/rest/dostaje umiarkowany limit 100 żądań na minutę z burst=20. To endpointy do zarządzania workflow, credentials, wykonaniami – normalne użycie generuje umiarkowany ruch, ale nie powinno być setek requestów na minutę z jednego IP. Burst=20 daje elastyczność dla legalnych operacji które mogą generować serię requestów, ale powstrzymuje nadużycia. - Webhooks
/webhook/mają ten sam rate (100/min) ale znacznie wyższy burst=50, ponieważ zewnętrzne systemy często wysyłają serie webhooków naraz – na przykład przy synchronizacji danych czy po jakimś wydarzeniu które triggeruje wiele workflow jednocześnie. Wysoki burst pozwala na te legalne szczyty ruchu, ale base rate wciąż chroni przed zalewaniem serwera. - Wszystkie lokacje używają nodelay co oznacza że nadmiarowe requesty są natychmiast odrzucane z kodem 429 (Too Many Requests), zamiast być kolejkowane. Headery
proxy_set_headerzapewniają że n8n widzi prawdziwy adres IP klienta (nie IP Nginx) i wie że połączenie przyszło przez HTTPS, co jest ważne dla logów i funkcji bezpieczeństwa n8n.
- Endpoint
To podejście daje nam precyzyjną kontrolę – najbardziej chronimy to co najważniejsze (login), ale nie blokujemy legalnego użycia API i webhooks.
Następnie sprawdzamy konfigurację Nginx i przeładowujemy:
nginx -t
service nginx reload
Uruchomienie n8n
Na tym etapie konfiguracji mamy już zainstalowany i skonfigurowane n8n wraz z obsługą Redis, Nginx jako reverse proxy oraz certyfikat SSL dla domeny pod którą pracuje aplikacja.
Uruchamiamy więc n8n:
service n8n start
Sprawdzenie statusu n8n i ew. również logów:
service n8n status
tail -f /var/log/n8n.log
Aby zweryfikować poprawność instalacji n8n, otwieramy przeglądarkę i przechodzimy do https://NAZWA_TWOJEJ_DOMENY. Powinniśmy mieć dostęp do ekranu tworzenia nowego konta w naszej instancji n8n.
Możemy też oczywiście sprawdzić procesy:
ps aux | grep n8n | grep -v grep
Przykładowy wynik:
n8n 67193 43.8 12.2 8351532 507744 - S 22:03 0:00.05 node /usr/local/bin/n8n start root 67192 0.0 0.1 14380 2708 - S 22:03 0:00.00 su -m n8n -c cd /home/n8n && HOME=/home/n8n PATH=/usr/local/bin:/usr/bin:/bin /usr/local/bin/n8n start
Tu mała uwaga. Widzimy dwa procesy i jest to standardowe podejście!
Proces root 67192 to proces wrapper który zmienia użytkownika z root na n8n. Musi pozostać uruchomiony, ponieważ jest rodzicem procesu n8n oraz zarządza środowiskiem i przekazuje sygnały.
Proces n8n 67193 to faktyczny proces n8n. Działa jako użytkownik n8n (bezpieczeństwo!) i jest procesem potomnym procesu su.
Możemy również zweryfikować, który proces faktycznie nasłuchuje, wydając polecenie:
sockstat -l | grep 5678n8n node 67193 15 tcp46 *:5678 *:*
Jeśli zależy nam, by mieć tylko jeden proces, możemy to osiągnąć używając sudo zamiast su, ale wymaga to dodatkowej konfiguracji, a obecne rozwiązanie jest prostsze i działa dobrze.
Przykładowy workflow n8n uruchomiony na serwerze FreeBSD weryfikujący poprawność naszej instalacji.
Optymalizacja n8n dzięki Redis i Queue Mode
Po podstawowej instalacji możemy znacząco zwiększyć wydajność n8n, konfigurując Redis do pracy z n8n w trybie Queue Mode. To opcjonalna, ale zalecana optymalizacja dla środowisk produkcyjnych.
Queue Mode to tryb pracy n8n, w którym workflow nie są wykonywane bezpośrednio w głównym procesie, ale trafiają do kolejki zadań zarządzanej przez Redis (biblioteka Bull Queue). W innym razie zadania są jedynie kolejkowane do czasu dostępności zasobów.
Korzyści Queue Mode w n8n:
1. Lepsza skalowalność
- Możliwość uruchomienia wielu workerów
- Równoległe wykonywanie workflow na różnych serwerach
- Skalowanie horyzontalne (dodawanie nowych instancji workerów)
2. Większa niezawodność
- Izolacja wykonań – awaria jednego workflow nie zabija głównego procesu
- Automatyczny restart workera przy błędach
- Persystencja kolejki – workflow nie giną przy restarcie
3. Lepsza wydajność
- Główny proces obsługuje tylko UI i API
- Workery skupiają się tylko na wykonywaniu workflow
- Możliwość priorytetyzacji zadań
4. Zaawansowane funkcje
- Scheduled jobs z precyzyjnym czasem
- Rate limiting wykonań
- Monitoring kolejki w czasie rzeczywistym
Konfiguracja Queue Mode
Edytujemy główny plik konfiguracyjny n8n, czyli /home/n8n/.n8n/.env i dodajemy następujące zmienne na końcu pliku:
# REDIS QUEUE MODE
# Włączenie trybu kolejkowania - KLUCZOWE!
EXECUTIONS_MODE=queue
# Konfiguracja Redis Queue
QUEUE_BULL_REDIS_HOST=localhost
QUEUE_BULL_REDIS_PORT=6379
QUEUE_BULL_REDIS_DB=0
QUEUE_HEALTH_CHECK_ACTIVE=true
QUEUE_RECOVERY_INTERVAL=60
# OPCJONALNE USTAWIENIA KOLEJKI
# Liczba worker procesów (domyślnie 1)
N8N_WORKERS=2
# Timeout dla zadań w kolejce (sekundy)
# QUEUE_WORKER_TIMEOUT=60Wyjaśnienie kluczowych zmiennych:
EXECUTIONS_MODE=queue– NAJWAŻNIEJSZE USTAWIENIE! Przełącza n8n z trybu regular na queue mode. Bez tego wszystkie pozostałe ustawienia kolejki są ignorowane.QUEUE_BULL_REDIS_DB=0– numer bazy danych Redis dla kolejki. Redis pozwala na 16 oddzielnych baz danych (0-15) w jednej instancji. Używamy osobnych baz dla kolejki i cache dla lepszej izolacji. (CACHE_REDIS_DB=1ustwiliśmy już wcześniej, to osobna baza Redis dla cache, inna niż kolejka = DB 0, zapewnia, że operacje cache nie wpływają na wydajność kolejki).QUEUE_HEALTH_CHECK_ACTIVE=true– włącza okresowe sprawdzanie zdrowia kolejki. n8n będzie monitorował, czy Redis jest dostępny i czy kolejka działa poprawnie.QUEUE_RECOVERY_INTERVAL=60– co 60 sekund n8n sprawdza, czy są “utknięte” zadania w kolejce (np. po awarii worker) i próbuje je odzyskać.N8N_WORKERS– liczba procesów worker do uruchamiania. Pozostaw zakomentowane dla standardowej instalacji (1 worker wystarczy). Dla większych instalacji możesz zwiększyć do 2-4.
Po dodaniu konfiguracji Queue Mode w n8n restartujemy usługę n8n:
service n8n restart
Weryfikacja Queue Mode
Poniżej kilka metod na sprawdzenie czy n8n rzeczywiście używa Redis w trybie queue.
- Dostępność biblioteki Bull:
ls -d /usr/local/lib/node_modules/n8n/node_modules/*bull* 2>/dev/nulldrwxr-xr-x 4 root wheel 512B Nov 12 17:10 /usr/local/lib/node_modules/n8n/node_modules/bull
npm list --prefix /usr/local/lib/node_modules/n8n bull 2>&1 | head -20n8n@1.119.1 /usr/local/lib/node_modules/n8n ├─┬ @rudderstack/rudder-sdk-node@2.1.4 │ └── bull@4.16.4 deduped └── bull@4.16.4
- Lista parametrów wczytanych do n8n:
PID=$(ps aux | grep "node.*n8n" | grep -v grep | awk '{print $2}')
echo "n8n PID: $PID"n8n PID: 67588
ps eww $PID | tr ' ' '\n' | grep -i "redis\|queue\|bull\|executions_mode"CACHE_REDIS_HOST=localhost QUEUE_BULL_REDIS_PORT=6379 CACHE_REDIS_DB=1 QUEUE_BULL_REDIS_DB=0 QUEUE_BULL_REDIS_HOST=localhost CACHE_REDIS_PORT=6379 QUEUE_RECOVERY_INTERVAL=60 QUEUE_HEALTH_CHECK_ACTIVE=true EXECUTIONS_MODE=queue
- Aktywne połączenia Redis:
redis-cli client list
- Klucze kolejki Bull:
redis-cli keys "bull:*"
- Lista zadań w kolejce:
redis-cli llen "bull:n8n:wait"
redis-cli llen "bull:n8n:active"
redis-cli llen "bull:n8n:completed"
- Monitorowanie Redis w czasie rzeczywistym:
redis-cli monitor
Wykonując jakąkolwiek operację w n8n, powniśmy zobaczyć aktywność w Redis, jak poniżej:
OK 1762987961.730924 [0 127.0.0.1:49304] "get" "n8n:cache:variables" 1762987961.730951 [0 127.0.0.1:49304] "hget" "n8n:cache:workflow-project" "kJ0kaWZlHa3KwcWw" 1762987961.747233 [0 127.0.0.1:49304] "hget" "n8n:cache:workflow-project" "kJ0kaWZlHa3KwcWw" 1762987961.748456 [0 127.0.0.1:49304] "hget" "n8n:cache:project-owner" "aepvBToOYsssARgi" 1762987961.750307 [0 127.0.0.1:49304] "get" "n8n:cache:variables" 1762987961.750322 [0 127.0.0.1:49304] "hget" "n8n:cache:workflow-project" "kJ0kaWZlHa3KwcWw" 1762987971.013431 [0 127.0.0.1:49304] "get" "n8n:cache:variables" 1762987971.013536 [0 127.0.0.1:49304] "hget" "n8n:cache:workflow-project" "kJ0kaWZlHa3KwcWw" 1762987971.028417 [0 127.0.0.1:49304] "hget" "n8n:cache:workflow-project" "kJ0kaWZlHa3KwcWw" 1762987971.028977 [0 127.0.0.1:49304] "hget" "n8n:cache:project-owner" "aepvBToOYsssARgi" 1762987971.030609 [0 127.0.0.1:49304] "get" "n8n:cache:variables" 1762987971.030617 [0 127.0.0.1:49304] "hget" "n8n:cache:workflow-project" "kJ0kaWZlHa3KwcWw" 1762987976.797001 [0 127.0.0.1:49304] "get" "n8n:cache:variables" 1762987976.797039 [0 127.0.0.1:49304] "hget" "n8n:cache:workflow-project" "kJ0kaWZlHa3KwcWw"
Monitoring wydajności n8n z Queue Mode
Po włączeniu Queue Mode w n8n, możemy również monitorować jego wydajność. Poniżej kilka metod:
- Statystyki Redis:
redis-cli info stats
- Wykorzystanie pamięci:
redis-cli info memory
- Sprawdzenie liczby zadań w różnych stanach:
# Oczekujące
redis-cli llen "bull:n8n:wait"
# W trakcie wykonywania
redis-cli llen "bull:n8n:active"
# Zakończone
redis-cli llen "bull:n8n:completed"
# Nieudane
redis-cli llen "bull:n8n:failed"
Dodatkowa optymalizacja n8n i FreeBSD
Po skonfigurowaniu Queue Mode, możemy również dodać kilka zaawansowanych optymalizacji dla maksymalnej wydajności naszej instalacji.
Zaawansowana optymalizacja n8n
W tym celu edytujemy plik /home/n8n/.n8n/.env i dodajemy na końcu dodatkowe zmienne optymalizacyjne:
# ZAAWANSOWANE OPTYMALIZACJE
# Zwiększenie limitów payload
N8N_PAYLOAD_SIZE_MAX=16
N8N_DEFAULT_BINARY_DATA_MODE=filesystem
# Funkcje Node.js (code nodes)
NODE_FUNCTION_ALLOW_BUILTIN=*
NODE_FUNCTION_ALLOW_EXTERNAL=*
# Optymalizacja wykonań workflow
EXECUTIONS_TIMEOUT=3600
EXECUTIONS_TIMEOUT_MAX=7200
# Metryki i monitoring
N8N_METRICS=true
N8N_METRICS_PREFIX=n8n_
# Optymalizacja połączeń
N8N_SKIP_WEBHOOK_DEREGISTRATION_SHUTDOWN=true
# Ustawienia bazy danych (SQLite optimization)
DB_SQLITE_VACUUM_ON_STARTUP=true
DB_SQLITE_ENABLE_WAL=true
# Push notifications dla UI
N8N_PUSH_BACKEND=websocket
# Diagnostyka (wyłącz w produkcji jeśli nie potrzebujesz)
N8N_DIAGNOSTICS_ENABLED=false
N8N_VERSION_NOTIFICATIONS_ENABLED=trueOmówienie zmiennych:
N8N_PAYLOAD_SIZE_MAX=16– maksymalny rozmiar danych przekazywanych między węzłami workflow w MB. Domyślnie to 4 MB. Zwiększenie do 16 MB pozwala na przetwarzanie większych zbiorów danych bez błędów.N8N_DEFAULT_BINARY_DATA_MODE=filesystem– przechowuje binarne dane (pliki, obrazy) na dysku zamiast w pamięci. To znacząco zmniejsza zużycie RAM przy pracy z dużymi plikami.NODE_FUNCTION_ALLOW_BUILTIN=*– zezwala na użycie wszystkich wbudowanych modułów Node.js w węzłach Function. Zwiększa elastyczność przy tworzeniu custom logic.NODE_FUNCTION_ALLOW_EXTERNAL=*– pozwala na import zewnętrznych pakietów npm w węzłach Function Code. Potężna funkcja dla zaawansowanych użytkowników.EXECUTIONS_TIMEOUT=3600– maksymalny czas wykonania workflow (1 godzina). Zapobiega “zawieszonym” workflow.N8N_METRICS=true– eksportuje metryki w formacie Prometheus na /metrics. Niezbędne do monitorowania z Prometheus/Grafana.DB_SQLITE_ENABLE_WAL=true– włącza Write-Ahead Logging dla SQLite. Znacząco poprawia wydajność przy współbieżnych operacjach.N8N_PUSH_BACKEND=websocket– używa WebSocket do komunikacji real-time między serwerem a UI. Szybszy niż SSE.
Oczywiście po wprowadzeniu zmian, uruchamiamy ponownie n8n:
service n8n restart
Weryfikacja limitów systemu FreeBSD dla użytkownika n8n
Domyślna instalacja FreeBSD nie nakłada limitów na zasoby systemowe dostępne dla użytkowników. Warto to jednak zweryfikować:
grep -A 30 "^default:" /etc/login.conf | grep -E "openfiles|maxproc|cputime|memoryuse":cputime=unlimited:\ :memoryuse=unlimited:\ :openfiles=unlimited:\ :maxproc=unlimited:\ :vmemoryuse=unlimited:\
Jeśli jednak z jakiegoś powodu instalacja FreeBSD ma zmodyfikowane limity, możemy je przywrócić do unlimited lub utworzyć dedykowaną klasę dla użytkownika n8n edytując plik /etc/login.conf:
# Plik: /etc/login.conf
n8n:\
:cputime=unlimited:\
:memoryuse=unlimited:\
:openfiles=unlimited:\
:maxproc=unlimited:\
:vmemoryuse=unlimited:\
:tc=default:W praktyce “unlimited” nie oznacza dosłownie braku limitów. Wciąż obowiązują ogólnosystemowe limity jądra (sysctl). To jednak najlepsze podejście dla usług produkcyjnych, pozwalające aplikacji używać tylu zasobów, ile potrzebuje, w ramach możliwości systemu.
Po zmianach musimy przebudować bazę danych login konwertując plik tekstowy login.conf do binarnego formatu używanego przez system:
cap_mkdb /etc/login.confNastępnie przypisujemy nowododaną klasę n8n do użytkownika n8n:
pw usermod n8n -L n8n
Aby sprawdzić aktualne limity dla działającego procesu n8n wykonujemy poniższe polecenie:
limits -P $(ps aux | grep '[n]8n' | awk '{print $2}')Przykładowy wynik:
Resource limits (current): cputime infinity secs filesize infinity kB datasize 33554432 kB stacksize 524288 kB coredumpsize infinity kB memoryuse infinity kB memorylocked infinity kB maxprocesses 8499 openfiles 116964 sbsize infinity bytes vmemoryuse infinity kB pseudo-terminals infinity swapuse infinity kB kqueues infinity umtxp infinity pipebuf infinity kB
Diagnostyka i przydatne polecenia
Sprawdzenie stanu Redis
redis-cli info stats
Sprawdzenie długości kolejki Redis
redis-cli llen bull:n8n:jobs:waiting
Test wydajności Redis
redis-cli --latency
Restarty wszystkich usług
service n8n restart
service nginx restart
service redis restart
service pf restart
Statusy wszystkich usług
service n8n status
service nginx status
service redis status
service pf status
Podsumowanie
W przewodniku starałem się przedstawić wszystkie niezbędne kroki i informacje pozwalające uruchomić w pełni funkcjonalne, bezpieczne i zoptymalizowane środowisko n8n na FreeBSD. Z identycznej konfiguracji korzystam na co dzień. Instalacja spełnia standardy produkcyjne i jest gotowa do obsługi zadań biznesowych.
Kluczowe cechy prezentownego rozwiązania
Bezpieczeństwo
- Firewall PF z rate limiting i automatycznym blokowaniem ataków
- Szyfrowanie SSL/TLS z nowoczesnymi algorytmami (TLS 1.3)
- Dedykowany użytkownik systemowy z ograniczonymi uprawnieniami
- Wielowarstwowe uwierzytelnianie (Nginx + n8n)
- Security headers chroniące przed XSS, clickjacking i innymi atakami
- Nginx z Rate Limiting Zones
Wysoka dostępność
- Automatyczne restarty usługi w przypadku awarii
- Health checks i monitoring kolejki
- Łatwe przywracanie do poprzednich stanów
Wydajność
- Redis cache dla szybkiego dostępu do danych
- Optymalizowane limity systemowe
- Wydajne kolejkowanie zadań
Łatwość zarządzania dzięki FreeBSD
- Scentralizowane logi w jednym miejscu
- Proste komendy service dla wszystkich komponentów
- Automatyczne odnawienie certyfikatów
- Jasna struktura plików konfiguracyjnych
Chętnie odpowiem na pytania w komentarzu.
