Renovate на Ubuntu 24.04: пошаговая установка

MAATRIX

Зависимости в проекте копятся годами: сегодня забыли обновить одну библиотеку, завтра — десять, а через полгода апгрейд превращается в отдельный спринт с непредсказуемым числом сломанных тестов. Renovate решает эту проблему системно — сканирует репозиторий, находит устаревшие пакеты и сам открывает pull request с обновлением, по расписанию, без вашего участия. Дальше — пошаговая установка self-hosted Renovate на Ubuntu 24.04, от нуля до рабочего бота, который открывает PR-ы в GitLab или Gitea.

Зачем self-hosted Renovate, если есть облачный сервис

У Renovate есть облачная версия — Mend Renovate App для GitHub, бесплатная и не требующая администрирования. Но если ваш код лежит не на GitHub, а на self-hosted GitLab или Gitea (что типично для проектов, где инфраструктура держится на своём VPS), облачный вариант не подойдёт: он не достучится до внутреннего сервера за NAT или за VPN.

Self-hosted Renovate — это тот же движок, но запущенный как обычное CLI-приложение или контейнер внутри вашей инфраструктуры, с доступом к внутреннему Git-серверу напрямую по сети. Дополнительный плюс — полный контроль над расписанием, логами и тем, какие именно репозитории сканируются. Минус один: обслуживание берёте на себя вы, а не чужой облачный сервис.

Если у вас уже поднят self-hosted Gitea или GitLab CI/CD, Renovate логично ставить рядом, на том же сервере или соседнем VPS — тогда сетевые задержки до Git-сервера минимальны, а токен доступа не нужно светить наружу.

Требования к серверу и подготовка Ubuntu 24.04

Renovate — Node.js-приложение, ресурсоёмкость зависит от числа репозиториев и частоты запуска. Для 5-20 проектов с ежедневным сканированием достаточно скромной конфигурации:

Это ориентир — если репозиториев десятки и среди них крупные монорепы, память лучше взять с запасом, потому что Renovate клонирует каждый репозиторий локально для анализа lock-файлов.

Обновляем систему и ставим базовые пакеты:

apt update && apt upgrade -y
apt install -y curl git build-essential ca-certificates gnupg

Проверяем часовой пояс сервера — он влияет на то, как Renovate трактует cron-расписание запусков:

timedatectl set-timezone Europe/Moscow
timedatectl status

Установка Node.js и Renovate CLI

Renovate требует актуальный LTS Node.js. Ставим через NodeSource-репозиторий — на момент написания статьи актуальна ветка Node.js 20 LTS:

curl -fsSL https://deb.nodesource.com/setup_20.x | bash -
apt install -y nodejs
node -v
npm -v

Дальше два пути: установить Renovate CLI глобально через npm либо запускать через официальный Docker-образ. Для сервера, где Renovate — единственная задача, проще и предсказуемее CLI-путь:

npm install -g renovate
renovate --version

Если вы уже используете Docker для других сервисов на этом VPS (например, поднимали docker compose для продакшена), логичнее запускать Renovate тем же образом — так проще версионировать и откатывать конфигурацию:

docker pull renovate/renovate:latest

Оба варианта рабочие, дальше в статье приведены команды для CLI-подхода — для Docker логика та же, меняется только способ передачи переменных окружения (через -e или --env-file).

Создание токена доступа и первый запуск

Renovate работает от имени бота — отдельного пользователя или личного токена с правами на чтение репозиториев и создание pull request-ов. Для Gitea:

1. Создайте отдельного пользователя renovate-bot (или используйте существующий сервисный аккаунт).
2. Зайдите в Settings → Applications → Generate New Token.
3. Выберите права: repository (read/write), write:issue для комментариев в PR.
4. Сохраните токен — он показывается один раз.

Для GitLab процесс аналогичный: Settings → Access Tokens, права api, read_repository, write_repository.

Создаём файл конфигурации хоста — config.js в домашней директории сервисного пользователя:

module.exports = {
  platform: 'gitea',
  endpoint: 'https://git.example.com/api/v1/',
  token: process.env.RENOVATE_TOKEN,
  autodiscover: false,
  repositories: ['team/project-a', 'team/project-b'],
  onboardingConfigFileName: 'renovate.json',
};

Для GitLab меняется только platform: 'gitlab' и endpoint на https://git.example.com/api/v4.

Первый запуск делаем вручную, чтобы увидеть логи и убедиться, что токен и права настроены верно:

export RENOVATE_TOKEN="ваш_токен"
renovate --config-file /home/renovate-bot/config.js

