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

MAATRIX

Renovate падает с кодом 137 посреди ночного прогона, PR не создаются, а в логах — тишина или сухое "Killed". Это классический OOM: Node.js-процесс, который парсит lockfile и резолвит зависимости десятка репозиториев, съел всю память VPS. Дальше — конкретные цифры по сценариям, рабочие конфиги systemd и docker, и что настроить, чтобы Renovate работал предсказуемо, а не как лотерея на каждый запуск.

Что на самом деле ест память

Renovate — это Node.js-приложение, и почти вся память уходит не на сам движок, а на три вещи.

Клонирование репозиториев. Для каждого репо Renovate делает git clone (обычно shallow, но для больших монорепо с длинной историей объём всё равно заметный) и держит рабочую копию на диске и частично в памяти во время анализа.

Парсинг lockfile и резолвинг зависимостей. Это главный потребитель. package-lock.json или pnpm-lock.yaml на несколько тысяч строк парсится в объектное дерево, а для каждого обновляемого пакета Renovate обращается к registry (npm, PyPI, crates.io и т.д.), кэширует ответы и строит граф версий. Монорепо с workspaces из 20-30 пакетов и общим lockfile — самый тяжёлый случай: один такой репозиторий по потреблению памяти может быть тяжелее десятка обычных Node.js-проектов.

Параллелизм. Self-hosted Renovate по умолчанию может обрабатывать несколько репозиториев и извлекать зависимости из нескольких lockfile-менеджеров внутри одного репо параллельно (parallel, prConcurrentLimit и внутренняя очередь datasource-запросов). Каждый параллельный поток — это ещё один экземпляр парсера и кэша в памяти в один момент времени.

Node.js по умолчанию ограничивает heap (--max-old-space-size) величиной, которая зависит от доступной памяти хоста — на VPS с 8+ ГБ это может быть 2-4 ГБ на одну кучу. Если явно не задать лимит, процесс будет пытаться выделять память вплоть до системного предела, и когда упрётся в него — сработает OOM killer ядра, а не аккуратная ошибка Node.js.

Сколько RAM нужно: по сценариям

Цифры ниже — ориентир по опыту эксплуатации self-hosted Renovate на обычных VPS, а не результат формального бенчмарка. У вас может отличаться в зависимости от языка проекта, размера lockfile и числа datasource-источников (npm, Docker Hub, GitHub Releases и т.д. — каждый добавляет сетевые запросы и немного памяти на кэш).

Если Renovate запускается по расписанию (раз в несколько часов), а не как постоянно работающий сервис, вам не нужно резервировать эту память под него круглосуточно — процесс отработал и завершился. Это отличается от логики подбора ресурсов под БД или веб-приложение, где нужен запас памяти "здесь и сейчас": подробнее про подбор VPS под задачи разработки и CI разобрано в статье про ресурсы VPS для разработчика и CI/CD.

Установка и разовый запуск

Проще всего пробовать через официальный Docker-образ — он уже содержит Node.js нужной версии и все datasource-плагины.

docker run --rm \
  -e RENOVATE_TOKEN="$RENOVATE_TOKEN" \
  -e RENOVATE_PLATFORM=github \
  -e LOG_LEVEL=info \
  renovate/renovate:39 \
  your-org/repo1 your-org/repo2

Для GitLab меняете RENOVATE_PLATFORM=gitlab и RENOVATE_ENDPOINT на URL вашего инстанса (если он self-hosted). Список репозиториев можно не перечислять в команде, а вынести в конфиг:

{
  "platform": "github",
  "repositories": ["your-org/repo1", "your-org/repo2", "your-org/repo3"],
  "onboardingConfig": {
    "extends": ["config:recommended"]
  }
}

Файл кладёте как config.js или config.json и передаёте переменной RENOVATE_CONFIG_FILE=/config/config.json с монтированием тома. Явный список репозиториев вместо autodiscover: true — первая и самая простая мера контроля памяти: вы точно знаете, сколько объектов Renovate будет держать в работе за один прогон.

Запуск по расписанию через systemd timer

На VPS разумнее не гонять Renovate постоянно, а поднимать его по таймеру — раз в 2-6 часов достаточно для большинства команд.

/etc/systemd/system/renovate.service:

