Свой GitLab против платных тарифов: точка перелома по числу разработчиков

MAATRIX

Когда в команде пять разработчиков, вопрос «свой GitLab или подписка» не стоит — платите за пять мест и не думаете об инфраструктуре. Когда разработчиков пятьдесят, счёт за подписку превращается в отдельную строку бюджета, и кто-то в чате обязательно спрашивает: «А если поднять своё?» Проблема в том, что честного ответа с числами обычно никто не считает — сравнивают на глаз. Ниже — методика, как посчитать точку перелома для вашей команды: число разработчиков, начиная с которого self-hosted GitLab CE на своём сервере обходится дешевле платной подписки, и что в этом расчёте почти всегда забывают.

Как устроены платные тарифы GitLab: за что вы платите каждый месяц

GitLab продаётся по модели «цена за пользователя в месяц» (per-seat pricing), с несколькими уровнями: бесплатный tier с ограниченным функционалом, средний платный tier (обычно называется Premium) и верхний (Ultimate) с расширенной безопасностью, compliance-инструментами и портфельным управлением проектами. Точные цифры тарифов я здесь сознательно не привожу — GitLab периодически их пересматривает, курс валюты для оплаты из России добавляет свою переменную, а условия для команд разного размера (self-managed лицензия, годовая оплата со скидкой, SaaS-версия на gitlab.com) отличаются. Смотрите актуальные цифры на официальной странице тарифов перед расчётом — но саму методику это не меняет.

Для формулы важна не конкретная цифра, а сама структура: стоимость подписки растёт линейно с числом пользователей.

Стоимость_подписки(N) = P × N × 12   (в год)

где:

• N — число разработчиков (мест) с доступом к GitLab;
• P — цена одного места в месяц на выбранном тарифе.

Ключевой нюанс: N — это не «сколько человек реально коммитят каждый день», а число выданных лицензий. В подписку обычно попадают и тимлиды, которые в основном ревьюят MR, и QA, которым нужен доступ к issue-трекеру, и иногда даже менеджеры продукта, которым нужны epics. На практике N почти всегда больше, чем «число разработчиков» в узком смысле — это первая вещь, которую стоит проверить перед сравнением: посчитайте реальное число активных мест, а не строку в оргструктуре.

Второй нюанс — при переходе на верхний тариф (Ultimate) ради конкретной фичи (security scanning, compliance-фреймворки, продвинутый approval workflow) вы платите P за *всех* пользователей, а не только за тех, кому фича нужна. Это часто и есть реальный триггер разговора про self-hosted: команде нужна одна-две функции с верхнего тарифа, а платить приходится за всех.

GitLab CE на своём сервере: что получаете и чего не получаете

GitLab Community Edition (CE) — open-source версия GitLab, которую можно развернуть на собственном сервере бесплатно, без лицензионных платежей. Это тот же продукт, что и в облаке: репозитории, merge requests, встроенный CI/CD с раннерами, container registry, issue-трекер, wiki. Для абсолютного большинства команд из 5–200 разработчиков функционала CE хватает с запасом — это не урезанная «пробная» версия, а полноценная система, на которой годами работают компании поменьше GitLab Inc.

Чего в CE нет — это функций, которые GitLab оставляет за Enterprise Edition (EE), доступной либо в облачных платных тарифах, либо как self-managed лицензия поверх той же кодовой базы (то есть self-hosted тоже можно купить с EE-функциями, просто это отдельная статья расходов). Обычно это:

• продвинутые правила approval для merge requests (несколько групп ревьюеров, обязательные ревью по коду);
• эпики и портфельное планирование поверх issues;
• расширенное сканирование безопасности (SAST/DAST продвинутого уровня, dependency scanning с полным отчётом);
• compliance-фреймворки и аудит-логи корпоративного уровня;
• SSO/SAML для крупных организаций (базовый LDAP в CE есть).

Если ни одна из этих функций вашей команде не критична — сравнение получается честным: CE на своём сервере против Free/Premium тарифа в облаке. Если критична хотя бы одна — сравнивайте self-managed EE-лицензию, а не «бесплатный» CE, иначе расчёт получится нечестным в вашу пользу.

Сколько стоит сервер под self-hosted GitLab CE

