Как установить и настроить Renovate на VPS

MAATRIX

Зависимости в проекте устаревают незаметно: сегодня пакет на минорной версии, через полгода — три мажорных релиза позади, а обновление превращается в отдельный спринт с риском всё сломать. Renovate решает это иначе: он сам находит устаревшие зависимости, открывает pull request с апдейтом и даже прогоняет тесты, пока вы занимаетесь остальным кодом. SaaS-версия от Mend бесплатна для GitHub, но для приватных self-hosted GitLab, Gitea или Forgejo нужен собственный инстанс Renovate — и его удобнее всего держать на своём VPS, где вы полностью контролируете токены, расписание и логи.

Установка Renovate на VPS

Renovate распространяется как npm-пакет и как Docker-образ. Для сервера практичнее контейнер: не нужно тащить Node.js в систему, версия зависимостей фиксирована, обновление — это docker pull новым тегом.

Проверьте, что Docker установлен и работает:

docker --version
docker compose version

Если Docker ещё не стоит, разверните его по инструкции для вашего дистрибутива — например, подробный разбор для Ubuntu 24.04, а если вы уже используете compose для остальных сервисов на сервере, пригодится и общий гайд по Docker Compose в продакшене.

Создайте рабочую директорию и файл с конфигом:

mkdir -p /opt/renovate/config
cd /opt/renovate
touch config/config.js

Проверить, что образ вообще запускается, можно так:

docker run --rm renovate/renovate:39 --version

Тег 39 здесь условный — на момент чтения статьи актуальная мажорная версия может быть другой, проверьте свежий тег на Docker Hub (renovate/renovate) перед деплоем. Дальше запускать docker run руками неудобно — нужен токен, переменные окружения и повторяемый запуск, поэтому конфигурацию лучше сразу оформить через compose или systemd-сервис (об этом — в разделе про расписание).

Подключение к Git-провайдеру

Renovate работает через API вашей платформы — GitLab, Gitea, Forgejo или GitHub — и для этого нужен токен доступа. Создайте отдельного технического пользователя (бота), а не используйте личный аккаунт: так проще отозвать доступ и видно в истории коммитов, что PR открыл именно бот.

Для self-hosted GitLab (если ваш инстанс развёрнут аналогично этой инструкции по GitLab CE на VPS):

1. Зайдите под учёткой бота → Settings → Access Tokens.
2. Создайте токен со scope api, read_repository, write_repository.
3. Дайте боту роль Developer (или выше) в нужных проектах/группе.

Для self-hosted Gitea (по инструкции установки Gitea на VPS):

1. Settings → Applications → Generate New Token.
2. Отметьте права repo, write:issue, read:user.

Токен не хранится в открытом виде в конфиге — Renovate ожидает его в переменной окружения. Создайте файл .env:

cat > /opt/renovate/.env <<'EOF'
RENOVATE_TOKEN=glpat-xxxxxxxxxxxxxxxxxxxx
RENOVATE_PLATFORM=gitlab
RENOVATE_ENDPOINT=https://git.example.com/api/v4/
RENOVATE_AUTODISCOVER=false
EOF
chmod 600 /opt/renovate/.env

Для Gitea/Forgejo укажите RENOVATE_PLATFORM=gitea, а RENOVATE_ENDPOINT — путь до API вашего инстанса. Ограничьте права на файл: только владелец должен читать токен, никаких chmod 644 на переменные окружения.

Базовая конфигурация renovate.json

Основной конфиг — renovate.json в корне репозитория, который Renovate будет сканировать. Минимальная рабочая версия:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"],
  "timezone": "Europe/Moscow",
  "schedule": ["before 6am on monday"],
  "labels": ["dependencies"],
  "prConcurrentLimit": 5,
  "packageRules": [
    {
      "matchUpdateTypes": ["minor", "patch"],
      "automerge": true
    },
    {
      "matchUpdateTypes": ["major"],
      "automerge": false,
      "labels": ["dependencies", "major-update"]
    }
  ]
}

Логика здесь простая и практичная: минорные и патч-обновления сливаются автоматически (если у вас настроен CI и он проверяет тесты перед мержем), а мажорные — только через ручной ревью с отдельным лейблом. prConcurrentLimit не даёт Renovate завалить репозиторий тридцатью PR за один прогон — полезно на старте, когда зависимостей накопилось много.

Если репозиториев несколько и хочется единый стандарт, вынесите общую часть в отдельный shareable-конфиг (renovate-config репозиторий с default.json) и подключайте через extends: ["github>org/renovate-config"] или аналог для вашей платформы — это избавляет от копипасты между проектами.

Список репозиториев, которые должен обходить Renovate, задаётся либо через RENOVATE_AUTODISCOVER=true (сканирует всё, что доступно токену — удобно для старта, но может зацепить лишнее), либо явным списком:

RENOVATE_REPOSITORIES=group/project-a,group/project-b

Для продакшена явный список надёжнее — вы точно знаете, что бот трогает, и не удивляетесь PR в чужом форке.

Запуск по расписанию: systemd timer

Renovate — не демон, он завершает работу после одного прохода по репозиториям. Запускать его нужно периодически, и на VPS для этого удобнее systemd timer, а не обычный cron: он логирует запуски через journalctl, умеет Persistent=true (наверстать пропущенный запуск после перезагрузки) и не зависит от того, залогинен ли кто-то в системе.

Юнит для запуска контейнера:

# /etc/systemd/system/renovate.service
[Unit]
Description=Renovate dependency updates
After=docker.service
Requires=docker.service

[Service]
Type=oneshot
EnvironmentFile=/opt/renovate/.env
ExecStart=/usr/bin/docker run --rm \
  --env-file /opt/renovate/.env \
  -v /opt/renovate/config:/usr/src/app/config \
  renovate/renovate:39

Таймер:

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

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
RandomizedDelaySec=600

[Install]
WantedBy=timers.target

Активируйте:

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

RandomizedDelaySec размазывает запуск в пределах 10 минут — мелочь, но если у вас несколько таймеров на одном сервере, это снижает пиковую нагрузку. Проверить, что всё сработало, можно через:

journalctl -u renovate.service -n 100 --no-pager

Если предпочитаете классический cron, запись в crontab -e под тем же пользователем выглядит так: 0 3 * * * docker run --rm --env-file /opt/renovate/.env -v /opt/renovate/config:/usr/src/app/config renovate/renovate:39 >> /var/log/renovate.log 2>&1 — рабочий вариант, но без встроенного восстановления после простоя сервера и без структурированных логов.

Практические сценарии

Renovate из коробки понимает десятки экосистем — npm, pip, Docker-образы в Dockerfile и compose-файлах, GitHub Actions, Terraform-провайдеры, Go-модули. Разберём пару частых случаев.

Обновление Docker-образов в compose-файле. Если в docker-compose.yml у сервисов зафиксированы теги (postgres:16.2, nginx:1.27-alpine), Renovate сам подхватит это без дополнительной настройки — достаточно, чтобы образы были указаны с явной версией, а не latest (для latest отслеживать «обновление» бессмысленно, Renovate такие теги игнорирует).

npm-зависимости с группировкой. Чтобы не получать по PR на каждый пакет из одного экосистемного семейства, сгруппируйте их:

{
  "packageRules": [
    {
      "matchPackagePatterns": ["^@types/"],
      "groupName": "TypeScript types"
    },
    {
      "matchPackageNames": ["eslint", "eslint-config-*", "eslint-plugin-*"],
      "groupName": "ESLint"
    }
  ]
}

Уязвимости отдельным потоком. Модуль vulnerabilityAlerts поднимает приоритет PR с исправлением известных CVE — они приходят вне обычного расписания, сразу после обнаружения:

{
  "vulnerabilityAlerts": {
    "enabled": true,
    "labels": ["security"]
  }
}

Если у вас в CI уже настроен собственный раннер — например, по инструкции GitLab CI Runner на VPS — имеет смысл требовать зелёный пайплайн как условие для автомержа: "automergeType": "pr" вместе с настроенными required checks на стороне GitLab/Gitea не даст замержить обновление, которое ломает сборку.

Диагностика и частые проблемы

Самая частая проблема на старте — «Renovate ничего не находит». Проверяйте в таком порядке:

1. Токен и права. docker run с LOG_LEVEL=debug покажет, смог ли Renovate вообще авторизоваться и увидеть список репозиториев.
2. AUTODISCOVER vs явный список. Опечатка в имени репозитория в RENOVATE_REPOSITORIES — Renovate просто молча пропустит его.
3. onboarding PR не создаётся. При первом запуске на новом репозитории Renovate обычно сначала открывает "Configure Renovate" PR — это нормально, надо смержить его, чтобы бот начал работать по-настоящему.
4. Rate limit платформы. На self-hosted GitLab/Gitea лимиты обычно не проблема, но при RENOVATE_AUTODISCOVER=true на большом количестве проектов первый прогон может быть долгим — это не зависание, а честный обход всех репозиториев.

Полезная переменная для отладки: LOG_LEVEL=debug в .env временно, для разового запуска — не оставляйте её в проде постоянно, лог разрастается быстро. Ограничить диск под логи systemd можно в /etc/systemd/journald.conf через SystemMaxUse.

Если бот открывает PR, но CI не подтягивается — проверьте, что у токена бота есть права запускать пайплайны (api scope в GitLab закрывает это, но убедитесь, что бот не заблокирован защитой веток на push в форк-репозитории, если используете такую модель).

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