Сколько RAM нужно для n8n

MAATRIX

Запрос «n8n требования к серверу» набирают в двух состояниях: перед заказом VPS и после третьего ночного падения с exit code 137. Ответ «двух гигабайт хватит» верен ровно до первого сценария, который тянет из API десять тысяч записей или скачивает партию PDF. Ниже — разбор памяти по компонентам с цифрами RSS, способ измерить свой расход и набор переменных, снимающих половину нагрузки без перехода на тариф дороже.

Короткий ответ: сколько RAM нужно для n8n

Аппетит n8n определяется не количеством сценариев, а объёмом данных в одном выполнении и тем, что вы поставили рядом на ту же машину.

Главное из таблицы: сам n8n в покое — это 250–400 МБ. Всё, что выше четырёх гигабайт, уходит не на интерфейс и не на число сценариев, а на данные активных выполнений, базу и соседей по машине.

Из чего складывается память n8n

n8n — это Node.js-приложение (в актуальной ветке 1.1xx — на Node 22), запакованное в Alpine-образ. Версию сборки и вес образа видно так:

docker exec n8n n8n --version
docker images n8nio/n8n --format "{{.Repository}}:{{.Tag}} {{.Size}}"

Первые восемь строк предсказуемы: 400–700 МБ. Последние две умножаются на вашу нагрузку — в них и живут все неожиданности.

Почему сервер падает ночью, а не под дневной нагрузкой

Днём идут вебхуки: маленькие JSON, короткие выполнения, память возвращается сборщику мусора почти сразу. Ночью отрабатывает расписание — выгрузки, синхронизации, почта с вложениями. И вступает механика, о которой не пишут в туториалах: n8n держит в памяти данные всех узлов выполнения, пока оно не закончилось. Не только текущего узла — всех, начиная с триггера.

Замер на стенде (2 vCPU / 4 ГБ, Ubuntu 24.04, Docker 27, mem_limit: 3g, NODE_OPTIONS=--max-old-space-size=2304):

• холодный старт, редактор закрыт — RSS 238 МБ, nodejs_heap_size_used_bytes 96 МБ;
• редактор открыт, в базе 24 сценария — RSS 372 МБ, heap 141 МБ;
• отработал один узел из langchain-пакета — RSS 546 МБ и обратно уже не опустился;
• HTTP Request вернул 11 МБ JSON (8 700 объектов) — heap вырос на 104 МБ, почти вдесятеро против размера ответа;
• после Split Out и двух Set-узлов — heap 486 МБ;
• Code-узел с items.map(), создающий копию массива — пик heap 690 МБ, RSS 940 МБ.

Одиннадцать мегабайт с сервера превратились в шестьсот с лишним в памяти. Распарсенный JS-объект тяжелее своего текстового представления в 5–10 раз, а каждый меняющий данные узел кладёт рядом новую версию массива, не удаляя предыдущую: она нужна для отладки и перезапуска с места ошибки.

Бинарные данные добавляют своё. В режиме по умолчанию файл живёт в памяти как base64-строка — на 33% больше исходного размера. PDF на 8 МБ превращается в 10,7 МБ строки, и она копируется в run data каждого пройденного узла: пять узлов — за 50 МБ на документ, ночная партия из сорока счетов — два гигабайта на ровном месте.

Отсюда же ловушка узла Loop Over Items: он не освобождает память между итерациями, данные всех итераций остаются частью того же выполнения. Лечится выносом тела цикла в отдельный сценарий через Execute Sub-workflow с возвратом одного маленького объекта — дочернее выполнение завершается, и его данные освобождаются.

Как отличить OOMKilled от heap limit

Это два разных отказа, и лечатся они по-разному. Начните с проверки, кто именно убил процесс:

docker inspect n8n --format '{{.State.OOMKilled}} {{.State.ExitCode}}'