Стоимость self-hosted варианта — это не «ноль», это фиксированная сумма, не зависящая (в первом приближении) от числа разработчиков, пока сервер тянет нагрузку.

Составляющие:

1. Аренда сервера. GitLab CE — прожорливое приложение: Rails-монолит, PostgreSQL, Redis, Gitaly, Sidekiq-воркеры. Официальные рекомендации GitLab начинаются от 4 CPU / 8 ГБ RAM для команд до ~20 пользователей, и требования растут с числом активных проектов и частотой CI-джобов — детальную раскладку по памяти под разные размеры команды разбирали в статье сколько RAM нужно для GitLab CE. Для команды в 30–50 разработчиков закладывайте отдельный сервер под сам GitLab и, желательно, отдельные CI-раннеры — раннеры любят упираться в CPU при параллельных пайплайнах.
2. Хранилище под репозитории, артефакты и container registry. Растёт со временем — Docker-образы и CI-артефакты копятся быстрее, чем кажется на старте.
3. Резервное копирование. Отдельное хранилище под бэкапы (минимум — снапшоты + выгрузка gitlab-backup в объектное хранилище). Это не опция, а обязательная статья расходов: конфигурацию восстановления после сбоя разбирали в бэкапе и восстановлении GitLab CE.
4. CI/CD-раннеры, если ожидается параллельная сборка нескольких проектов — их можно и нужно вынести на отдельные VPS, чтобы сборки не конкурировали за ресурсы с самим GitLab. Настройка раннеров на VPS разобрана в статье про GitLab CI/CD на VPS.

Обозначим суммарную ежемесячную стоимость инфраструктуры как F — это сервер под сам GitLab, сервер(ы) под раннеры и хранилище под бэкапы вместе. Для ориентира: командам среднего размера (20–40 человек) обычно достаточно конфигурации в диапазоне 8–16 ГБ RAM под основной сервер плюс отдельный раннер на 4–8 ГБ — но это именно ориентир, а не готовая цифра для вашей команды: точный размер зависит от числа проектов, частоты пайплайнов и объёма Docker-образов, которые вы храните в registry.

Важно: F почти не растёт при переходе с 20 до 40 разработчиков — растёт при росте числа *проектов и пайплайнов*, а это разные вещи. Именно поэтому self-hosted вариант становится тем выгоднее, чем больше в команде людей относительно числа активных репозиториев.

Формула точки перелома: когда своя инфраструктура выгоднее

Точка перелома — это число разработчиков N*, при котором ежемесячная стоимость подписки становится равна фиксированной стоимости своей инфраструктуры (плюс стоимость администрирования — о ней в следующем разделе). До этой точки платить за облако может быть дешевле и точно проще; после — считать становится выгодно самим.

Базовая формула без учёта администрирования:

P × N* = F
N* = F / P

где:

• P — цена одного места в месяц на тарифе, который вы бы выбрали в облаке;
• F — суммарная ежемесячная стоимость self-hosted инфраструктуры (сервер + раннеры + бэкап-хранилище).

Если реальное число ваших разработчиков N > N* — self-hosted вариант в моменте дешевле по инфраструктуре. Если N < N* — платная подписка обходится дешевле, чем аренда и обслуживание своего сервера ради экономии на малом числе мест.

С учётом администрирования формула честнее:

N* = (F + A) / P

где A — ежемесячная стоимость администрирования в денежном эквиваленте (часы в месяц × стоимость часа специалиста). Про это — следующий раздел, это не мелочь, которую можно опустить.

Практическое наблюдение из этой формулы: точка перелома зависит не только от числа людей, но и от того, какой тариф вы сравниваете. Если команде фактически хватает бесплатного тарифа GitLab (или у вас реально мало разработчиков, но вы всё равно тратите на другой инструмент) — self-hosted может вообще не окупаться, потому что P в формуле равен нулю или близко к нему. Формула работает только там, где вы *действительно* платите за платный тариф ради конкретных функций.

Также стоит проверить чувствительность расчёта: если P вырастет (а провайдеры пересматривают тарифы), N* уменьшается — self-hosted становится выгоднее при меньшем числе разработчиков. Если у вас команда балансирует у самой точки перелома — держите это в уме как аргумент на будущее, а не только на сегодня.

