n8n self-hosted: kiedy, po co, na czym.

Co oznacza self-hosted w kontekście n8n

Self-hosted n8n to instalacja serwera n8n na infrastrukturze, którą kontrolujesz Ty albo Twój dostawca (GCP, AWS, Hetzner, on-prem). Pracuje jako proces Node.js z bazą PostgreSQL i opcjonalnie Redisem jako kolejką execution. W przeciwieństwie do n8n Cloud, gdzie n8n.io zajmuje się uruchomieniem i aktualizacjami, przy self-hosted zarządzasz stackiem sam lub oddajesz komuś (mnie, DevOpsowi, managed providerowi).

Rozróżnienie formalne: n8n Cloud to SaaS z miesięczną subskrypcją i hostem dostawcy. n8n self-hosted (community edition) jest darmowy, open-source, ale wymaga infrastruktury i utrzymania. n8n Enterprise self-hosted to wersja z dodatkami (SSO, environments, audit logs), licencja płatna ale hosting nadal u Ciebie.

Kiedy self-hosted ma sens

Trzy scenariusze, w których polecam self-hosted bez zastanowienia:

• RODO-sensitive dane: jeśli workflow przepuszczają dane osobowe, medyczne albo finansowe, potrzebujesz fizycznej kontroli nad miejscem przechowywania i jurysdykcją. Cloud rozwiązuje to częściowo (n8n Cloud EU region), ale self-hosted na Twoim GCP europe-west4 daje Ci pełny audit trail i umowę powierzenia jedynie z dostawcą chmury, nie z n8n.io.
• Integracje z systemami on-prem albo private network: jeśli musisz sięgnąć do CRM-a klienta zamkniętego w VPN, do ERP-a dostępnego tylko z konkretnego IP, albo do pgSQL za firewallem, self-hosted w tym samym VPC rozwiązuje to natywnie. Cloud wymaga VPN tunnel albo publicznego exposure z whitelistą IP.
• Workflow'y wysokowolumenowe: przy tysiącach execution dziennie cennik n8n Cloud per-execution robi się zauważalnie drogi. Self-hosted na VPS za 200 PLN miesięcznie obsłuży wolumeny, które w Cloud kosztowałyby kilka tysięcy PLN.

Dwa scenariusze, w których self-hosted nie ma sensu (i rekomenduję Cloud):

• Startup, który testuje pomysł: dopóki nie wiadomo czy workflow przetrwa miesiąc, n8n Cloud Starter (kilkadziesiąt PLN miesięcznie) jest znacznie tańszy niż koszt postawienia i utrzymania własnej infra.
• Brak kompetencji DevOps po stronie klienta: self-hosted to nie tylko setup. Potrzeba kogoś, kto ogarnie aktualizacje (co 2-4 tygodnie nowy release), backup, monitoring, rotację sekretów. Bez tej osoby wdrożenie rozsypuje się w ciągu roku.

Jak wygląda setup produkcyjny

Minimalny zestaw, który stawiam u klienta, ma cztery elementy uruchamiane przez Docker Compose:

• n8n: sam serwer aplikacji, jeden kontener dla web UI i executions (albo osobny n8n-worker jeśli wolumen uzasadnia rozdzielenie).
• PostgreSQL: baza dla workflow'ów, credentials (szyfrowane), execution history.
• Redis: opcjonalnie, ale zalecany przy wyższych wolumenach jako queue dla n8n-worker.
• Caddy: reverse proxy z automatycznym TLS przez Let's Encrypt, blokada dotfiles, rate limiting, nagłówki bezpieczeństwa.