[Unit]
Description=Renovate self-hosted run
After=docker.service
Requires=docker.service

[Service]
Type=oneshot
EnvironmentFile=/etc/renovate/renovate.env
ExecStart=/usr/bin/docker run --rm \
  --memory=2g --memory-swap=3g \
  --env-file /etc/renovate/renovate.env \
  -v /etc/renovate/config.json:/usr/src/app/config.json:ro \
  renovate/renovate:39

/etc/systemd/system/renovate.timer:

[Unit]
Description=Run Renovate every 4 hours

[Timer]
OnCalendar=*-*-* 0,4,8,12,16,20:00:00
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now renovate.timer
sudo systemctl list-timers renovate.timer

Ключевая строка — --memory=2g --memory-swap=3g: Docker жёстко ограничивает cgroup контейнера, и если Renovate попытается выйти за 2 ГБ, ядро убьёт процесс контролируемо, а не начнёт душить своп всей системы (что на маленьком VPS роняет заодно и остальные сервисы). Про то, как правильно посчитать своп под такие всплески — в статье про правильный размер swap для VPS.

Ограничение heap на уровне Node.js

Docker-лимит защищает систему, но сам Node.js узнаёт об этом не сразу — процесс может успеть выделить память до того, как cgroup его остановит. Дополнительно стоит ограничить heap явно через переменную окружения:

-e NODE_OPTIONS="--max-old-space-size=1536"

Это заставляет V8 запускать сборку мусора раньше и падать с чистой ошибкой JavaScript heap out of memory вместо непредсказуемого OOM kill в середине git-операции (после которого рабочая копия репозитория может остаться в грязном состоянии). Правило: --max-old-space-size выставляйте на 15-20% ниже, чем --memory в Docker — оставляете запас на не-heap память самого V8, буферы Node.js и дочерние процессы git.

Как снизить потребление без апгрейда VPS

Если 2 ГБ не хватает, а расширять сервер не хочется, есть рычаги внутри самого Renovate:

• Явный список репозиториев вместо autodiscover: true — вы не даёте Renovate самому решать, сколько репо обрабатывать за прогон.
• prConcurrentLimit и parallel — снизьте число одновременно обрабатываемых репозиториев/веток. Меньше параллелизма — ниже пиковое потребление, но дольше общий прогон.
• ignorePaths и matchFileNames — исключите lockfile тестовых окружений, документации, node_modules в вложенных пакетах, которые не нужно обновлять, но которые Renovate иначе честно распарсит.
• Реже lockFileMaintenance — полная пересборка lockfile (не точечное обновление одной зависимости) самая тяжёлая операция; включайте её по отдельному расписанию раз в неделю, а не при каждом прогоне.
• Разбить один самообслуживающий self-hosted процесс на несколько cron-задач — например, тяжёлые монорепо гонять отдельным таймером ночью, а лёгкие репо — чаще днём. Так пиковая память нужна не постоянно, а только в конкретное окно.
• Собственный runner в GitLab CI/GitHub Actions — если у вас уже настроен self-hosted раннер, дать ему отдельный job с memory limit проще, чем держать выделенный сервис. Базовая настройка такого раннера на VPS описана в статье про GitLab CI/CD на VPS.

Что делать, если Renovate всё равно падает по памяти

Признак OOM — код завершения 137 и запись в системном логе:

journalctl -u renovate.service --since "1 hour ago"
dmesg -T | grep -i "out of memory\|oom"

Если видите Memory cgroup out of memory: Killed process ... (node) — контейнеру не хватило заданного лимита. Порядок действий:

1. Сначала попробуйте сузить объём работы (список репозиториев, parallel) — это бесплатно.
2. Добавьте своп, если его нет или он слишком мал — процесс не будет мгновенно убит при кратковременном пике. Как это сделать с нуля, разобрано в статье про настройку swap-файла.
3. Если пики стабильно упираются в потолок даже с оптимизациями — это сигнал, что текущий тариф VPS маловат для объёма репозиториев, и разумнее взять план на ступень выше, чем постоянно балансировать на грани OOM.

Здесь есть прямая аналогия с self-hosted Sentry — там тоже легко недооценить память под фоновую обработку, и разбор по цифрам есть в статье сколько RAM нужно для Sentry self-hosted.

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