Собственный Git-сервер обычно появляется не потому, что разработчикам внезапно понадобилось место для хранения исходного кода. Для этой задачи существует множество готовых облачных сервисов, где можно за несколько минут создать приватный репозиторий и начать работать.
Причины поднять Git на своем сервере обычно другие. Компания хочет полностью контролировать инфраструктуру и данные, проект нельзя размещать у стороннего сервиса, требуется интеграция с внутренней сетью или просто хочется получить собственную площадку для репозиториев без привязки к ограничениям внешней платформы.
И вот здесь возникает интересный выбор.
Можно установить GitLab и получить большую систему с репозиториями, пользователями, задачами, CI/CD и множеством дополнительных инструментов. Можно выбрать значительно более легкую Gitea или Forgejo. А можно вообще обойтись минимальным Git-сервером через SSH, если красивый веб-интерфейс и дополнительные функции не нужны.
Требования к хостингу у этих вариантов заметно отличаются.
Сам Git довольно экономно расходует ресурсы. Но GitLab, CI/CD runners, Docker-сборки, Git LFS и большое количество пользователей способны превратить маленький сервер для хранения кода в полноценную инфраструктурную систему.
Разберемся, какой сервер выбрать для Git, сколько ресурсов нужно GitLab, Gitea и Forgejo, где хранить большие файлы, как организовать резервное копирование и когда собственный Git-хостинг действительно имеет смысл.
Нужен ли вообще собственный Git-сервер
Первый вопрос стоит задать еще до выбора VPS.
Если небольшая команда просто хочет хранить несколько приватных репозиториев, собственный сервер далеко не всегда является самым удобным решением.
Готовая Git-платформа избавляет от администрирования. Не нужно обновлять операционную систему, следить за свободным диском, настраивать резервное копирование и восстанавливать сервис после сбоя.
Вы регистрируетесь, создаете репозиторий и работаете.
Собственный Git-хостинг переносит ответственность на владельца сервера.
Если VPS перестал работать в понедельник утром, проблема становится вашей. Если закончилось место на диске — тоже. Если несколько месяцев не устанавливались обновления безопасности — исправлять ситуацию придется самостоятельно.
Поэтому self-hosted Git следует выбирать не ради самого факта владения сервером, а когда его преимущества действительно нужны.
Например, компания хочет хранить исходный код только в собственной инфраструктуре. Или Git необходимо интегрировать с внутренними сервисами, которые недоступны из интернета. Иногда важна возможность самостоятельно определять правила регистрации, резервирования и хранения данных.
Еще один сценарий — большое количество небольших частных репозиториев, для которых собственная легкая Git-платформа оказывается удобной и экономичной.
Есть и просто личные серверы разработчиков. Один VPS может использоваться одновременно для небольших проектов, тестового окружения и собственной Gitea.
Но если единственная причина звучит как «свой сервер профессиональнее», лучше еще раз посчитать время на его обслуживание.
Git-хостинг и обычный Git — не совсем одно и то же
Сам по себе Git не требует GitLab или Gitea.
Репозиторий можно хранить на сервере и работать с ним через SSH. Для небольшой технически подготовленной команды этого иногда достаточно.
GitLab, Gitea и Forgejo добавляют вокруг Git удобную платформу.
Появляются веб-интерфейс, учетные записи, права доступа, просмотр кода, issues, pull или merge requests, уведомления, интеграции и множество других возможностей.
Поэтому, говоря о хостинге для Git, чаще имеют в виду именно сервер для такой платформы, а не просто каталог с bare-репозиториями.
GitLab, Gitea или Forgejo что выбрать для своего сервера
Выбор платформы напрямую влияет на требования к хостингу.
GitLab — большая система, объединяющая множество инструментов разработки вокруг репозитория. Она подходит командам, которым нужен не только Git, но и развитая экосистема для работы над проектами и автоматизации.
За функциональность приходится платить ресурсами и сложностью.
Устанавливать GitLab на самый маленький VPS только потому, что технически установка запускается, обычно не лучшая идея. Нужно оставлять достаточно памяти самой платформе, операционной системе и дополнительным процессам.
Gitea заметно легче. Это хороший вариант, когда в первую очередь нужны собственные Git-репозитории, удобный веб-интерфейс, пользователи, issues и стандартные инструменты совместной разработки без тяжелой инфраструктуры вокруг.
Forgejo находится в той же категории легких self-hosted Git-платформ и во многом близок к Gitea. Для небольшого собственного сервера оба варианта интересны именно умеренными требованиями к ресурсам.
Поэтому выбор стоит начинать не с вопроса «какая система мощнее», а с функций, которые действительно нужны команде.
Если требуется полноценная DevOps-платформа с глубокой автоматизацией, GitLab может оправдать более тяжелую инфраструктуру.
Если основная задача — удобно хранить код и совместно работать с репозиториями, легкая платформа зачастую рациональнее.
Нет смысла постоянно оплачивать лишние гигабайты RAM ради функций, которыми никто не пользуется.
Для одного разработчика GitLab часто избыточен
Представим разработчика, которому нужны десять приватных репозиториев, веб-интерфейс и возможность работать с ними с нескольких компьютеров.
Поднимать ради этого тяжелую платформу необязательно.
Gitea или Forgejo позволяют решить задачу значительно меньшими ресурсами.
А если веб-интерфейс вообще не нужен, можно использовать еще более простую конфигурацию.
С другой стороны, если разработчик хочет изучать GitLab CI/CD или воспроизводить рабочую инфраструктуру, GitLab может быть оправдан даже для одного человека.
Контекст важнее количества пользователей.
Какой VPS нужен для Git
Для собственного Git-хостинга чаще всего выбирают VPS или облачную виртуальную машину.
Главное преимущество — полноценный контроль над операционной системой.
Можно установить нужную платформу, настроить SSH, reverse proxy, firewall, резервные копии и дополнительные сервисы.
Виртуальный хостинг для такой задачи обычно неудобен. Пользователь shared-хостинга не получает того уровня контроля над системой, который требуется для самостоятельной установки GitLab или аналогичной постоянно работающей платформы.
Конкретные требования VPS зависят прежде всего от выбранного ПО.
Легкая Gitea с несколькими пользователями может комфортно чувствовать себя на относительно скромном сервере.
GitLab требует более серьезного запаса ресурсов.
При этом количество репозиториев само по себе опять же не является идеальным показателем нагрузки.
Сто маленьких репозиториев могут занимать меньше места и создавать меньшую нагрузку, чем один огромный проект с длинной историей, большими бинарными файлами и постоянно работающим CI.
Поэтому при выборе VPS я бы смотрела на четыре основные характеристики: CPU, RAM, диск и сеть.
Оперативная память. Особенно важна для тяжелых платформ и дополнительных сервисов. Сервер не должен постоянно работать на границе доступной RAM.
CPU. Само хранение Git-репозиториев редко требует огромного количества ядер, но операции с крупными репозиториями, веб-платформа и особенно CI способны заметно нагружать процессор.
Диск. Для Git важны не только гигабайты, но и нормальная производительность хранилища. SSD или NVMe сегодня являются наиболее логичным вариантом.
Сеть. Разработчики постоянно клонируют репозитории, выполняют pull и push. Для больших проектов объем трафика становится заметным.
Полезно оставлять запас дискового пространства. Репозитории растут, появляются артефакты, вложения, registry и резервные копии.
Сервер, на котором свободно несколько сотен мегабайт, — плохое место для системы хранения исходного кода.
Почему CI/CD может потреблять больше ресурсов чем сам Git
Вот здесь начинается самая интересная часть.
Небольшой Git-сервер способен обслуживать команду с довольно умеренной нагрузкой. Но затем кто-то включает автоматические сборки.
После каждого push запускаются тесты. Потом собирается frontend. Затем Docker-образ. После этого выполняются еще несколько проверок.
Внезапно сервер начинает использовать весь CPU и несколько гигабайт оперативной памяти.
Сам Git при этом практически ни при чем.
Нагрузку создает runner.
CI/CD runner выполняет задания pipeline. По сути, это рабочая машина, на которой запускаются команды проекта.
Если проект компилируется, прогоняет большой набор тестов или собирает Docker-образы, требования runner могут быть значительно выше требований самой Git-платформы.
Поэтому для серьезного CI имеет смысл разделять эти роли.
GitLab или Gitea работает на одном сервере, а runner — на другом.
Если runner полностью загрузит CPU во время тяжелой сборки, разработчики продолжат нормально открывать репозитории и выполнять push.
Для маленького проекта разделение необязательно. Git-платформа и runner могут находиться на одной машине.
Но это одна из первых вещей, которую стоит изменить при росте нагрузки.
Docker-сборки особенно прожорливы
Если CI собирает Docker-образы, нужно учитывать не только CPU и RAM.
Начинает активно расходоваться диск.
Слои образов, кеш сборки и временные данные постепенно накапливаются.
Без очистки диск может неожиданно закончиться, хотя сами Git-репозитории занимают совсем немного.
Поэтому мониторинг свободного пространства для CI-сервера особенно важен.
Именно здесь хорошо видно, почему вопрос «сколько места занимают мои репозитории» недостаточен для выбора размера VPS.
Где хранить большие файлы и нужен ли Git LFS
Git отлично работает с исходным кодом и текстовыми файлами, но плохо подходит для постоянно изменяющихся больших бинарных объектов.
Например, дизайнер добавляет в репозиторий огромный PSD-файл, затем несколько раз его изменяет.
Git хранит историю, и размер репозитория начинает быстро расти.
Для больших файлов существует Git LFS — Large File Storage.
В самом Git вместо большого объекта хранится указатель, а содержимое размещается отдельно.
Это особенно актуально для проектов с графикой, видео, крупными моделями и другими бинарными данными.
Но LFS тоже занимает место.
Если Git-сервер собственный, оплачивать это хранилище в конечном счете придется владельцу инфраструктуры.
Поэтому перед покупкой VPS полезно оценить не только текущий размер репозиториев, но и характер файлов.
Если команда работает преимущественно с исходным кодом, рост может быть относительно спокойным.
Если через Git проходят гигабайты графических ресурсов, требования к хранилищу совсем другие.
Для крупных инсталляций имеет смысл рассматривать отдельное или объектное хранилище, если выбранная платформа поддерживает подходящую схему.
SSH и HTTPS для работы с репозиториями
Git-сервер обычно позволяет работать с репозиториями через SSH и HTTPS.
SSH особенно удобен для разработчиков.
Пользователь создает пару ключей, добавляет публичный ключ в свой аккаунт и после этого может выполнять Git-операции без постоянного ввода пароля.
Приватный ключ остается на устройстве пользователя.
Важно не путать SSH-доступ к Git и административный SSH-доступ к самому VPS.
Разработчику совершенно необязательно выдавать root-доступ к серверу только для того, чтобы он мог делать push в репозиторий.
Платформа самостоятельно управляет Git-доступом пользователей.
HTTPS тоже широко используется и особенно удобен для различных интеграций.
Веб-интерфейс Git-платформы в любом случае должен работать по HTTPS, если доступен через интернет.
Сертификаты можно получать и обновлять автоматически, поэтому оставлять панель с логинами и исходным кодом на обычном незашифрованном HTTP нет смысла.
Безопасность собственного Git-сервера
Git-сервер содержит одну из наиболее ценных частей технического проекта — исходный код.
Иногда вместе с историей разработки, внутренними комментариями, конфигурациями и другой чувствительной информацией.
Поэтому относиться к нему как к случайному тестовому VPS не стоит.
Первое правило — своевременно обновлять саму Git-платформу и операционную систему.
Особенно важно следить за исправлениями у веб-приложения, которое доступно из интернета.
Второе — ограничить административный доступ.
Для SSH предпочтительнее использовать ключи, а root-вход и парольную аутентификацию настраивать в соответствии с выбранной моделью безопасности.
Третье — не открывать наружу ненужные сервисы.
Если база данных Git-платформы используется только локально, ей незачем принимать соединения со всего интернета.
Четвертое — внимательно относиться к регистрации пользователей.
Если это внутренний Git компании, публичная свободная регистрация обычно не нужна.
Создавать аккаунты можно вручную или через корпоративную систему аутентификации, если она используется.
Для важных учетных записей стоит включить многофакторную аутентификацию, если платформа ее поддерживает.
И конечно, секреты нельзя хранить прямо в репозитории.
Пароль базы, приватный API-ключ или production-токен, однажды попавший в Git, не исчезает автоматически после удаления из последнего состояния файлов. Он может сохраниться в истории.
Если секрет случайно опубликован, его следует считать скомпрометированным и заменить.
Backup Git-сервера сложнее копирования репозиториев
Если используется простой Git через SSH, основная ценность действительно находится в самих репозиториях.
У GitLab, Gitea или Forgejo данных значительно больше.
Помимо Git-репозиториев платформа может хранить:
- учетные записи пользователей;
- настройки проектов;
- права доступа;
- issues;
- pull или merge requests;
- комментарии;
- вложения;
- Git LFS;
- настройки интеграций;
- CI/CD-конфигурацию и связанные данные;
- packages и другие артефакты;
- данные container registry.
Часть этой информации находится в базе данных, часть — в файловом хранилище.
Поэтому простое копирование каталога с репозиториями не гарантирует полноценного восстановления платформы.
У GitLab, Gitea и Forgejo есть собственные особенности резервного копирования. Схему нужно строить с учетом документации выбранной системы.
При этом действует универсальное правило: резервная копия не должна существовать только на том же VPS.
Если сервер полностью потерян, локальный backup исчезнет вместе с ним.
Копию стоит отправлять в независимое хранилище.
Репозиторий на компьютере разработчика не заменяет backup
Git распределенный, поэтому у разработчиков действительно существуют локальные копии репозиториев.
В крайнем случае исходный код можно восстановить с одного из компьютеров команды.
Это замечательное дополнительное преимущество Git.
Но считать его полноценным резервным копированием GitLab или Gitea нельзя.
На локальном компьютере не обязательно есть все ветки и refs. Там нет полной базы пользователей, issues, комментариев, настроек доступа и другой информации платформы.
Поэтому нормальный серверный backup все равно необходим.
Стоит ли размещать Git-сервер в Docker
Можно, и это достаточно распространенный вариант.
GitLab, Gitea и Forgejo можно разворачивать в контейнерной среде, если конкретный способ поддерживается выбранной платформой.
Docker упрощает воспроизводимость окружения и обновление приложения.
Но после нашей статьи про Docker здесь важно повторить главный принцип: контейнер не должен быть единственным местом хранения ценных данных.
Репозитории, база и другие постоянные данные должны находиться в persistent volumes или соответствующем внешнем хранилище.
Удаление и создание нового контейнера не должно уничтожать Git-сервер вместе со всеми проектами.
Для небольшой Gitea можно получить очень аккуратную конфигурацию: reverse proxy, приложение и база работают в Docker Compose на одном VPS.
GitLab тоже можно контейнеризировать, но требования к ресурсам самой платформы от этого не исчезают.
Docker не делает тяжелое приложение легким.
Собственный Git и приватная сеть
Не каждый Git-сервер обязан быть доступен из всего интернета.
Для внутренней разработки компании его можно разместить в приватной сети и предоставлять доступ сотрудникам через VPN.
Так веб-интерфейс и SSH вообще не придется публиковать для всего мира.
Это особенно интересно для инфраструктуры, которая используется только сотрудниками.
Но такое решение тоже имеет цену в удобстве.
Разработчику сначала нужно подключиться к корпоративной сети. Внешним CI-сервисам и интеграциям потребуется отдельный доступ.
Поэтому закрывать Git за VPN только потому, что это кажется более безопасным, не всегда обязательно.
Публично доступный сервис с HTTPS, своевременными обновлениями, правильной аутентификацией и ограниченными административными интерфейсами тоже может быть нормально защищен.
Архитектуру стоит выбирать под реальную модель угроз и требования компании.
Когда Git-сервер пора разделять на несколько машин
Для небольшой команды одна виртуальная машина — нормальная отправная точка.
На ней может находиться Git-платформа, база и даже небольшой runner.
По мере роста первым кандидатом на переезд часто становится CI.
Причина проста: сборки создают резкие пики нагрузки.
Runner можно перенести на отдельный VPS и оставить основной Git-сервер в покое.
Дальше все зависит от проекта.
Если быстро растет объем данных, можно изменить архитектуру хранения. Если база становится значимой частью нагрузки — рассмотреть ее отдельное размещение. Если container registry занимает сотни гигабайт, его хранилище тоже заслуживает отдельного внимания.
Но начинать с пяти серверов для команды из трех разработчиков обычно нет необходимости.
Простая инфраструктура легче восстанавливается и требует меньше обслуживания.
Как мониторить собственный Git-хостинг
Минимум нужно знать, работает ли веб-интерфейс и доступен ли Git по используемым протоколам.
На уровне сервера стоит следить за CPU, RAM и диском.
Свободное место особенно важно.
Исходный код может занимать немного, но CI-артефакты, container registry, Git LFS, вложения и backup способны расти намного быстрее.
Не стоит ждать сообщения разработчика «push не проходит», чтобы узнать о заполненном диске.
Мониторинг должен предупредить заранее.
Полезно следить и за сроком действия TLS-сертификата, если его обновление по какой-то причине не полностью автоматизировано.
Для более крупной установки появляются метрики самой платформы, базы данных, очередей и runners.
Но маленькому Git-серверу не обязательно сразу строить огромную систему наблюдаемости.
Начните с показателей, которые позволяют обнаружить наиболее вероятные проблемы.
Что проверить перед покупкой хостинга для Git
Сначала определитесь с платформой.
Требования небольшого Forgejo и большой установки GitLab могут различаться настолько сильно, что искать абстрактный «лучший VPS для Git» без этого решения почти бессмысленно.
После выбора ПО я бы проверила:
- полноценный root-доступ;
- поддерживаемые операционные системы;
- соответствие ресурсов официальным требованиям выбранной Git-платформы;
- количество CPU;
- объем оперативной памяти;
- SSD или NVMe;
- доступный объем диска;
- возможность расширения хранилища;
- стоимость дополнительного дискового пространства;
- лимиты и стоимость сетевого трафика;
- наличие IPv4 и IPv6, если они нужны;
- возможность настройки firewall;
- приватную сеть между VPS;
- поддержку snapshots;
- резервное копирование;
- возможность хранить backup отдельно;
- мониторинг сервера;
- доступность Docker, если выбран контейнерный способ установки;
- возможность быстро увеличить RAM и CPU;
- доступность дополнительных VPS для CI runners;
- географию дата-центров;
- качество технической поддержки.
Если планируется Git LFS или container registry, отдельно оцените будущий объем хранилища.
Пятьдесят гигабайт для обычных репозиториев могут казаться огромным запасом, но для Docker-образов и больших бинарных файлов это уже совсем другой масштаб.
Еще один момент — snapshots.
Снимок VPS удобен перед серьезным обновлением, но не должен становиться единственным способом резервирования Git-сервера.
Независимый backup важных данных все равно нужен.
Какой хостинг для Git выбрать в итоге
Если вам просто нужны приватные Git-репозитории и нет особых требований к размещению данных, сначала стоит сравнить собственный сервер с готовыми Git-сервисами.
Self-hosted инфраструктура дает больше контроля, но этот контроль приходится обслуживать.
Когда собственный Git действительно нужен, обычный VPS чаще всего является наиболее понятной отправной точкой.
Для небольшой команды Gitea или Forgejo могут оказаться удобнее тяжелой платформы. Они требуют меньше ресурсов и предоставляют основные возможности для совместной работы с кодом.
GitLab стоит рассматривать, когда нужны именно его более широкие возможности и команда готова выделить соответствующие серверные ресурсы.
Не выбирайте VPS только по количеству репозиториев.
Смотрите на их размер, количество пользователей, Git LFS, CI/CD, container registry и другие сервисы вокруг Git.
Особенно внимательно оценивайте runners. Тяжелая сборка способна потреблять больше CPU и RAM, чем сам Git-сервер. Если CI начинает мешать работе репозиториев, runner логично вынести на отдельную машину.
Не экономьте на резервном копировании.
Git распределенный, и локальные копии разработчиков действительно повышают шансы сохранить исходный код. Но они не содержат всю информацию GitLab, Gitea или Forgejo.
Полноценный backup должен учитывать репозитории, базу данных, пользователей, настройки, LFS, вложения и другие важные компоненты платформы.
Следите за диском. Для Git-хостинга именно хранилище часто растет незаметнее всего: сначала несколько репозиториев, затем LFS, артефакты CI, Docker-образы и резервные копии.
И не стройте сложную инфраструктуру заранее.
Одна Gitea на одном VPS способна быть отличным Git-хостингом для небольшой команды. GitLab и runner тоже могут первое время находиться рядом, если сервер справляется с нагрузкой.
Когда проект вырастет, CI можно вынести отдельно, увеличить хранилище, разделить базу и приложение или построить более сложную инфраструктуру.
Хороший собственный Git-сервер — это не тот, где используется больше всего DevOps-инструментов. Это сервер, который надежно хранит код, быстро выполняет обычные операции, имеет понятную систему доступа, регулярно резервируется и не требует от команды больше времени на обслуживание, чем приносит пользы.
