n8n self-hosted czy cloud?

TCO w PLN — pełny koszt, nie tylko abonament

Całkowity koszt posiadania (TCO) to nie tylko cena serwera czy abonamentu — to suma pieniędzy i czasu, który ktoś musi poświęcić, żeby system działał niezawodnie. Ceny poniżej to stan na połowę 2026, orientacyjne — kursy walut i cenniki dostawców zmieniają się co kilka miesięcy.

Punkt przecięcia w praktyce: przy kilku tysiącach wykonań miesięcznie różnica jest niewielka. Przy 20 000-40 000+ wykonań miesięcznie self-hosted n8n na VPS za 90 zł/mies. bywa 5-10 razy tańszy niż odpowiadający plan cloud — pod warunkiem, że ktoś realnie ogarnia utrzymanie, a nie tylko "kiedyś to zrobi".

RODO i dane w EU — co naprawdę wymaga self-hostingu

Częsty mit: "RODO wymaga self-hostingu". Nieprawda — RODO wymaga, żeby dane osobowe były przetwarzane zgodnie z przepisami i żeby istniała umowa powierzenia przetwarzania (DPA) z każdym podmiotem, który te dane przetwarza. n8n Cloud oferuje serwery w UE i standardowe DPA — dla większości małych i średnich firm to w pełni wystarczające.

Self-hosting staje się realnym wymogiem w trzech sytuacjach: (1) klient korporacyjny w umowie wprost zastrzega, że dane nie mogą trafiać do infrastruktury podmiotu trzeciego poza kontraktowanym dostawcą; (2) branża z podwyższonymi wymaganiami regulacyjnymi (ochrona zdrowia, finanse, kancelarie prawne), gdzie audytor pyta o dokładną lokalizację i kontrolę nad serwerem; (3) przetwarzasz dane szczególnie wrażliwe (zdrowotne, biometryczne) w wolumenie, przy którym każda dodatkowa strona w łańcuchu przetwarzania zwiększa ryzyko.

Poza tymi przypadkami wybór self-hosted vs cloud pod kątem RODO to głównie kwestia tego, jak łatwo chcesz móc odpowiedzieć na pytanie "gdzie dokładnie leżą nasze dane" podczas audytu — self-hosted daje odpowiedź jednym zdaniem, cloud wymaga sprawdzenia dokumentacji dostawcy.

Aktualizacje i kopie zapasowe — codzienność, nie jednorazowy koszt

Self-hosted n8n trzeba aktualizować samodzielnie. Nowe wersje pojawiają się regularnie — część aktualizacji to poprawki bezpieczeństwa, których nie warto odkładać. Bez automatyzacji tego procesu (np. prostym skryptem uruchamianym cyklicznie) realistycznie ktoś musi o tym pamiętać raz na 2-4 tygodnie. Zaniedbany serwer z nieaktualizowanym n8n to nie tylko ryzyko bezpieczeństwa, ale też brak nowych funkcji i węzłów integracji.

Kopie zapasowe przy self-hostingu też są Twoją odpowiedzialnością — snapshoty VPS albo eksport workflow do repozytorium. To 30 minut konfiguracji na starcie, ale bez tego jedna awaria dysku kasuje miesiące pracy. Cloud ma to wliczone w cenę — to jeden z powodów, dla których dla firm bez własnego IT cloud bywa tańszy "naprawdę", nawet przy wyższym abonamencie.

Kiedy cloud wygrywa mimo wyższej ceny nominalnej

Cloud jest lepszym wyborem, gdy: potrzebujesz działającej automatyzacji w tym tygodniu, nie w tym miesiącu; nie masz nikogo (własnego lub zewnętrznego), kto zajmie się serwerem na bieżąco; liczba wykonań mieści się wygodnie w niższych planach (do kilku tysięcy miesięcznie); priorytetem jest przewidywalność — brak niespodzianek typu "serwer padł w piątek wieczorem".

Krótko: cena VPS jest niższa na papierze, ale "papierowa" oszczędność znika, jeśli nikt nie pilnuje aktualizacji i kopii. Cloud kupuje spokój — to ma realną wartość, szczególnie w pierwszych miesiącach, gdy dopiero uczysz się, ile automatyzacji faktycznie potrzebujesz.

Konkretna rekomendacja per wielkość firmy

• Jednoosobowa działalność / mikrofirma (1-5 automatyzacji): cloud. Koszt utrzymania własnego serwera przewyższa oszczędność, a czas lepiej spędzić na obsłudze klientów.
• Mała firma (10-30 pracowników, kilka-kilkanaście workflow): zależy od wolumenu. Do ok. 10 000 wykonań miesięcznie — cloud (Starter/Pro). Powyżej — self-hosted zaczyna się opłacać, jeśli macie wykonawcę na utrzymanie.
• Średnia firma (30-100+ pracowników, duży wolumen, integracje z kilkoma systemami): self-hosted, najlepiej z umową na utrzymanie u zewnętrznego wykonawcy. Kontrola nad danymi i przewidywalny koszt niezależny od skali wygrywają przy tej wielkości.
• Firma z wymogiem regulacyjnym lub kontraktowym co do lokalizacji danych: self-hosted na serwerze w Polsce/UE, niezależnie od wielkości — to nie jest decyzja kosztowa, tylko wymóg zgodności.

U klientów, którym wdrażamy automatyzacje, migracja z cloud na self-hosted zwykle następuje naturalnie — firma zaczyna od cloud, żeby szybko przetestować, czy automatyzacja się sprawdza, a po 3-6 miesiącach, gdy liczba workflow rośnie, przenosimy na własny serwer bez przerywania działania procesów. To bezpieczniejsza ścieżka niż decydować się na self-hosting od pierwszego dnia, zanim wiadomo, ile automatyzacji firma faktycznie będzie potrzebować.

Jak wygląda sama migracja z cloud na self-hosted

Workflow zbudowane w n8n Cloud eksportuje się jako pliki JSON i importuje bez zmian na własnej instalacji — samą logikę automatyzacji przenosisz jeden do jednego. Prawdziwa praca to strona serwerowa: postawienie VPS, konfiguracja bazy danych, certyfikat SSL, podpięcie tych samych kont API (CRM, poczta, systemy zewnętrzne) i test każdego workflow po kolei, zanim wyłączysz starą wersję w chmurze.

Typowe okno migracji dla 10-15 workflow to 1-2 dni robocze, robione równolegle do działającej wersji w chmurze — przełączasz się dopiero, gdy nowa instalacja przejdzie te same testy co produkcja. Ryzyko przestoju przy takim podejściu jest minimalne, bo w każdej chwili możesz wrócić do cloud, dopóki self-hosted nie udowodni, że działa stabilnie przez kilka dni.

Jedna rzecz, o którą trzeba zadbać przed migracją: harmonogram testowania kopii zapasowych. Sama kopia bez sprawdzonego przywracania to fałszywe poczucie bezpieczeństwa — raz na kwartał warto realnie odtworzyć środowisko z backupu, żeby wiedzieć, że w razie awarii serwera odzyskanie zajmie godziny, nie dni.