Deployment przez CI/CD (GitLab CI albo podobny tool): push na gałąź main triggeruje build obrazu (jeśli mamy custom node'y), push na registry i SSH deploy na VPS. Aktualizacja bazy i migracje n8n są zautomatyzowane, rollback wymaga ręcznej decyzji (bo zwykle chcesz zobaczyć co się zepsuło zanim cofniesz).

Co musisz ogarnąć po handoff'ie

Po wdrożeniu dostajesz run-book (dokumentację operacyjną) z listą zadań, które musi ktoś po Twojej stronie trzymać na radarze. Listowo od najczęstszych:

• Aktualizacje n8n: nowy release co 2-4 tygodnie, semver patch zwykle bezpieczny, minor release wymaga 15 minut testów. Automatyzuję to przez watchtower z flagą "poll-interval=168h" (raz w tygodniu), plus manualny release check co miesiąc.
• Backup bazy i credentials: pg_dump codziennie do Cloud Storage, retencja 30 dni, test restore raz na kwartał. Bez testu restore backup jest niepotwierdzoną obietnicą.
• Monitoring execution failures: workflow, który miał być cichy (np. nocna synchronizacja), musi wysłać alert gdy failuje dwa razy z rzędu. Podpinam Prometheus + Alertmanager albo Sentry, zależy od preferencji klienta.
• Rotacja sekretów: API keys do Resend, Allegro, Google OAuth, klucze SSH. Planuje się rotację co 6-12 miesięcy, automatyka opiera się o Secret Manager, a nie hard-coded w .env.
• Review workflow 2 razy w roku: po 6 i 12 miesiącach sprawdzam, które workflow'y faktycznie są używane, które padają coraz częściej, które wymagają migracji do nowszej wersji node'ów.

Jeśli w Twoim zespole nie ma osoby, która to weźmie na klatę, dopisujemy support miesięczny do kontraktu wdrożeniowego. Bez tego w horyzoncie 12-18 miesięcy wdrożenie degraduje się do stanu "działa, ale nikt nie wie jak".

Kiedy self-hosted przestaje wystarczać

Self-hosted skaluje się dobrze do kilkunastu tysięcy executions dziennie na pojedynczym hoście. Gdy wolumen rośnie powyżej, a dodatkowo poszczególne workflow'y są długie (LLM calls, OCR, integracje synchroniczne z wolnymi API), skalujemy horyzontalnie. Trzy techniki:

• Worker nodes: n8n main trzyma UI i scheduler, ale executions idą do worker'ów przez Redis queue. Dodajesz worker'y według potrzeb, każdy obrabiający swoją kolejkę.
• Queue mode z priorytetami: szybkie workflow'y (sub-second) idą do priority queue, długie (OCR, LLM) do osobnej. Zapobiega temu, że długie zadania blokują szybkie.
• Cache execution results: jeśli workflow często odpytuje to samo API (np. o kursy walut, statusy faktur), cache w Redisie z TTL 5-60 minut potrafi odjąć 30-80 procent wywołań zewnętrznych.

Powyżej skali, gdzie scale-out n8n robi się wąskim gardłem (kilkadziesiąt tysięcy executions na godzinę, workflow'y z wieloma etapami per execution), rozważam migrację krytycznych pipeline'ów do dedicated orchestratorów (Apache Airflow, Temporal, Dagster). Nie jako zastępstwo całego n8n, tylko dla konkretnych ciężkich flows. Kryterium decyzji: gdy 80 procent wolumenu generuje 5 workflow'ów, które warto wyekstraktować na osobną platformę, n8n zostaje dla pozostałych 95 workflow'ów.

Typowe pułapki self-hosted

Rzeczy, które wielu klientów odkrywa dopiero po kilku miesiącach:

• Encryption key: n8n szyfruje credentials symetrycznie kluczem z N8N_ENCRYPTION_KEY. Utrata tego klucza oznacza utratę wszystkich credentials (API keys do CRM, SMTP, OAuth tokens). Backup klucza osobno od bazy, w Secret Manager, nigdy nie w repo.
• Timezone w schedulerze: domyślnie n8n używa UTC. Jeśli cron-trigger ma wystartować o 08:00 czasu lokalnego, a deploy jest w UTC, workflow wystartuje o 10:00 (latem) albo 09:00 (zimą). Ustaw GENERIC_TIMEZONE na Europe/Warsaw przy deploy, ale pamiętaj, że nie każdy node node'ów honoruje tę zmienną.
• Session secret nie jest domyślnie ustawiony: n8n generuje go losowo, ale jeśli nie zapiszesz go na stałe, restart kontenera wyloguje wszystkich użytkowników UI. Ustaw N8N_USER_MANAGEMENT_JWT_SECRET wyraźnie.
• Webhook URL-e zmieniają się przy restart: webhooki produkcyjne (których URL znają zewnętrzne systemy) nie powinny używać ścieżek z UUID n8n. Używaj Caddy rewrite'u z własnej domeny (na przykład /api/crm-push → /webhook/wf-crm-push) tak, żeby URL dla zewnętrznego systemu był stabilny nawet po migracji workflow.

Najczęstsze pytania

Co warto przeczytać obok