n8n self-hosted: Jak uruchomić n8n na własnym serwerze – praktyczne pułapki
Coraz więcej firm decyduje się na n8n self-hosted, czyli uruchomienie automatyzacji na własnym serwerze. Taka instalacja daje pełną kontrolę nad danymi i kosztami, ale niesie też kilka pułapek, których nie znajdziesz w oficjalnej dokumentacji. W tym artykule zebrałem konkretne problemy, na które natknąłem się wdrażając n8n u klientów.
Wymagania sprzętowe i środowiskowe dla n8n self-hosted
n8n uruchomisz praktycznie na każdym serwerze z Dockerem i Node.js. W praktyce najwygodniej korzystać z docker-compose, bo pozwala łatwo zarządzać aktualizacjami i restartami. Minimalna konfiguracja to 2 GB RAM – mniej oznacza ryzyko ubijania procesów przy większym obciążeniu. Jeśli planujesz integracje z bazami danych lub AI, rozważ od razu Postgresa jako backend dla n8n.
Pułapki z portami SMTP na serwerach VPS
Jeśli Twój serwer stoi w Hetznerze, miej na uwadze blokadę portów SMTP 25 i 465. Próba wysyłki maili z n8n przez te porty kończy się komunikatem błędu ETIMEDOUT po kilku minutach. Rozwiązanie: korzystaj z portu 587 z włączonym STARTTLS i wyłączoną opcją SSL/TLS w credentialu SMTP. To jedyny sposób, by wiadomości wychodziły bez problemów na nowych serwerach tej firmy.
Credential cache – dlaczego restart n8n jest konieczny
n8n trzyma dane logowania (credentials) w pamięci podręcznej. Po usunięciu i ponownym utworzeniu credentiala, workflow potrafi dalej zgłaszać błąd uwierzytelnienia, mimo że w panelu widzisz połączenie jako aktywne. Pomaga dopiero docker compose restart n8n – dopiero wtedy nowe dane są ładowane do pamięci i błędy znikają.
Licencja n8n Community a hosting dla klientów
Wersja Community n8n pozwala na automatyzację własnych procesów i wdrożenia dla klientów, ale nie na hostowanie workflowów i credentiali wielu klientów na jednej instancji. Jeśli chcesz oferować n8n jako usługę z własnego serwera, potrzebujesz licencji Enterprise. Najbezpieczniej jest wdrażać n8n na serwerze klienta i zapewnić mu utrzymanie – to zgodne z licencją i eliminuje ryzyko naruszeń.
Zabezpieczenie webhooków i pamięć czatu
Webhooki w n8n są otwarte – każdy, kto zna adres, może je wywołać. W praktyce wystarczy dodać nagłówek z tokenem (Header Auth), by ograniczyć ruch tylko do zaufanych źródeł. Jeśli budujesz agenta AI lub chatbota, pamiętaj: domyślna pamięć rozmów znika po restarcie kontenera. Przeniesienie jej do Postgresa rozwiązuje problem utraty kontekstu – kosztuje to jeden dodatkowy node w workflow.
- n8n self-hosted wymaga minimum 2 GB RAM i Docker Compose.
- Na serwerach Hetzner SMTP działa tylko na porcie 587 z STARTTLS.
- Po zmianie credentiala konieczny jest restart n8n.
- Webhook zabezpieczysz prostym nagłówkiem z tokenem.
- Licencja Community nie pozwala hostować workflowów wielu klientów.