Свой CI-раннер на VPS: перестаём платить за минуты

Платные минуты CI кончаются быстро, особенно на тяжёлых билдах. Свой раннер на VPS снимает лимиты: платите фиксированную цену за сервер и гоняете сколько нужно. Разберём GitHub Actions и GitLab.

Когда свой раннер выгоднее

Бесплатные минуты GitHub/GitLab заканчиваются, а платные стоят дорого при частых билдах, тестах и Docker-сборках. Свой раннер на VPS даёт неограниченное время сборки, кэш между запусками на быстром диске и полный контроль над окружением.

CI-сборки — это компиляция, тесты и Docker-образы: всё упирается в CPU и диск. AMD EPYC + NVMe у MAATRIX ускоряют билды в разы против медленных облачных раннеров, а фиксированная цена от $8/мес заменяет поминутную оплату.

Посчитайте на пальцах: типичный облачный раннер даёт 2 медленных ядра, а тяжёлый билд монорепозитория с тестами легко съедает 15-20 минут. При десятках пушей в день бесплатный лимит кончается за неделю, и дальше каждая минута платная. Свой раннер на быстром VPS не только снимает лимит, но и физически считает быстрее — билд, который в облаке шёл 15 минут, на NVMe с кэшем зависимостей укладывается в 4-5. Для команд из России бонус — оплата сервера картой РФ, СБП или криптой.

GitHub Actions self-hosted runner

Заходим в репозиторий → Settings → Actions → Runners → New self-hosted runner. GitHub даёт токен. На VPS:

useradd -m runner && su - runner
mkdir actions-runner && cd actions-runner
curl -o actions-runner.tar.gz -L https://github.com/actions/runner/releases/download/v2.317.0/actions-runner-linux-x64-2.317.0.tar.gz
tar xzf actions-runner.tar.gz
./config.sh --url https://github.com/USER/REPO --token <TOKEN>

Устанавливаем как сервис, чтобы раннер жил после выхода из сессии:

sudo ./svc.sh install
sudo ./svc.sh start
sudo ./svc.sh status

В workflow укажите runs-on: self-hosted — задачи пойдут на ваш VPS.

GitLab Runner

Для GitLab ставим официальный пакет и регистрируем раннер:

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | bash
apt install -y gitlab-runner
gitlab-runner register --url https://gitlab.com --token <TOKEN>

При регистрации выберите executor docker, чтобы каждая job шла в изолированном контейнере. Раннер уже запущен как systemd-сервис gitlab-runner. Тегами вы направляете нужные job именно на этот раннер: в .gitlab-ci.yml укажите tags: [self-hosted], а при регистрации задайте тот же тег. Так один VPS обслуживает несколько проектов, а лёгкие задачи можно оставить на shared-раннерах.

Docker для сборок

Большинству пайплайнов нужен Docker (сборка образов, docker-in-docker):

apt install -y docker.io
usermod -aG docker runner
usermod -aG docker gitlab-runner
systemctl enable --now docker

Для GitHub-раннера добавьте кэш зависимостей — храните его на NVMe, и повторные билды ускорятся кратно. Отдельно стоит включить очистку: после сотен сборок Docker забивает диск слоями и висячими образами. Поставьте в cron еженедельную уборку, чтобы не ловить No space left on device:

docker system prune -af --volumes
# и логи раннера, если растут
journalctl --vacuum-time=7d

Безопасность и частые ошибки

Self-hosted раннер выполняет код из репозитория — это риск. Правила:

• Не подключайте раннер к публичным репозиториям — форк-PR может выполнить произвольный код на вашем сервере.
• Гоняйте job в Docker/эфемерных контейнерах, не в host-окружении.
• Держите раннер под отдельным пользователем без sudo.

Проверить статус:

systemctl status actions.runner.*
gitlab-runner verify

Частая ошибка — раннер offline после ребута: проверьте, что сервис включён (systemctl is-enabled). Ещё одна — раздутый диск от кэшей и образов, поэтому уборку из предыдущего раздела ставьте в cron сразу. На отдельном VPS от MAATRIX раннер живёт стабильно, не конкурирует за ресурсы с продакшеном, а фиксированная цена от $8/мес окупается уже после нескольких десятков сборок в месяц.

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