Короткий цикл 2026: self-hosted Git (Gitea/Forgejo) на лёгком VPS и посуточный облачный Mac для нативных сборок iOS — вебхуки, токены и изоляция пула

Командам с коротким циклом релиза выгодно держать Git ближе к разработчикам: Gitea или Forgejo на небольшом VPS даёт контрольную плоскость — репозитории, права, аудит и вебхуки — без тяжёлого DevOps-стека. Нативная сборка iOS по-прежнему требует macOS и Xcode; разумный компромисс 2026 года — оставить Git и оркестрацию на Linux VPS, а «горячую» фазу archive/testflight выполнять на посуточно арендуемом облачном Mac, когда очередь задач того стоит. Такой расклад снижает зависимость от чужих минутных квот SaaS-CI и позволяет явно разделить зоны ответственности: кто администрирует инстанс Git, кто владеет сертификатами Apple и кто имеет право ставить теги релиза.

Ниже — практическая схема без привязки к конкретному CI-бренду: вебхук из Forgejo/Gitea попадает на лёгкий брокер, который решает, нужно ли поднимать Mac-слот, и с каким набором секретов. Мы сознательно не смешиваем «матрицу решений» с рекламой одного поставщика: критерии одинаково применимы к собственным Mac mini в стойке и к посуточной аренде в облаке — отличаются только операционные издержки на обслуживание железа и предсказуемость очередей.

Разделение плоскостей: VPS и облачный Mac

На VPS размещают сам Forgejo/Gitea, reverse proxy с Let’s Encrypt, базу и брокер очереди (например, простой HTTP-сервис или лёгкий runner-шлюз). Он принимает вебхук push/pull_request, проверяет подпись или секрет заголовка, кладёт job в очередь и будит исполнитель. Облачный Mac поднимается по слоту: клонирует по HTTPS/SSH с deploy key только на чтение, подтягивает кэши, гоняет xcodebuild и выгружает артефакты обратно в хранилище или в object storage. Так вы не держите публичный SSH на постоянном железе команды и не смешиваете админские токены Git с ключами подписи кода.

Контрольная плоскость на Linux дешевле в эксплуатации по трафику и проще в резервном копировании: достаточно снапшотов тома с базой и конфигом. Исполнительная плоскость на macOS остаётся «островом» Apple: вы осознанно принимаете стоимость слота ради нативного toolchain и предсказуемого поведения линкера. Между ними держите только небольшой JSON с параметрами job (ветка, scheme, номер сборки) и ссылку на артефакт — без передачи лишних переменных окружения из вебхука целиком, чтобы снизить риск утечки через логи.

Если в организации уже есть корпоративный каталог и SSO, Forgejo/Gitea обычно интегрируют через OAuth провайдера; для машинного доступа всё равно оставляйте отдельные deploy keys на репозиторий, а не личные аккаунты разработчиков — так проще отозвать доступ при ротации команды без пересборки всех ноутбуков.

Вебхуки из Gitea/Forgejo: минимальный контракт

Настройте отдельный URL для CI за reverse proxy, ограничьте IP источника там, где возможно, и всегда проверяйте секрет вебхука на стороне брокера до постановки в очередь. Логируйте delivery id и отбрасывайте повторы, чтобы защититься от replay. Для репозиториев с субмодулями заранее решите: либо зеркала на том же инстансе, либо отдельные deploy keys с минимальным scope — иначе «зелёная» ветка на Mac сломается из-за недоступного субмодуля, а виноватой окажется сеть, а не код.

Таймауты между инстансом Git и брокером лучше держать короткими с явным ретраем на стороне Forgejo: так вы отличите временную деградацию сети от логической ошибки в скрипте приёма. В теле вебхука не полагайтесь на произвольные поля без схемы — валидируйте минимальный набор (репозиторий, коммит, тип события) и отвергайте всё остальное. Это дешёвая страховка против «толстых» payload’ов и случайных расширений плагинов.

Токены минимальных привилегий

Разведите три класса секретов: (1) PAT/токен инстанса только для администрирования и не храните его на раннерах; (2) scoped token или deploy key с правом только на нужные репозитории для clone/fetch; (3) ключи подписи Apple в Keychain или в секрет-хранилище CI, доступные только профилю сборки. Регулярно ротируйте вебхук-секрет и deploy key при увольнении или компрометации. Практический разбор сети и токенов для короткого цикла на облачном Mac см. также в материале про эластичный пул self-hosted GitHub Actions на macOS — те же принципы масштабирования и изоляции применимы к собственному брокеру.

Токен, которым раннер отмечает статус коммита в Git, не должен уметь удалять репозитории или менять веточную защиту: для API Forgejo/Gitea заведите отдельную «служебную» учётку с ролью только на запись статусов и артефактов. Для чтения исходников придерживайтесь deploy key на уровне репозитория, а не глобального ключа организации — так проще локализовать инцидент, если ключ утёк с одной машины сборки.

Ключи notarization и пароли от учёток разработчика Apple никогда не прокидывайте через переменные окружения из вебхука: только из защищённого хранилища на стороне Mac после успешной аутентификации job. Это правило скучное, зато оно спасает от ситуации, когда отладочный лог печатает окружение целиком.

Короткий FAQ

Forgejo или Gitea? Оба подходят как «лёгкий GitHub»: смотрите лицензию, плагины и политику безопасности релизов вашей организации. Если важна независимость от вендорских вилок, Forgejo явно позиционируется сообществом как устойчивый форк с открытым управлением; Gitea остаётся зрелым выбором там, где уже стандартизированы процессы под неё.

Нужен ли отдельный секрет для статусов в Git? Да: токен, который пишет commit status, должен иметь минимальный scope и отличаться от ключа, который может читать все репозитории оргизации. Иначе компрометация раннера открывает сразу и исходники, и метаданные релизов.

Как уменьшить шторм вебхуков? Фильтруйте события (только push в защищённые ветки), дебаунсьте и объединяйте очередь, чтобы не поднимать Mac на каждый автокоммит документации. Для монорепозитория полезен coarse trigger: собирать iOS только если изменились каталоги приложения, а не общие README.

Стоит ли держать Mac включённым 24/7? Для редких релизов дешевле посуточные или почасовые слоты плюс прогрев кэша; для непрерывного потока коммитов смотрите на стоимость ожидания в очереди и сравните с фиксированным узлом — матрица выше как раз про этот выбор.

Как объяснить безопасность внешнему аудиту? Покажите карту потоков данных: вебхук не содержит секретов Apple, Mac не хранит админский токен инстанса, артефакты уходят в object storage с отдельной политикой доступа. Этого достаточно для большинства чек-листов ISO-подобных опросников.

# Псевдокод проверки входящего вебхука
X-Gitea-Signature: <hmac>   # или X-Forgejo-Signature
X-GitHub-Delivery: <uuid> # если используете совместимый формат
User-Agent: GiteaHook / ForgejoHook

# Отклонить, если секрет не совпал или delivery уже видели

Итоговая схема для корпоративного пула: VPS остаётся «истиной» для политик и журналов, Mac — одноразовым или короткоживущим исполнителем с минимальным набором секретов. Так вы совмещаете нативный Xcode, контроль данных на своём Git и предсказуемую стоимость посуточных слотов под пики релиза.