Администрирование — вторая, нефинансовая стоимость

Здесь честность важнее красивой формулы. F — это не единственная цена self-hosted GitLab. Есть вторая цена, которая не в деньгах напрямую, но конвертируется в них при желании: время.

Что реально требует внимания на self-hosted GitLab CE:

• Обновления. GitLab выпускает минорные релизы часто, а мажорные обновления иногда требуют строгого порядка (нельзя перепрыгнуть через несколько мажорных версий разом) — пропустите пару циклов обновлений, и апгрейд превращается в отдельный проект на день, а не в рутинную операцию на 20 минут.
• Мониторинг ресурсов. Sidekiq-очереди забиваются под нагрузкой, Gitaly упирается в диск при большом числе репозиториев, PostgreSQL требует настройки под объём данных — это не «поставил и забыл», особенно на растущей команде.
• Резервное копирование и проверка восстановления. Бэкап, который ни разу не разворачивали в тестовой среде — это не бэкап, а иллюзия бэкапа. Проверка восстановления — регулярная задача, а не разовая настройка.
• Безопасность. Патчи безопасности, ограничение доступа, ротация токенов CI/CD, настройка runner-изоляции, чтобы один скомпрометированный пайплайн не добрался до остальной инфраструктуры.
• CI-раннеры под нагрузкой. С ростом команды раннеры упираются в ресурсы первыми — потребуется либо масштабировать вертикально, либо добавлять раннеры и настраивать балансировку джобов.

Реалистичная оценка для команды в 30–50 разработчиков — от нескольких часов в неделю в спокойный период до полноценного дня при мажорном обновлении или инциденте с восстановлением. Если у вас уже есть DevOps-инженер, добавление GitLab в его зону ответственности стоит недорого по деньгам, но всё равно стоит по времени и вниманию — это ресурс, который тратится не бесконечно. Если такого человека нет и его придётся нанимать — это прямая статья расходов, и её стоит явно посчитать, а не спрятать в «ну, кто-нибудь разберётся». Методику перевода часов администратора в деньги и порог, когда выгоднее доплатить за managed-решение, разбирали в статье сколько стоит час админа и когда дешевле доплатить — используйте её вместе с формулой выше, чтобы получить честное A.

Честный итог этого раздела: self-hosted GitLab почти никогда не бывает бесплатным. Он обменивает денежные расходы на подписку на комбинацию из фиксированной инфраструктурной стоимости и времени специалиста. Формула из предыдущего раздела с A внутри — это и есть попытка сделать сравнение честным, а не «своё = бесплатно».

Практический пример: считаем для команды

Возьмём иллюстративные, а не реальные официальные цифры — просто чтобы показать, как формула работает на практике. Подставьте в неё актуальные P с сайта GitLab и реальную F под вашу конфигурацию сервера.

Допустим:

• P = условные 20 $/мес за место на платном тарифе (актуальную цифру проверьте сами — GitLab её пересматривает);
• F = условные 120 $/мес суммарно за сервер под GitLab, раннер и бэкап-хранилище;
• A = условные 80 $/мес эквивалент времени администратора при спокойном режиме обслуживания (несколько часов в месяц).

Тогда:

N* = (F + A) / P = (120 + 80) / 20 = 10

При 10 разработчиках подписка и self-hosted вариант обходятся примерно одинаково. При 20 разработчиках стоимость подписки (20 × 20 $ = 400 $/мес) уже вдвое превышает F + A (200 $/мес) — self-hosted вариант становится выгоднее почти вдвое. При 5 разработчиках подписка (100 $/мес) дешевле self-hosted (200 $/мес) — держать свой сервер ради экономии здесь смысла не имеет, разве что есть другие причины (контроль над данными, требования по резидентности, желание не зависеть от чужого SaaS).

Соберите эти три числа для своей команды в таблицу и пересчитайте — формула не изменится, изменятся только входные данные:

Если реальное N вашей команды заметно больше расчётного N* — экономика в пользу self-hosted, и дальше вопрос сводится к тому, готовы ли вы взять на себя администрирование. Если N близко к N* или меньше — платная подписка, скорее всего, обойдётся дешевле по совокупности денег и времени, и переезд имеет смысл по другим причинам, не по экономии.

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