При успехе Renovate клонирует каждый репозиторий из списка, проанализирует package.json, go.mod, requirements.txt или другой манифест зависимостей и на первом прогоне откроет "onboarding PR" — предложение добавить файл renovate.json в репозиторий с настройками именно для этого проекта.

Конфигурация renovate.json в репозитории

Общие настройки хоста живут в config.js на сервере, а поведение для конкретного проекта — в renovate.json внутри самого репозитория. Базовый пример, который покрывает большинство случаев:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"],
  "timezone": "Europe/Moscow",
  "schedule": ["after 10pm and before 6am every weekday"],
  "prConcurrentLimit": 5,
  "packageRules": [
    {
      "matchUpdateTypes": ["minor", "patch"],
      "automerge": true
    },
    {
      "matchUpdateTypes": ["major"],
      "automerge": false,
      "labels": ["major-update", "needs-review"]
    }
  ]
}

Ключевые параметры, которые стоит настроить осознанно, а не оставлять по умолчанию:

• schedule — окно, в которое Renovate разрешено открывать и обновлять PR-ы. Ночное расписание удобно, чтобы не отвлекать команду в рабочие часы.
• prConcurrentLimit — ограничивает число одновременно открытых PR, иначе при первом запуске на старом проекте вы получите полсотни pull request-ов разом.
• automerge для patch/minor — рискованный, но экономящий время параметр. Включайте только там, где есть автотесты, которые реально блокируют мердж при поломке.
• packageRules — точечные исключения: например, зафиксировать мажорную версию фреймворка, пока не готовы к миграции.

Для проектов на Python, Go или Rust логика та же — Renovate поддерживает десятки экосистем "из коробки" без дополнительной настройки, определяя менеджер пакетов по файлам манифеста в репозитории.

Автоматизация запуска через cron и systemd timer

Ручной запуск годится для отладки, в бою нужен планировщик. Два рабочих варианта: классический cron или systemd timer — второй даёт более внятные логи через journalctl.

Вариант с cron, запуск каждый час в рабочем окне:

crontab -e -u renovate-bot

0 * * * * cd /home/renovate-bot && RENOVATE_TOKEN="ваш_токен" renovate --config-file config.js >> /var/log/renovate/run.log 2>&1

Если вы уже настраивали cron-задачи на VPS для других задач, добавить сюда ещё одну строку — минутное дело, важно только не забыть про ротацию логов, иначе run.log за месяц вырастет до неприличных размеров.

Вариант с systemd timer чуть многословнее, зато логи идут в единый системный журнал:

# /etc/systemd/system/renovate.service
[Unit]
Description=Renovate dependency updater

[Service]
Type=oneshot
User=renovate-bot
WorkingDirectory=/home/renovate-bot
Environment=RENOVATE_TOKEN=ваш_токен
ExecStart=/usr/bin/renovate --config-file /home/renovate-bot/config.js

# /etc/systemd/system/renovate.timer
[Unit]
Description=Run Renovate hourly

[Timer]
OnCalendar=hourly
Persistent=true

[Install]
WantedBy=timers.target

systemctl daemon-reload
systemctl enable --now renovate.timer
systemctl list-timers | grep renovate

Токен в открытом виде в unit-файле — не лучшая практика для продакшена: вынесите его в EnvironmentFile=/home/renovate-bot/.env с правами 600, чтобы файл читал только сам сервисный пользователь.

Мониторинг и типовые проблемы запуска

Renovate — стабильный инструмент, но при первом внедрении вы почти наверняка столкнётесь с парой типичных ситуаций.

Onboarding PR не открывается. Чаще всего причина в правах токена — не хватает write:issue или аналога для создания PR, либо у бота нет прав писать в репозиторий напрямую (для защищённых веток нужен обход через merge request, а не push).

Слишком много PR разом на старом проекте. Решается через prConcurrentLimit и prHourlyLimit в конфиге — Renovate откроет PR-ы порциями, а не все 40 штук единовременно.

Renovate падает по памяти на больших монорепах. Клонирование и анализ lock-файлов у крупных репозиториев требовательны к RAM — если сервер начинает уходить в swap, это сигнал добавить памяти или ограничить matchFileNames, чтобы Renovate анализировал не весь монорепо, а конкретные пакеты.

Для отслеживания, что плановые запуски вообще происходят (а не молча падают неделями), полезно завести внешний heartbeat-мониторинг — например, через healthchecks.io: последняя строка cron-команды или systemd-сервиса делает curl-пинг при успешном завершении, и вы получаете алерт, если Renovate вдруг замолчал.

Логи стоит проверять не только глазами при инциденте, но и периодически — renovate пишет достаточно подробный вывод об ошибках доступа, rate limit API Git-сервера и пропущенных пакетах прямо в stdout.

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