Wymagania serwera n8n

Ile maszyny naprawdę potrzebuje samodzielnie hostowana instancja n8n, co dokłada baza danych i moment, w którym jedna instancja przestaje wystarczać. Większość poradników dotyczących rozmiaru, jakie znajdziesz w sieci, pisana jest pod tryb kolejki, z którego większość ludzi nigdy nie korzysta, więc wygląda na dużo większe wymaganie, niż jest w rzeczywistości.

Krótka odpowiedź

Pojedyncza instancja n8n z normalnymi workflowami nie jest zbyt wymagającym oprogramowaniem. Dwa vCPU i 2 GB RAM-u z zapasem poradzą sobie z prawdziwym obciążeniem: zaplanowanymi zadaniami, webhookami i wywołaniami API, ponieważ n8n większość czasu czeka na usługi innych, zamiast coś liczyć. Sam główny proces n8n zajmuje w spoczynku około 300 MB.

To, co naprawdę podnosi tę liczbę, to nie to, ile workflow zdefiniowałeś. Chodzi o to, ile danych pojedyncze wykonanie trzyma w pamięci naraz i ile wykonań działa współbieżnie.

Co zużywa pamięć w n8n

n8n przekazuje dane między węzłami jako elementy trzymane w pamięci przez cały czas trwania wykonania. Ma to jedną ważną konsekwencję dla doboru zasobów: workflow, które pobiera dziesięć tysięcy wierszy i przepuszcza je przez pięć węzłów, to dużo cięższy najemca niż sto workflow, z których każde przesyła ładunek webhooka.

  • Rozmiar ładunku na wykonanie. Duże odpowiedzi HTTP, importy arkuszy i pliki binarne to zwykła przyczyna, dla której instancja, która działała, nagle przestaje działać.
  • Współbieżność. Dziesięć wykonań działających jednocześnie zajmuje każde swój zestaw roboczy. Harmonogram, który uruchamia kilka workflow w tej samej minucie, to szczyt, którego nie zaplanowałeś.
  • Historia wykonań. Zapisane dane wykonań narastają w bazie. To pytanie o dysk i bazę, a nie o RAM, ale to właśnie rośnie po cichu przez miesiące, aż zaczyna mieć znaczenie.

Praktyczna konsekwencja: jeśli przetwarzasz duże ładunki, rozdzielaj je. Dzielenie dużego zbioru danych na porcje daje większą stabilność niż jakakolwiek ilość dodatkowego RAM, bo zmienia szczyt zamiast podnosić sufit.

Baza danych jest wymaganiem, a nie optymalizacją

n8n domyślnie używa SQLite, co wystarcza do testów, ale jest kiepskim pomysłem w produkcji. Słabo radzi sobie z równoległymi wykonaniami, a trudno z niego niezawodnie zrobić backup i go przywrócić. PostgreSQL to produkcyjne rozwiązanie, a pod względem zasobów nie jest darmowe: przewidź około 500 MB do 1 GB, rosnące wraz z historią wykonań.

Tę liczbę większość przewodników o rozmiarze po cichu wrzuca do tego samego worka co samo n8n. Na VPS w modelu DIY pochodzi ona z tej samej pamięci RAM co twoje workflow, wraz z runtime kontenerów, reverse proxy i systemem operacyjnym. W naszych planach klaster PostgreSQL jest osobnym komponentem o wysokiej dostępności, z własną pamięcią, więc RAM w nazwie planu to RAM dla n8n.

Plann8nBaza danychOdpowiednie dla
Small, $6.99/mies.1 GB, 2 vCores1 GB HA PostgreSQLOsobiste automatyzacje, webhooki, małe ładunki
Medium, $7.99/mies.2 GB, 2.5 vCores1 GB HA PostgreSQLPrawdziwe środowisko produkcyjne z mieszanymi rozmiarami ładunków
Large, $12.49/mies.4 GB, 4 vCores2 GB HA PostgreSQLWykonania intensywne danymi, większa współbieżność, węzły AI

CPU: zwykle nie jest ograniczeniem

n8n w dużej mierze czeka. Wykonanie spędza czas na rundach sieciowych do API, a nie na obliczeniach, więc dwa rdzenie wystarczą na wiele. Wyjątki są realne, ale konkretne: ciężkie przekształcanie danych w węzłach Code, duże parsowanie JSON i workflow AI wykonujące znaczącą pracę lokalnie, a nie tylko wywołujące model przez API. Jeśli twoje workflow to głównie integracje, dokładaj RAM przed rdzeniami.

Kiedy potrzebujesz trybu kolejki

Domyślnie n8n wykonuje wszystko w jednym procesie. Tryb kolejki to rozdziela: główna instancja przyjmuje wyzwalacze i przekazuje wykonania osobnym procesom workerów przez Redis, dzięki czemu główny proces pozostaje responsywny bez względu na to, jak długo trwa zadanie. To standardowa odpowiedź na skalowanie n8n, a także powód, dla którego większość publikowanych porad dotyczących rozmiaru brzmi tak ciężko.

