n8n na FreeBSD – instalacja, konfiguracja i optymalizacja

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.

 

 

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

 

 

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 ping

Polecenie 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 TTL
  • noeviction – 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

 

 

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 logowania
• rate=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 -e

i 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-run

To 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/login ma 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_header zapewniają ż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.

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 5678

n8n 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.

 

 

 

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=60

Wyjaś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=1 ustwiliś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/null

drwxr-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 -20

n8n@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=true

Omó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.conf

Nastę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.