Self‑hosted Git на VDS: Gitea, GitLab CE и Forgejo для команд и pet‑проектов

Self-hosted Git на собственном VDS давно перестал быть игрушкой для параноиков. Это нормальная практика для команд, которые хотят контролировать доступ, хранить код на своих серверах, спокойно интегрировать CI/CD и не зависеть от внешних SaaS. Сегодня три самых популярных варианта для приватного Git-сервера: Gitea, GitLab Community Edition и Forgejo.

В этой статье разберём, чем они отличаются, на каких сценариях каждый выигрывает, что учитывать при выборе VDS и как не загнать себя в угол вопросами обновлений и бэкапов.

Зачем вам self‑hosted Git вообще нужен

Прежде чем сравнивать Gitea, GitLab и Forgejo, полезно честно ответить себе: а зачем вообще тянуть Git-сервер к себе на VDS, когда есть облачные решения?

Чаще всего self-hosted Git выбирают по одной или нескольким причинам:

• Чувствительные данные. Код нельзя выносить во внешний облачный сервис (ограничения заказчика, комплаенс, внутренняя политика).
• Изоляция от внешних зависимостей. Хочется, чтобы разработка продолжалась даже при проблемах у крупных провайдеров.
• Точная интеграция в инфраструктуру. Локальный LDAP/AD, собственный SMTP, внутренние Docker/CI-раннеры, доступ только через VPN и т.д.
• Стоимость и предсказуемость. Для команд из 5–20 человек SaaS-подписки иногда оказываются дороже простого VDS, особенно если нужен приватный CI.
• Гибкость. Возможность включать и выключать фичи, добавлять плагины, подстраивать хуки, стандарты ветвления, политики хранения артефактов.

Если вы админ или devops для небольшого отдела, агентства или продукта, то один-единственный VDS с Git-сервером часто становится ядром внутренних процессов: от код-ревью до авто-деплоев на staging и production.

Краткий обзор: Gitea, GitLab CE и Forgejo

Все три решения решают одну задачу — хостинг Git‑репозиториев, но делают это по-разному по части архитектуры, нагрузки и экосистемы.

Gitea

Gitea — лёгкий, написанный на Go Git-сервер с веб-интерфейсом, поддержкой pull/merge запросов, issues, wiki, базовых pipelines и контейнерного реестра (в новых версиях). Основные плюсы:

• Малые требования к ресурсам. Стабильно живёт на небольших VDS, включая 1–2 vCPU и 1–2 ГБ RAM для небольшой команды.
• Простая установка. Один бинарник, минимальная зависимость от сторонних сервисов (можно начать даже с SQLite).
• Понятная модель администрирования. Конфиг в виде INI/YAML, простой процесс обновления, предсказуемое хранение данных.

Минусы Gitea:

• CI функционально проще и более «ручной», чем у GitLab.
• Меньше готовых интеграций и плагинов.
• Некоторые фичи ещё в активной доработке, API иногда догоняет UI по функциональности.

GitLab Community Edition

GitLab CE — тяжёлая, но мощная платформа «всё в одном»: Git, CI/CD, контейнерный реестр, управление задачами, релизами, security‑сканами и много всего ещё.

Плюсы GitLab CE:

• Самый мощный CI/CD из коробки. GitLab Runner, pipelines, environments, approvals, автодеплой — всё в одной экосистеме.
• Развитый интерфейс для управления проектами. Эпики, борды, milestone’ы, релизы, интеграции с внешними трекерами.
• Большое сообщество и документация. Легко найти ответы на типовые вопросы и готовые рецепты.

Основные минусы GitLab CE для self‑hosted на VDS:

• Ресурсоёмкость. Для комфортной работы даже небольшой команды нужен заметный запас по CPU, RAM и диску.
• Сложность администрирования. Много компонентов: PostgreSQL, Redis, Sidekiq, Gitaly и т.д. Обновления тоже требуют аккуратности.
• Сложнее мигрировать. Перенос на другие решения — не мгновенный процесс.

Forgejo

Forgejo — форк Gitea, который ставит упор на действительно открытое управление проектом, независимость от коммерческой компании и прозрачное развитие.

Что важно понимать о Forgejo:

• По архитектуре и коду он очень близок к Gitea (исторически это форк), поэтому требования к VDS и подходы к администрированию похожи.
• Некоторые фичи появляются раньше или реализованы чуть иначе, чем в Gitea, но общая модель схожа: лёгкий бинарник, понятный конфиг, MySQL/PostgreSQL/SQLite.
• Выбор Forgejo часто продиктован не техническими, а организационными соображениями: доверие к roadmap, governance, прозрачность принятия решений.