Potrzebujesz go, gdy spełniony jest któryś z poniższych warunków, a nie wcześniej:

  • Długie wykonania blokują krótsze. Workflow, które trwa pięć minut, sprawi, że przychodzący webhook będzie czekał za nim w trybie jednego procesu. W trybie kolejki główna instancja od razu potwierdza przyjęcie, a worker wykonuje pracę.
  • Widzisz wyraźne zaległości. Najwyraźniejszym sygnałem są wykonania, które czekają w stanie oczekiwania dłużej niż kilka sekund w interfejsie n8n. To znaczy, że tworzy się kolejka, a żadna ilość dodatkowego RAM w jednym procesie jej nie usunie.
  • Jedno ciężkie zadanie może położyć całą instancję. Izolacja to często prawdziwy powód, a nie przepustowość.

Tryb kolejki dodaje do wymagań dwie rzeczy. Redis, który jest mały, około 128 MB, ale to kolejny komponent do uruchomienia, oraz RAM na każdego workera: każdy proces workera zużywa mniej więcej 200 do 500 MB, zależnie od tego, co niosą twoje workflow. Dwa workery to rozsądny punkt startowy, a dodajesz więcej dopiero wtedy, gdy wskazują na to zaległości. Workery potrzebują RAM znacznie bardziej niż rdzeni, dlatego typowa ścieżka skalowania dokłada pamięć dwa lub trzy razy, zanim dołoży CPU.

Mówiąc wprost: wdrożenie w trybie kolejki z wieloma workerami wymaga komponentu Redis i większej ilości pamięci, niż oferują wyżej wymienione plany, więc nie na tym polegają te plany. Są to instancje n8n z pojedynczą instancją i bazą o wysokiej dostępności, a to właśnie większość samodzielnie hostowanych instancji. Jeśli zmierzyłeś zaległości i naprawdę potrzebujesz workerów, wyrosłeś poza wdrożenie jednym kliknięciem i powinieneś zaprojektować dedykowany stos.

Pamięć i to, co rośnie

n8n sam potrzebuje bardzo mało miejsca na dysku. Rośnie historia wykonań, a rośnie proporcjonalnie do tego, jak często uruchamiają się workflow, a nie do ich liczby. Workflow odpytujące API co dziesięć minut generuje około 4,300 wykonań miesięcznie. Usuwaj zapisane dane wykonań według polityki retencji, zamiast czekać, aż dysk podejmie decyzję za ciebie, i zachowuj nieudane wykonania dłużej niż udane, bo tylko je kiedykolwiek przeczytasz.

Wymagania, które nie są sprzętem

Dwie z nich liczą się bardziej niż jakakolwiek specyfikacja. Webhooki potrzebują stabilnego publicznego adresu HTTPS, co oznacza prawdziwą domenę, ważny certyfikat i reverse proxy przed n8n. Samodzielnie hostowana instancja bez tego może uruchamiać harmonogramy, ale nic nie odbierze. Platforma automatyzacji musi być dostępna w momencie uruchomienia wyzwalacza, co wyklucza laptopa i czyni dostępność wymaganiem w tym samym sensie co RAM.

Dobierz rozmiar w 30 sekund

Dedykowana instancja n8n z bazą PostgreSQL o wysokiej dostępności i działającymi webhookami HTTPS. Od $6.99/mies., pierwszy tydzień za darmo.

Najczęściej zadawane pytania

How much RAM does n8n need?

Two vCPU and 2 GB comfortably runs a real production workload of scheduled jobs and webhooks, with the n8n main process sitting around 300 MB at rest. What raises the number is payload size per execution and concurrency, not how many workflows you have defined. Add PostgreSQL to that if it shares the same machine, which is another 500 MB to 1 GB.

Does n8n need a lot of CPU?

Usually not. Executions are dominated by waiting on external APIs rather than by computation, so two cores go a long way. Heavy Code-node transformations, large JSON parsing and AI workflows doing local work are the genuine exceptions.

Do I need PostgreSQL for n8n?

For production, yes. SQLite is fine for a trial but handles concurrent executions badly and is awkward to back up and restore reliably. PostgreSQL is the production answer, and on a DIY VPS it takes 500 MB to 1 GB out of the same memory as your workflows.

When should I switch n8n to queue mode?

When long executions start blocking short ones, or when you can see executions waiting more than a few seconds in the n8n UI. That backlog is the signal, and it is not fixed by adding RAM to a single process. Below that point, queue mode adds Redis and worker processes for no benefit.

How much RAM does each n8n worker need?

Roughly 200 to 500 MB each, depending on what your workflows carry, plus about 128 MB for Redis. Start with two workers and add more only when the backlog says so. Workers need memory far more than cores, so the usual upgrade path raises RAM two or three times before it raises CPU.

Can I run n8n on a Raspberry Pi?

The resource requirements are low enough that the hardware is rarely the obstacle. Uptime and a public HTTPS endpoint are. An automation platform has to be reachable when the trigger fires, and webhooks need a stable certificate-backed URL, which is where home hosting usually breaks down rather than at the specification.