Ответ true 137 означает, что процесс прибило ядро по лимиту cgroup. Подтверждение — в dmesg -T | grep -i "out of memory": строка вида Memory cgroup out of memory: Killed process ... (node). Лечится увеличением лимита контейнера, снижением параллелизма или уменьшением данных.

Второй вариант — код выхода 134 и в docker logs n8n --tail 50:

<--- Last few GCs --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

Здесь до системного лимита не дошло: в потолок упёрся сам V8. Проверить его значение:

docker exec n8n node -e "console.log(Math.round(require('v8').getHeapStatistics().heap_size_limit/1048576)+' MB')"

На контейнере с лимитом 2 ГБ увидите около 1024 МБ, на 4 ГБ — около 2048, на машине без лимита — около 4144: Node подгоняет кучу под доступную память.

Самая неприятная комбинация — когда --max-old-space-size больше лимита контейнера. V8 не успевает начать агрессивную сборку мусора, ядро приходит раньше, и вы всегда получаете 137 без единой строчки диагностики: ни имени сценария, ни стека. Правило: --max-old-space-size = 70–75% лимита контейнера. Для 4 ГБ это 3072, для 2 ГБ — 1400.

Чтобы видеть расход, а не ловить его постфактум, включите метрики (N8N_METRICS=true и N8N_METRICS_INCLUDE_DEFAULT_METRICS=true) и снимайте:

curl -s http://127.0.0.1:5678/metrics | grep -E 'nodejs_heap_size_(used|total)_bytes'
while true; do docker stats --no-stream --format '{{.Name}} {{.MemUsage}}' n8n; sleep 10; done | tee -a /var/log/n8n-mem.log

Сутки такого лога покажут, какой именно ночной сценарий даёт пик.

Переменные, которые снимают половину нагрузки

Прежде чем брать тариф вдвое дороже, выставьте это в docker-compose.yml — набор снижает пиковое потребление примерно вдвое:

    mem_limit: 3g
    environment:
      - NODE_OPTIONS=--max-old-space-size=2304
      - N8N_DEFAULT_BINARY_DATA_MODE=filesystem
      - N8N_CONCURRENCY_PRODUCTION_LIMIT=5
      - N8N_PAYLOAD_SIZE_MAX=32
      - EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
      - EXECUTIONS_DATA_SAVE_ON_ERROR=all
      - EXECUTIONS_DATA_SAVE_ON_PROGRESS=false
      - EXECUTIONS_DATA_PRUNE=true
      - EXECUTIONS_DATA_MAX_AGE=168
      - EXECUTIONS_DATA_PRUNE_MAX_COUNT=5000

Чем приходится платить:

• N8N_DEFAULT_BINARY_DATA_MODE=filesystem — самая крупная одиночная победа: файлы уезжают из памяти в /home/node/.n8n/binaryData. Честный минус — проблема переезжает на диск, а каталог чистится только вместе с удалением выполнений: без прунинга он растёт бесконечно.
• N8N_CONCURRENCY_PRODUCTION_LIMIT=5 — лишние выполнения встают в очередь вместо одновременного старта. Минус прямой: при всплеске вебхуков ответы задержатся. Зато сервер не ляжет.
• EXECUTIONS_DATA_SAVE_ON_SUCCESS=none — успешные выполнения не пишутся в базу, экономятся диск и память на сериализации. Ошибки сохраняются полностью, отладка не страдает.
• EXECUTIONS_DATA_SAVE_ON_PROGRESS=false — значение по умолчанию, но его включают на время отладки и забывают выключить. С ним n8n сериализует всё run data после каждого узла.
• N8N_PAYLOAD_SIZE_MAX=32 — потолок тела входящего запроса в мегабайтах (по умолчанию 16). Выше поднимать без нужды не стоит: это прямой множитель к пику на каждый параллельный вебхук.
• DB_TYPE=postgresdb память не экономит, но снимает залипания на разросшихся таблицах. Что распухло, покажет SELECT pg_size_pretty(pg_total_relation_size('execution_data'));