С практической точки зрения для администратора VDS Forgejo — это «ещё один лёгкий self‑hosted Git-сервер уровня Gitea», который стоит рассматривать в том же классе решений.

Выбор VDS под self‑hosted Git

Git‑сервер, особенно если на нём крутится ещё и CI/CD, — это не просто «ещё один веб-проект». Он активно шлёпает по диску, создаёт много маленьких файлов, хранит артефакты сборок и ведёт логи. Поэтому выбор параметров VDS сильно влияет на комфорт работы команды.

CPU и RAM

Условно можно выделить три уровня нагрузки, если говорить о Gitea/Forgejo/GitLab CE:

• Pet‑проект или 2–3 разработчика, без тяжёлого CI.
  Gitea или Forgejo: 1–2 vCPU, 1–2 ГБ RAM вполне достаточно. GitLab CE на такой конфигурации будет страдать.
• Небольшая команда 5–15 человек, лёгкий или внешний CI.
  Gitea/Forgejo комфортно чувствуют себя на 2–4 vCPU и 4 ГБ RAM. GitLab CE лучше стартовать хотя бы с 4 vCPU и 8 ГБ RAM.
• Активный CI/CD и десятки проектов.
  Для GitLab CE планируйте 8+ ГБ RAM и 4+ vCPU только под «core» (без CI-раннеров). CI-раннеры лучше выносить на отдельные машины.

Диск и файловая система

Git любит быстрый диск с низкими задержками. Клонирование, fetch/pull, создание и слияние веток — всё это постоянно читает и пишет мелкие файлы.

Рекомендации по диску:

• SSD по умолчанию. HDD стоит рассматривать только как холодное хранилище бэкапов.
• Запас по объёму. Учтите, что:

Репозиторий с монолитным приложением, несколькими ветками и долгой историей легко раздувается в несколько раз относительно размера актуального кода. Плюс артефакты CI и контейнерные образы.

• Для маленькой команды стоит сразу смотреть в район 80–120 ГБ, даже если сейчас кода немного.
• Отдельный раздел под данные. Удобно, когда можно перенести каталог данных (репозитории, БД, аплоады) на другой диск или в снапшот, не трогая систему.

Сеть и доступ

Self‑hosted Git — это сервис, к которому разработчики обращаются по SSH и HTTPS постоянно: пуши, пуллы, CI‑триггеры, вебхуки.

Минимальный набор требований к сети:

• Стабильный канал с нормальной латентностью до офисов и домашних сетей, где сидят разработчики.
• Возможность открыть SSH‑порт (обычно 22 или кастомный) и HTTPS‑порт (443), настроить firewall и, при необходимости, доступ по VPN.
• Выделенный IP, если планируете настроить собственный домен и TLS‑сертификат (что желательно в проде).

Сценарии выбора: когда Gitea, когда GitLab, когда Forgejo

Выбор между Gitea, GitLab CE и Forgejo лучше привязывать не только к «нравится UI», но и к конкретным сценариям использования.

Когда логичен выбор Gitea

Gitea чаще всего оказывается оптимальным, если вы хотите:

• Быстро поднять Git‑сервер на небольшом VDS и не тратить много времени на администрирование.
• Хранить приватные репозитории для небольшой команды и иметь удобное веб‑UI для ревью.
• Использовать внешний CI (например, Drone CI, Woodpecker, Jenkins) или простые вебхуки.
• Иметь разумный баланс между функциональностью (issues, wiki, PR/merge requests, контейнерный реестр) и лёгкостью.

Если у вас уже есть настроенный CI (Ansible, rsync‑деплой, отдельный Jenkins), Gitea отлично работает как «точка правды» для кода и триггер для пайплайнов.

Когда оправдано тянуть GitLab CE

GitLab CE имеет смысл поднимать, когда:

• Команда привыкла к GitLab.com и хочет «то же самое, только локально».
• Нужен мощный встроенный CI/CD с pipeline’ами, environment’ами, review apps, ручными job’ами и гибкой матрицей.
• Есть много смежных процессов: релизы, планирование работ, security‑сканы, контейнерный реестр, управление пакетами.
• Готовы тратить время на администрирование: обновления, мониторинг компонентов, бэкапы PostgreSQL и Redis.

GitLab CE — это скорее «self‑hosted Git‑платформа» для продуктовых команд и компаний с плотным процессом разработки, чем просто сервер Git‑репозиториев.

Когда присмотреться к Forgejo

Forgejo имеет смысл рассматривать как альтернативу Gitea, если:

• Важна модель управления проектом: вы хотите, чтобы ключевые решения по развитию принимались сообществом, а не коммерческой компанией.
• Нравится архитектура Gitea, но вы больше доверяете roadmap и governance Forgejo.
• Хотите участвовать в развитии проекта и рассчитываете на более «комьюнити‑ориентированный» подход к фичам.

С точки зрения требований к VDS и практического администрирования Forgejo и Gitea можно рассматривать в одном классе решений: лёгкие, быстрые, дружелюбные к небольшим серверам.

Ключевые практические вопросы self‑hosted Git

Как только вы выбрали движок (Gitea, GitLab CE или Forgejo) и VDS, дальше начинается рутина: установка, обновления, резервные копии, мониторинг и безопасность. Здесь у админов и devops‑ов почти всегда одни и те же вопросы.

Где хранить данные и как их бэкапить

Самая важная часть любого Git‑сервера — это не бинарники и не конфиг, а:

• Git‑репозитории (директории с bare‑репами, обычно под общим корнем вроде repositories или data/git/repositories).
• База данных (PostgreSQL/MySQL/SQLite), где хранятся пользователи, issues, PR/merge requests, настройки проектов.
• Файловые аплоуды, артефакты CI, вложения к задачам (если включены).

Базовые принципы бэкапов:

• Разделяйте «горячие» и «холодные» копии. Минимум — ежедневный дамп БД и rsync/копирование каталога с репозиториями на отдельное хранилище.
• Проверяйте восстановление. Один раз разверните отдельный тестовый VDS и попробуйте выполнить полный restore по инструкции. Лучше поймать проблемы сейчас, чем во время инцидента.
• Не держите единственную копию бэкапа на том же диске. Если VDS или диск выйдет из строя, бэкапы должны быть доступны отдельно.

Для GitLab CE критически важно корректно бэкапить PostgreSQL и конфиг; для Gitea и Forgejo проще сделать несколько rsync‑снимков каталога данных плюс дамп БД, но логику восстановления всё равно стоит зафиксировать в документации.

Обновления: как не сломать всё разом

Self‑hosted Git живёт годами. Версии выходят регулярно, и рано или поздно обновляться всё равно придётся — если не из‑за новых фич, то из‑за безопасности.

Рекомендации по обновлениям:

• Не прыгайте через несколько мажоров. У GitLab CE, Gitea и Forgejo есть официальные матрицы совместимости и пути миграций. Следуйте им, особенно при переходе между мажорными версиями.
• Читайте release notes. Перед апдейтом обратите внимание на breaking changes: формат БД, пути к каталогам, изменения в конфиге.
• Делайте снапшот или бэкап перед обновлением. Минимум — дамп БД и копия каталога с данными. Идеально — снапшот диска VDS, если платформа это позволяет.
• Тестируйте на staging. Если у вас много проектов и пользователей, имеет смысл держать небольшой тестовый инстанс с копией данных и сперва обновлять его.

Практика показывает, что лёгкие решения вроде Gitea/Forgejo обновлять проще и менее рискованно, а GitLab CE требует аккуратного соблюдения документации по апдейту. Хорошая стратегия — описать процедуру обновления в своём internal runbook’е и хранить его в отдельном репозитории (да, желательно не на том же Git-сервере).

Безопасность: доступ, SSH и внешние интеграции

Git‑сервер — критичная часть инфраструктуры. Компрометация этого узла означает потенциальный доступ к коду, секретам в репозиториях и конфигах деплоя. Если вы уже строите GitOps‑подход и храните зашифрованные секреты в Git, имеет смысл дополнительно посмотреть материалы по безопасному хранению ключей и автоматизации, например статью о шифровании секретов в GitOps-процессах.

Минимальный чек‑лист по безопасности self‑hosted Git‑сервера на VDS:

• SSH‑ключи и пароли. Запретите логин по паролю для системных пользователей, используйте SSH‑ключи и отдельного пользователя для деплоя.
• HTTPS и корректные сертификаты. Не отправляйте логины/пароли и токены по HTTP. Настройте TLS‑сертификат и перенаправление с HTTP на HTTPS. Для продакшн-среды стоит заранее позаботиться о надёжных SSL-сертификатах.
• Ограничьте доступ по IP или VPN. Если это чисто внутренний Git‑сервер, можно закрыть доступ из внешнего интернета и выдавать его только по VPN или через bastion‑хост.
• Масштаб пермишенов. Настройте политику: кто может создавать группы, публичные проекты, SSH‑ключи деплоя и токены. Лишнего лучше запретить.
• Логи и аудит. Желательно настроить сбор логов (аутентификация, пуши) во внешнюю систему логирования или хотя бы ротацию и хранение на отдельном разделе.

