Ile RAM potrzebuje n8n? Realne liczby z naszych automatyzacji i jak nie przepłacać za serwer

Samo n8n jest lekkie. Pamięć zjadają dane, które przepuszczasz przez workflow, oraz rzeczy, które stawiasz obok n8n na tym samym serwerze: bazę danych, przeglądarkę do scrapingu albo lokalny model AI.

| Scenariusz | RAM serwera | Dla kogo |
| --- | --- | --- |
| n8n + SQLite, kilka prostych workflow | 1 GB + 2 GB swap | Test, hobby, pojedyncze powiadomienia |
| n8n + PostgreSQL, kilkanaście–kilkadziesiąt workflow, AI przez API | 2 GB | Większość małych firm i blogów (nasz profil obciążenia) |
| Jak wyżej + scraping dużych stron, obróbka plików, równoległe wykonania | 4 GB | Sklepy, agregatory, większe potoki danych |
| n8n + lokalny model AI (Ollama, ComfyUI) na tej samej maszynie | 16 GB i więcej | Tu płacisz za model, nie za n8n |

Jeśli nie wiesz, od czego zacząć: 2 GB RAM, PostgreSQL, swap 2 GB i limity opisane w sekcji 6. Większy serwer kupuj dopiero wtedy, gdy pomiar (sekcja 5) pokaże, że go potrzebujesz.

> Punkt odniesienia z dokumentacji n8n

> Najmniejszy plan n8n Cloud działa na 320 MiB RAM, a dokumentacja podaje, że samo oprogramowanie zużywa średnio około 180 MiB. Wyższe plany mają 640 MiB, 1280 MiB i 4096 MiB. Producent sprzedaje produkcyjne n8n na mniej niż 1 GB pamięci.

Poniższe dane pochodzą z instancji n8n, która zasila stronę Wiadomości i nasz fanpage. Odczyt z API n8n: 2 listopada 2026 r., okres 7 dni.

| Parametr | Wartość |
| --- | --- |
| Workflow w instancji | 63, w tym 9 aktywnych |
| Węzłów w aktywnym workflow | mediana 23, największy 62 |
| Wykonań w 7 dni | 123 (ok. 18 dziennie), 116 udanych, 6 błędów |
| Najwięcej wykonań w ciągu godziny | 15 |
| Mediana czasu wykonania | ok. 3 minuty (czekanie na API i model AI) |
| Najdłuższe wykonania | ok. 50 minut (workflow czekające na zewnętrzne zadania, m.in. generowanie grafik) |
| Najcięższe wykonanie | ok. 44 MB danych JSON (scraper cenników dostawców) |
| Typowe wykonanie newsowe | ok. 2 MB danych |

Co robią te workflow: czytają kanały RSS, wybierają i streszczają newsy przez DeepSeek API, publikują posty na Facebooku, zapisują pliki JSON przez FTP, generują grafiki w ComfyUI, konwertują je do WebP i co tydzień przygotowują raport SEO. Najczęściej używane węzły to Code (55), HTTP Request (27), IF (22) i Google Sheets (16).

Czego te liczby uczą

• 18 wykonań dziennie to bardzo mało. Nawet „pracowita” automatyzacja treści przez większość doby nic nie robi. RAM jest potrzebny w krótkich szczytach, a nie stale.
• Długie wykonanie nie znaczy ciężkie. Workflow, który przez 50 minut czeka na model AI, prawie nie zajmuje pamięci n8n. Węzeł Wait dłuższy niż ok. 65 sekund zapisuje stan do bazy i zwalnia wykonanie z pamięci.
• O szczycie decyduje jeden workflow. Scraper, który ściąga 44 MB JSON-a, potrzebuje więcej RAM-u niż wszystkie pozostałe razem. Dane zajmują w pamięci silnika JavaScript wielokrotnie więcej niż na dysku, a każdy węzeł trzyma swoją kopię wyniku.

Dokumentacja n8n wymienia pięć czynników, które zwiększają zużycie pamięci. Przy każdym dopisaliśmy, jak to wygląda w praktyce.

