tempus.build
Self-hosted runners или managed: реальная стоимость
Для CI на GitHub Actions рано или поздно встаёт вопрос стоимости. Если сравнивать цену инстанса с поминутной оплатой GitHub-hosted, свои раннеры на бумаге выглядят дешевле. Но инстанс — это только compute. Полная стоимость владения CI складывается из трёх статей расходов — compute, эксплуатация и риск; две последние в тарифах облака не показаны, и в них уходит разница.
Мы делаем managed-раннеры для GitHub Actions, то есть в этом сравнении — сторона заинтересованная. Поэтому ниже названы и случаи, где self-hosted выигрывает. Цифры — только опубликованные; Total Cost of Ownership — полная стоимость владения: не только цена ресурса, но и эксплуатация, обслуживание и риск за всё время использования.-итогов и «экономии X%» здесь не будет: свои цифры считайте на калькуляторе.
Три модели исполнения
У CI на GitHub Actions три модели:
- GitHub-hosted — раннеры GitHub, оплата поминутно с округлением вверх. Ноль эксплуатации, но округление до минуты и меньше контроля над окружением.
- Self-hosted — свои раннеры на своём железе или в своём облаке. Максимум контроля, но эксплуатация и безопасность целиком на вас.
- Managed (сюда входит tempus.build) — чужие раннеры как сервис, но с той же простотой, что
GitHub-hosted: меняете одну строку
runs-on. Оплата за исполнение, эксплуатация — на стороне сервиса.
Дальше — про два полюса: self-hosted и managed.
Из чего складывается стоимость self-hosted
Цена «инстанс за N в час» покрывает только compute. Под ней лежит то, что оплачивается временем команды и простаивающей ёмкостью:
- Idle / always-on. Облачные инстансы и ноды тарифицируются, пока запущены, а не пока исполняют job. Значит, вы платите за простой между сборками и за запас под пики. CI неравномерен: утренний наплыв, ночная тишина. Эта неравномерность и превращается в оплаченный простой.
- Автоскейл. Чтобы не платить за постоянный пик, нужен автоскейлинг. Стандартное OSS-решение — ARC (actions-runner-controller), оператор Kubernetes от GitHub, который масштабирует self-hosted раннеры под нагрузку. Но это кластер, сам контроллер, runner scale sets, вебхуки, RBAC — их надо развернуть, обновлять и обслуживать. Работа платформенной команды, а не разовая установка.
- Сборка и патчинг образов. Кто-то собирает образы раннеров, держит тулчейны и рантаймы свежими, пересобирает под патчи безопасности и не даёт копиться устаревшим версиям. Постоянный поток задач, а не «настроил и забыл».
- Изоляция недоверенного кода. CI исполняет чужой код — из PR, из зависимостей. Безопасное исполнение требует изоляции на уровне VM, контроля Исходящий сетевой трафик из раннера — загрузка зависимостей, образов. В облаке за него берут плату, и его нужно контролировать ради безопасности., поведенческого мониторинга и Одноразовый раннер на один job: поднимается, выполняет, уничтожается. Ничего не переживает границу job'а.. Self-hosting на общих постоянных раннерах открывает риск breakout и горизонтального перемещения. Это не наша интерпретация: GitHub сам не рекомендует self-hosted для публичных репозиториев (открывается в новой вкладке) и советует одноразовые (ephemeral) раннеры — именно из-за недоверенного кода в PR. (Как устроена эта граница — в разборе изоляции Kata.)
- Кэш-инфраструктура. Скорость сборок держится на кэше зависимостей рядом с раннерами (pull-through для npm/pip/docker, CAS). Без него каждая сборка загружает зависимости из публичного интернета — медленнее и дороже по Исходящий сетевой трафик из раннера — загрузка зависимостей, образов. В облаке за него берут плату, и его нужно контролировать ради безопасности..
- On-call. У доступности, обновлений, инцидентов и ёмкости есть владелец. Регулярная человеческая стоимость, которой в сравнении «по цене VM» нет.
Сложите эти статьи — и «дешевле» из сравнения по цене инстанса часто исчезает уже на средней команде, где нет отдельной платформенной группы под всю эту эксплуатацию.
Как устроена цена в tempus.build
Managed снимает эту операционную стоимость с вашей команды — образы, патчи, ёмкость и изоляцию держит провайдер. Взамен появляется своя зависимость (аптайм провайдера, каталог форм-факторов, порог доверия) — поэтому ниже честно перечислены случаи, где self-hosted выигрывает.
Сама модель оплаты меняется так:
- Посекундно, без округления. Job на 75 секунд стоит 75 секунд. GitHub-hosted округляет каждый job до целой минуты — на коротких частых job’ах это накапливается.
- Только исполнение — никакого idle. Вы не платите за простой между сборками и за запас под пики: ёмкость и автоскейл — наша забота, не строка в вашем счёте.
- Задержка на запуск чистого окружения (VM или раннера) перед стартом job'а. Тёплый пул её маскирует ценой простаивающей ёмкости. не тарифицируется. Счётчик включается, когда job уже исполняется; секунды на запуск чистой VM — на нас.
- Предоплата — потолок расходов встроен. Баланс пополняется заранее и списывается посекундно; новые job-ы не стартуют при нулевом балансе, уже запущенные дорабатывают — перерасход не больше 1 $. Счёта-сюрприза в конце месяца нет. Баланс не сгорает.
- Цена зашита в метку.
tempus-ubuntu-24.04-2core— это всегда0,004 $/мин,4core—0,008 $/мин, в любом репозитории. Что выбрали вruns-on, то и платите, без скрытых множителей.
Сейчас доступны две конфигурации; 8- и 16-core — по запросу:
Метка runs-on | Ресурсы | Ставка |
|---|---|---|
tempus-ubuntu-24.04-2core | 2 vCPU / 8 GB | 0,004 $/мин |
tempus-ubuntu-24.04-4core | 4 vCPU / 16 GB | 0,008 $/мин |
2core — того же размера, что ubuntu-latest на приватных репозиториях, и дешевле его за минуту (0,004 $ против
0,006 $): самый простой способ переехать для job-ов, которым не нужно 4 ядра. Ставка 4core (0,008 $/мин)
дешевле сопоставимого GitHub-hosted larger-раннера; баланс — в долларах США. Точные цены GitHub и множители — в
официальной документации (открывается в новой вкладке) (на публичных
репозиториях standard-раннеры бесплатны — речь о приватных). На малых объёмах приватные репо могут
укладываться во включённые минуты GitHub — поэтому мы и говорим «посчитайте на своём объёме», а не обещаем
экономию всем. Сколько выйдет именно у вас — на калькуляторе; универсального «дешевле на
X%» не бывает, всё зависит от пайплайна.
Калькулятор считает по допущениям, которые вы вводите. Coverage считает по факту: войдите в платформу через GitHub, поставьте GitHub App (открывается в новой вкладке) — и по реальным прогонам после установки он покажет, во сколько обошлись бы те же прогоны на раннерах tempus.build. Не переключая на наши раннеры ни одного job.
Поверх — контроль расходов: бюджеты организации с уведомлением или остановкой новых job’ов, оповещения о всплесках, автопополнение по желанию. Начать можно с приветственных $5 на балансе — привязывать карту не нужно (один раз на GitHub-пользователя, после подключения первой организации). Это 625 минут работы 4-core раннера.
Сравнение по осям
| Ось | Self-hosted | tempus.build (managed) |
|---|---|---|
| Модель оплаты | за запущенную ёмкость (часто always-on) | посекундно за исполнение, без округления |
| Idle | платите за простой и запас под пики | не тарифицируется |
| Эксплуатация | кластер, ARC, образы, патчинг, on-call | на стороне сервиса (парк раннеров, образы и обновления — на нас) |
| Масштабирование | строите и настраиваете сами (ARC) | автомасштабирование по запросу, в пределах лимита одновременных job-ов на организацию |
| Cold start | сами держите тёплый пул против цены | управляем; не тарифицируется |
| Изоляция | ваша ответственность, легко ошибиться | VM на job + egress-контроль + поведенческий мониторинг |
| Supply-chain | аттестуете образы сами | подписанные образы + SBOM + SLSA, open-source |
| Кэш | строите и держите сами | кэш зависимостей в том же дата-центровом регионе, что и раннеры, по частной сети |
| Порог входа | дни-недели на безопасный запуск | одна строка runs-on, откат тоже одной |
Где self-hosted выигрывает
Managed — не всегда правильный ответ. Self-hosted сильнее, когда:
- Нужен полный контроль и своё железо — GPU, ARM, Windows/macOS, собственные образы, особые тулчейны. tempus.build сейчас — только Ubuntu 24.04 x64 и две конфигурации: 2 vCPU / 8 GB и 4 vCPU / 16 GB.
- Строгие требования к данным — data residency, изоляция в своём VPC или периметре, air-gap. Свои раннеры работают там, где скажете; managed-сервис — это третья сторона в контуре доверия.
- Ровная 24/7-загрузка. Если нода занята почти на 100% круглые сутки, собственное железо по себестоимости может обойти любую поштучную managed-цену. Посекундная модель выигрывает на неравномерном CI, а не на плоской полной загрузке.
- Независимость от вендора — нет привязки к доступности чужого сервиса.
Развилка: неравномерный CI + небольшая команда + желание ноль эксплуатации → managed; ровная 100%-загрузка + строгий residency + особое железо → self-hosted.
Если пробовать tempus.build
Порог входа и выхода низкий:
- Переход — одна строка.
runs-on: ubuntu-latest→runs-on: tempus-ubuntu-24.04-4core. Остальной workflow не меняется. - Откат — тоже одна строка. Вернули
ubuntu-latest— и вы снова на GitHub-hosted. Неизрасходованный оплаченный остаток вернём по запросу (приветственные и бонусные начисления не возвращаются); уйти можно в любой момент. - Изоляция как у отдельной машины. Каждый job — в своей одноразовой VM, уничтожается после завершения. Образ раннера — open-source (tempusbuild/runner-images (открывается в новой вкладке)), можно собрать и проверить самому; как устроена изоляция — на странице «Безопасность и изоляция» и в разборе изоляции Kata.
- Нужна GitHub-организация. Раннеры сейчас обслуживают приватные репозитории организаций; личные аккаунты и публичные репозитории пока не поддерживаются.
- Приветственные $5 на балансе, без карты — запустите свои пайплайны и посмотрите на реальные цифры до первого пополнения.
Не верьте на слово — посчитайте на своём объёме и сравните с тем, во сколько обходится собственная эксплуатация.