Если после всех настроек всё равно упирается — смотрите разбор нехватки RAM на сервере и частых ошибок n8n.

Когда одного процесса мало: раннеры и queue mode

Task runners выносят выполнение Code-нод в отдельный процесс со своей кучей:

      - N8N_RUNNERS_ENABLED=true
      - N8N_RUNNERS_MAX_CONCURRENCY=5
      - N8N_RUNNERS_MAX_OLD_SPACE_SIZE=1024

Цена — 80–120 МБ постоянно занятой памяти. Выгода — сорвавшийся Code-узел с бесконечным массивом убивает раннер, а не весь n8n: интерфейс и вебхуки живы, раннер поднимается сам.

Queue mode — следующий уровень: EXECUTIONS_MODE=queue, Redis как брокер, воркеры отдельными контейнерами (n8n worker --concurrency=5). Расход считается по формуле:

RAM воркера ≈ 250 МБ базы + concurrency × пик одного выполнения

При среднем пике 150 МБ и concurrency 5 это 250 + 750 = 1 ГБ, контейнеру нужно давать 1,5 ГБ с запасом. Главный процесс легчает до 400–600 МБ — он только принимает вебхуки и отдаёт интерфейс. Комплект «main + два воркера + Redis + PostgreSQL» занимает 4,5–5 ГБ, то есть просится на восьмигигабайтную машину.

Честно о границах: queue mode не уменьшает суммарную память, а перераспределяет её и добавляет около 700 МБ накладных расходов. Ради экономии RAM он бессмыслен — только ради параллелизма, изоляции сбоев и разнесения воркеров по серверам.

Ориентир по ядрам: n8n не распараллеливает одно выполнение. Два ядра — минимум, при котором сборка мусора и приём вебхуков не мешают друг другу. Если docker stats показывает 100% CPU при спокойной памяти, вам нужны ядра, а не гигабайты.

Какой сервер взять в MAATRIX под n8n

Честный минимум — 2 vCPU, 4 ГБ RAM, 40 ГБ NVMe. Почему не два гигабайта, хотя n8n на них стартует: при лимите 2 ГБ потолок кучи V8 опускается до ~1,4 ГБ, и первый же сценарий на десять тысяч записей в него упирается. Плюс диск: полтора гигабайта под образ, старый образ рядом до docker image prune, база и binaryData — двадцатигигабайтный диск кончается на третьем месяце.

Комфортный вариант — 4 vCPU, 8 ГБ RAM, 80 ГБ NVMe. Сюда влезают n8n с раннерами, PostgreSQL, Redis и пара воркеров, остаётся запас на ночные пики и место под файлы. AI-агенты через внешние API в эти же восемь гигабайт помещаются: langchain-пакет добавляет 120–200 МБ, а не гигабайты. Десятки гигабайт нужны только при локальной модели на том же сервере — и это уже требования модели, разобранные в таблице памяти для Ollama.

Локация — Лондон. Причина практическая: n8n целыми днями стучится наружу — Google Sheets, Notion, Slack, Telegram, платёжные шлюзы, API моделей. С британского адреса запросы уходят напрямую, без прокси и лишних звеньев. Из России часть сервисов отвечает капризно или не отвечает вовсе, а каждый повисший HTTP-узел держит run data своего выполнения в памяти всё время таймаута — так сетевая проблема становится проблемой с RAM. Пинг Москва — Лондон держится в районе 45–60 мс, для вебхуков и расписаний это незаметно. Франция — равноценная альтернатива с GDPR-соседством, США берут ради американского IP и зарубежных ИИ-сервисов, Россию — когда через сценарии ходят персональные данные и нужен 152-ФЗ.

Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT; иностранная карта не нужна даже для лондонской площадки. Развернуть с нуля поможет пошаговая установка n8n на VPS. Не уверены, какой сценарий ваш, — напишите, сколько сценариев и какого объёма данные гоняете, подберём конфигурацию под нагрузку.

Частые вопросы