| Czynnik | Co się dzieje | Przykład z naszych workflow |
| --- | --- | --- |
| Ilość danych JSON | Każdy węzeł trzyma swój wynik do końca wykonania | Scraper cenników: 44 MB w jednym wykonaniu |
| Pliki binarne | W trybie domyślnym obraz lub PDF siedzi w RAM | Grafika z ComfyUI ok. 1 MB przed konwersją do WebP (51 kB po) |
| Liczba węzłów | Więcej węzłów = więcej kopii pośrednich wyników | Największy workflow ma 62 węzły |
| Węzeł Code | Kod JavaScript tworzy własne obiekty i kopie tablic | 55 węzłów Code w aktywnych workflow |
| Ręczne uruchomienia | Edytor dostaje pełne dane każdego węzła | Test scrapera z edytora potrafi zużyć więcej niż przebieg z harmonogramu |

Do tego dochodzi równoległość: dwa ciężkie workflow uruchomione o tej samej minucie sumują swoje szczyty. U nas harmonogramy są rozłożone w czasie, dlatego 15 wykonań w godzinie nie przekłada się na 15 jednoczesnych szczytów.

Co stoi obok n8n i ile to kosztuje pamięci

• PostgreSQL przy małej instancji zwykle mieści się w kilkuset MB. SQLite nie ma osobnego procesu, ale słabiej znosi równoległe zapisy.
• Redis jest potrzebny dopiero w trybie kolejki (queue mode) z osobnymi workerami. Małej instancji nie jest potrzebny.
• Przeglądarka do scrapingu (Puppeteer, Browserless, Playwright) to zwykle kilkaset MB na każdą otwartą kartę. To najczęstszy powód, dla którego 2 GB przestaje wystarczać.
• Lokalny model AI to zupełnie inna skala: kilka do kilkudziesięciu GB. Więcej w poradniku Ile RAM-u potrzebuje serwer AI.

Przy VPS-ach to RAM najmocniej podbija cenę. Zwykle płacisz za plan, w którym pamięć, procesor i dysk rosną razem, a kolejny próg cenowy to podwojenie pamięci. Dlatego największa oszczędność to niekupowanie zapasu „na wszelki wypadek”.

Trzy decyzje, które ważą więcej niż wybór dostawcy

**1.*

• Model AI przez API zamiast lokalnego na VPS-ie. W naszych 9 aktywnych workflow model językowy (DeepSeek) jest wołany przez API, więc serwer z n8n nie musi go trzymać w pamięci. Lokalny model 7–8B na samym CPU wymaga zwykle co najmniej 8–16 GB RAM i działa wolno. Lokalne modele trzymamy na własnym sprzęcie z GPU, a nie na wynajętym VPS-ie.

**2.*

• Scraping przez zewnętrzne API zamiast przeglądarki na serwerze. Jeśli scrapujesz rzadko, usługa typu Apify czy Bright Data bywa tańsza niż stały upgrade VPS-a o 2 GB.

**3.*

• Pliki na dysk zamiast do RAM. Jedna zmienna środowiskowa (sekcja 6) sprawia, że obrazy i PDF-y nie zajmują pamięci n8n.

Kiedy zmienić plan na większy

Zwiększaj RAM, gdy po wdrożeniu limitów z sekcji 6 nadal widzisz którykolwiek z objawów:

• w logach pojawia się JavaScript heap out of memory;
• docker stats pokazuje stale ponad 80% limitu kontenera;
• system regularnie używa swapu przy zwykłych, zaplanowanych przebiegach (a nie przy ręcznym teście).

Aktualne ceny planów VPS porównasz w naszym zestawieniu dostawców. Instalację krok po kroku opisuje poradnik n8n na VPS z Dockerem i Caddy.

Zanim cokolwiek kupisz albo przytniesz, zmierz. Wystarczą trzy polecenia na serwerze z Dockerem.

Krok 1. Bieżące zużycie kontenerów

bashKopiuj

docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}\t{{.CPUPerc}}"

Kolumna MEM USAGE pokazuje pamięć samego kontenera n8n, osobno bazy i innych usług. To jest liczba, której szukasz, a nie wskaźnik całej maszyny.

Krok 2. Pamięć i swap całego serwera

bashKopiuj

free -h

Patrz na kolumnę available, nie free. Linux zajmuje wolną pamięć na pamięć podręczną dysku i oddaje ją, gdy trzeba, więc niskie „free” nie oznacza problemu.

Krok 3. Szczyt w czasie ciężkiego przebiegu

