Короткий ответ
- Чистой «российской» SaaS‑платформы, полностью аналогичной по масштабу и экосистеме GitHub.com (с миллионами проектов, Marketplace, Actions и т. п.), практически нет.
- Практически единственный рабочий вариант для крупных проектов — заказать у крупного российского облачного провайдера управляемый (SaaS‑подобный) Git‑сервис на базе GitLab/GitHub Enterprise, размещённый в РФ и поддерживаемый провайдером. Такой подход даёт Git‑хостинг, CI/CD и возможность запускать раннеры внутри инфраструктуры провайдера (и SLA на уровне, близком к вашим требованиям).
Кого рассматривать (точно проверить у каждого)
- Yandex.Cloud — крупный российский облачный провайдер; у них есть партнёры и marketplace‑образ с GitLab, а также возможности для развёртывания управляемых сервисов в РФ.
- SberCloud — облако Сбера, предлагает managed‑решения и услуги для DevOps / CI.
- Selectel — один из крупнейших российских хостеров, предлагает managed‑GitLab и managed‑DevOps‑услуги.
- VK Cloud / Mail.Ru Cloud Solutions — облачные сервисы крупного игрока, возможны managed‑решения.
- Rostelecom / DataLine / Cloud4Y и др. — крупные региональные провайдеры, также предлагают managed‑GitLab/DevOps.
Почему это практично
- GitLab/GitHub Enterprise на инфраструктуре российского облака даёт полный набор: git‑репозитории, Merge Requests/PR, CI/CD, контейнерный реестр, артефакты, политики безопасности, audit‑logs и поддержку self‑hosted runners (раннеры запускаются в частной сети/кластерe провайдера).
- Крупные провайдеры имеют сервис‑контракты и SLA (обычно 99.5–99.99% в зависимости от уровня сервиса).
О чём нужно спросить/проверить при выборе провайдера
1. SLA и компенсации: конкретный процент (например 99.5/99.9/99.99%), метрики, процедура эскалации и кредитов.
2. Резервирование и гео‑размещение: сколько зон/ЦОД в РФ, есть ли автоматическое резервирование между ЦОДами.
3. Data residency и доступ регуляторов: где физически хранятся данные, как оформлены соглашения.
4. Managed GitLab/GitHub vs «просто VM с GitLab»: что именно выдают как сервис (обновления, патчи, бэкапы, DR).
5. CI/CD и раннеры: поддержка self‑hosted runners, возможности коннекта к вашим VPC/Kubernetes, ограничения по параллельным пайплайнам, лимиты по времени и по ресурсам.
6. Безопасность: 2FA, SSO/LDAP, IP‑whitelisting, secrets management, audit logs, сканирование уязвимостей.
7. Масштабируемость и ограничения репозиториев (LFS, максимальный размер репо, монорепо).
8. Экспорт/импорт: возможность бэкапа и экспорта репозиториев, артефактов и CI‑настроек (чтобы при необходимости быстро перенести код).
9. Поддержка и SLA для администрирования (24/7, RTO/RPO).
10. Цена и модель оплаты (подписка/за ресурсы/за пользователя).
Практические рекомендации
- Попросите у провайдера тестовый период или демо‑инстанс и SLA‑договор в письменном виде.
- Требуйте четкий план бэкапа/восстановления и процедур на случай блокировок/инцидентов.
- Сделайте зеркала репозиториев (read‑only) у другого провайдера в РФ для отказоустойчивости; держите CI‑раннеры в нескольких зонах.
- Если критично «не заблокируют», ориентируйтесь на крупные государственно/корпоративно ориентированные провайдеры (SberCloud, Yandex.Cloud, Selectel и т. п.) — они менее уязвимы к локальным блокировкам, чем зарубежные SaaS.
Если хотите, могу:
- Составить готовый чеклист с вопросами для RFP/технического запроса провайдерам.
- Подобрать 2–3 конкретных предложения от поставщиков (на основе вашего полного списка требуемого функционала и бюджета).
Напишите, пожалуйста, полный список функциональных требований (что именно вы подразумеваете под «функционал:» — например, поддержка Git LFS, контейнерный реестр, сканирование кода, number of concurrent pipelines, SSO, аудит и т. п.), бюджет и ожидаемая нагрузка (количество репозиториев, пользователей, параллельных билдов). Тогда дам более предметные варианты и шаблоны вопросов.