Типовые devops‑сценарии с self‑hosted Git

Обычно Git‑сервер не живёт в вакууме. С ним связаны CI/CD, деплой на прод/стейджинг, мониторинг и интеграции с другими сервисами.

CI/CD: встроенный и внешний

Если брать три наши системы:

• GitLab CE — даёт мощный встроенный CI/CD. Вы подключаете GitLab Runner (на этом же или других VDS), описываете пайплайны в .gitlab-ci.yml и получаете полный цикл: тесты, сборка, деплой.
• Gitea — имеет свой Actions‑подобный функционал, но он проще и менее «индустриальный», чем у GitLab. Зато есть вебхуки и неплохой API, поэтому легко завести Drone CI, Woodpecker, Jenkins и любые внешние пайплайны.
• Forgejo — по возможностям близок к Gitea, в том числе с точки зрения интеграции с внешним CI и наличия собственного функционала пайплайнов.

Практически это означает:

• Если вы хотите «всё в одном месте» и готовы жить в экосистеме GitLab, GitLab CE + GitLab Runner — логичный выбор.
• Если у вас уже есть выстроенный CI (Ansible, Jenkins, сторонний SaaS) или вы любите более Unix‑подобный подход («делай одну вещь, но хорошо»), Gitea или Forgejo плюс внешний CI будут удобнее и легче по ресурсам.

Деплой на staging и production с self‑hosted Git

Self‑hosted Git на VDS удобно использовать как единую точку для деплоя на другие сервера:

• Через CI (GitLab CI, Gitea/Forgejo actions, Jenkins). При пуше в определённую ветку запускается пайплайн, который выкатывает обновление на staging или production.
• Через Git hooks (post‑receive). После получения пуша скрипт на стороне Git‑сервера инициирует деплой (rsync, systemd‑юнит, запуск Ansible‑плейбука).
• Через pull‑модель на целевом сервере (например, cron или systemd‑timer, который делает git fetch и выкатывает новый тег, если он появился).

В любом сценарии self‑hosted Git даёт вам:

• Единый источник правды по коду и релизам (ветки, теги, релизы).
• Журнал событий: кто, когда и что задеплоил, с каким коммитом.
• Возможность жёстко ограничить, кто может пушить в production‑ветку.

При сложных миграциях приложений удобно заранее держать Git‑репозитории, пайплайны и скрипты деплоя в порядке. Если планируется перенос приложений между серверами или типами хостинга, посмотрите также материал о миграции проектов без простоя — он хорошо сочетается с практикой использования self-hosted Git как центра оркестрации.

Интеграции: трекеры, чат, мониторинг

Современные Git‑платформы редко живут в одиночестве. После развёртывания вы почти всегда захотите подключить:

• Вебхуки в CI‑систему, таск‑менеджер или деплой‑сервис.
• Интеграцию с чатами (уведомления в мессенджеры о новых MR/PR, фейлах сборок, релизах).
• Мониторинг (метрики и алерты по состоянию сервиса, времени ответа и ошибкам).

По уровню «из коробки» интеграций GitLab CE традиционно впереди, но Gitea и Forgejo покрывают большую часть потребностей за счёт вебхуков, API и плагинов. Для простых сценариев достаточно отправки уведомлений по вебхуку, а метрики можно собрать стандартными экспортерами и завести в привычный стек мониторинга.

Итог: как принять решение и не пожалеть через год

Если свести всё к практическому чек‑листу для администратора или devops‑а, который выбирает self‑hosted Git на VDS, получится примерно следующее:

• Нужен лёгкий, простой в администрировании Git‑сервер для небольшой команды или pet‑проектов, CI уже есть или не критичен — разумнее начать с Gitea или Forgejo.
• Нужен мощный встроенный CI/CD и максимум фич «всё в одном», команда готова жить в экосистеме GitLab и есть ресурсы на администрирование — можно брать GitLab CE.
• Если важна именно открытость управления проектом и независимость от конкретной компании — присмотритесь к Forgejo как альтернативе Gitea.

За любым выбором остаётся инфраструктурная дисциплина: регулярные бэкапы, план обновлений, ограничения по доступу и мониторинг. Тогда ваш self‑hosted Git не станет ещё одним «сервером, который никто не трогает, потому что страшно», а будет надёжным и предсказуемым компонентом devops‑ландшафта.

Главное — думать не только о том, как быстро поднять Git‑сервер сегодня, но и как вы будете жить с ним через год: переносить, обновлять и масштабировать без боли. Для старта достаточно аккуратно подобранного VDS, базового чек‑листа по безопасности и понятной стратегии бэкапов — остальное всегда можно дорастить по мере роста команды и проектов.