Uruchom najcięższy workflow z harmonogramu (nie z edytora) i w drugim oknie terminala obserwuj zużycie co 2 sekundy:

bashKopiuj

watch -n 2 'docker stats --no-stream --format "{{.Name}}: {{.MemUsage}}"'

Zanotuj najwyższą wartość dla n8n. Limit pamięci ustaw na mniej więcej 1,5× tego szczytu.

Krok 4. Sprawdź logi pod kątem braku pamięci

bashKopiuj

docker logs n8n --since 72h 2>&1 | grep -iE "heap out of memory|allocation failed|SIGKILL"

Pusty wynik oznacza, że w ostatnich trzech dobach n8n nie zabrakło pamięci. Nazwa kontenera (n8n) może być u Ciebie inna; sprawdzisz ją poleceniem docker ps.

Poniższy fragment docker-compose.yml dla serwera z 2 GB RAM ustawia twardy limit pamięci, rozmiar sterty silnika JavaScript, zapis plików binarnych na dysk i krótszą historię wykonań.

yamlKopiuj

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    mem_limit: 1200m
    environment:
      - NODE_OPTIONS=--max-old-space-size=900
      - N8N_DEFAULT_BINARY_DATA_MODE=filesystem
      - N8N_CONCURRENCY_PRODUCTION_LIMIT=3
      - EXECUTIONS_DATA_PRUNE=true
      - EXECUTIONS_DATA_MAX_AGE=168
      - EXECUTIONS_DATA_PRUNE_MAX_COUNT=5000
      - EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
      - EXECUTIONS_DATA_SAVE_ON_ERROR=all
    volumes:
      - n8n_data:/home/node/.n8n

| Ustawienie | Co daje |
| --- | --- |
| mem_limit | Kontener nie zabierze pamięci bazie i systemowi. Przy przekroczeniu Docker zrestartuje tylko n8n. |
| --max-old-space-size | Sterta JavaScriptu mniejsza niż limit kontenera (ok. 75%), żeby n8n zgłosił czytelny błąd zamiast zostać zabity. |
| N8N_DEFAULT_BINARY_DATA_MODE=filesystem | Obrazy, PDF-y i inne pliki trafiają na dysk zamiast do RAM. W trybie domyślnym n8n trzyma je w pamięci. |
| N8N_CONCURRENCY_PRODUCTION_LIMIT | Maksymalnie 3 wykonania produkcyjne naraz, reszta czeka w kolejce. Chroni przed zsumowaniem szczytów. |
| EXECUTIONS_DATA_* | Domyślnie n8n trzyma wykonania 14 dni (336 h) i do 10 000 sztuk. Krótsza historia i niezapisywanie udanych przebiegów odchudzają bazę i przyspieszają listę wykonań. |

Jeśli chcesz zachować dane udanych przebiegów tylko dla wybranego workflow, zostaw SAVE_ON_SUCCESS=none globalnie i włącz zapis w ustawieniach tego workflow (Workflow settings → Save successful production executions).

Swap jako poduszka bezpieczeństwa

Na małym VPS-ie dodaj 2 GB swapu. Nie przyspieszy n8n, ale zamiast nagłego zabicia procesu dostaniesz chwilowe spowolnienie.

bashKopiuj

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

> Uwaga

> Swap to zabezpieczenie, nie zamiennik RAM-u. Jeśli n8n korzysta ze swapu przy każdym zaplanowanym przebiegu, serwer jest za mały albo workflow przetwarza za dużo danych naraz.

Konfiguracja serwera to połowa sukcesu. Druga połowa to sposób, w jaki projektujesz workflow.

Pobieraj tylko potrzebne pola

API zwykle pozwala wybrać pola odpowiedzi. U nas zapytania do Facebook Graph API proszą tylko o potrzebne pola (treść, datę, reakcje, komentarze), a nie o całe obiekty postów. To samo dotyczy baz danych: SELECT konkretnych kolumn zamiast SELECT *.

Przetwarzaj partiami

Zamiast 10 000 wierszy w jednym przebiegu użyj węzła Loop Over Items z partiami po 100–200 elementów. Dokumentacja n8n wprost zaleca taki podział przy problemach z pamięcią.

Przenieś ciężką część do sub-workflow

Węzeł Execute Workflow uruchamia osobny workflow, a jego pamięć zwalnia się po zakończeniu. Niech sub-workflow zwraca tylko wynik (np. liczbę zapisanych rekordów), a nie wszystkie przetworzone dane.

Odchudzaj dane od razu

Po pobraniu dużej odpowiedzi dodaj węzeł Edit Fields (Set) z opcją zachowania tylko wybranych pól. Każdy kolejny węzeł dostanie wtedy mniejszą kopię.

Ostrożnie z węzłem Code

Węzeł Code jest wygodny, ale łatwo w nim skopiować całą tablicę kilka razy (map, filter, JSON.parse(JSON.stringify())). Zwracaj tylko to, czego potrzebuje następny krok.

Nie testuj ciężkich workflow z edytora na pełnych danych

Ręczne uruchomienie przesyła dane każdego węzła do przeglądarki. Testuj na małej próbce (np. węzeł Limit ustawiony na 5 elementów), a pełne dane puszczaj z harmonogramu.

| Objaw | Prawdopodobna przyczyna | Co zrobić |
| --- | --- | --- |
| „Execution stopped at this node (n8n may have run out of memory…)” | Jeden węzeł dostał za dużo danych | Partie (Loop Over Items), mniej pól, sub-workflow |
| „Connection Lost” albo błąd 503 w edytorze | Proces n8n został zrestartowany | Sprawdź docker logs i docker stats |
| JavaScript heap out of memory w logach | Sterta za mała dla tego workflow | Najpierw odchudź dane, dopiero potem zwiększ --max-old-space-size |
| Kontener restartuje się bez komunikatu | Przekroczony mem_limit (OOM killer) | Ustaw stertę na ok. 75% limitu kontenera |
| Cały serwer zwalnia, SSH reaguje z opóźnieniem | Intensywne użycie swapu | Ogranicz równoległość albo zwiększ RAM |
| Lista wykonań w edytorze ładuje się bardzo długo | Rozrośnięta historia wykonań w bazie | Ustaw EXECUTIONS_DATA_MAX_AGE i PRUNE_MAX_COUNT |

Według dokumentacji n8n instalacje w Dockerze i w n8n Cloud restartują się automatycznie po wyczerpaniu pamięci. Instalacja przez npm może wymagać ręcznego ponownego uruchomienia.

1. Policz aktywne workflow i sprawdź, czy któryś przetwarza pliki albo duże odpowiedzi API.

2. Sprawdź, czy potrzebujesz przeglądarki do scrapingu lub lokalnego modelu AI. Jeśli nie, zacznij od 2 GB.

3. Ustaw PostgreSQL zamiast SQLite, jeśli workflow często zapisują równolegle.

4. Dodaj mem_limit, --max-old-space-size i N8N_DEFAULT_BINARY_DATA_MODE=filesystem.

5. Skróć historię wykonań i wyłącz zapis udanych przebiegów.

6. Dodaj 2 GB swapu.

7. Przez tydzień obserwuj docker stats i logi.

8. Zwiększ plan dopiero wtedy, gdy pomiar pokaże stały brak pamięci.

Poniżej znajdziesz odpowiedzi na najczęstsze pytania o pamięć i koszty serwera dla n8n.

Samo n8n potrzebuje kilkuset MB pamięci. Dla typowych automatyzacji treści i integracji z AI przez API wystarcza serwer z 2 GB RAM, PostgreSQL i swapem. Większy rachunek usprawiedliwiają dopiero: przetwarzanie dużych plików, scraping przeglądarką albo lokalny model AI na tej samej maszynie. Zanim zwiększysz plan, zmierz zużycie i ogranicz ilość danych w workflow.

Źródła i dalsza lektura

• n8n: Memory-related errors
• n8n: Execution data
• n8n: Binary data environment variables
• n8n Cloud: zarządzanie danymi i limity planów
• Brodatech Stack: n8n na VPS z Dockerem i Caddy
• Brodatech Stack: lokalna instalacja n8n na Ubuntu
• Brodatech Stack: kompresja obrazów z n8n

Dane z naszego wdrożenia: odczyt z API n8n i Proxmox, 2 listopada 2026 r. Limity planów n8n Cloud mogą się zmieniać; aktualne wartości sprawdź u producenta.