Git, GitHub, GitLab и аналоги: что развернуть для одного пользователя или небольшой команды

Введение

GitHub и GitLab давно стали привычной средой для работы с исходным кодом: репозитории, pull request, CI/CD, реестры пакетов. Но за облачные сервисы платят по подписке, а данные живут на чужих серверах. Для одного разработчика или команды из нескольких человек часто разумнее развернуть собственный git-сервер — бесплатно, под своим контролем, с доступом только для своих людей.

В этой статье разберём, что такое Git и как он соотносится с GitHub/GitLab, какие решения можно поднять самостоятельно, чем они отличаются по ресурсам и функциям, и как выбрать подходящий вариант под конкретную задачу. Особое внимание — Gitea, Forgejo и GitLab Community Edition: именно на них приходится львиная доля self-hosted-развёртываний в 2026 году.

Git, GitHub, GitLab: что есть что

Начнём с терминологии, потому что её часто путают.

Git — это распределённая система контроля версий, утилита командной строки, которая живёт на вашем компьютере. Она хранит историю коммитов локально в каждом клоне репозитория и умеет синхронизироваться с любым удалённым сервером по протоколу Git (HTTP/S или SSH). Сам по себе Git — не веб-сервис: у него нет браузера, pull request'ов и дашборда.

GitHub — это облачный сервис от Microsoft, который поверх Git строит платформу для командной работы: веб-интерфейс, pull request, issues, действия (CI/CD), реестры пакетов, Actions. Вы не устанавливаете GitHub — вы регистрируетесь на сайте и пользуетесь чужой инфраструктурой.

GitLab — аналогичная платформа, но с открытым исходным кодом (Community Edition) и возможностью self-hosting: её можно развернуть у себя на сервере и получить «свой GitHub» со встроенным CI/CD, реестром контейнеров и сканерами безопасности.

💡 Практическая выгода self-hosting: код не покидает вашу инфраструктуру (важно для коммерческой тайны), нет платы за подписку, а скорость операций зависит от вашей сети, а не от загрузки чужого CDN. Для небольших команд это экономит и деньги, и риски утечки.

Почему стоит свой git-сервер

Основные сценарии, в которых собственный сервер выигрывает у облака:

1. Конфиденциальность кода. Коммерческий продукт или внутренний инструмент не должны лежать на стороннем хостинге.

2. Стоимость. Облачные планы начинаются от нескольких долларов за пользователя в месяц; при росте команды сумма растёт линейно. Self-hosted-варианты бесплатны — платите только за VPS или сервер.

3. Автономность. Нет зависимости от чужих сбоев, лимитов API и изменений ценообразования.

4. Контроль над данными. Бэкапы, миграции, права доступа — всё под вашим управлением.

⚠️ Важно понимать: self-hosting перекладывает на вас ответственность за безопасность, обновления и бэкапы. Неправильно настроенный сервер с открытым доступом к репозиториям — это та же утечка, только ваша. Для продакшн-решений рекомендуется привлечение специалистов: корректная настройка TLS, прав доступа, резервного копирования и мониторинга снижает риски, которые «вайб-развёртывание» по туториалу не закрывает.

Обзор решений для self-hosting

Рассмотрим основные варианты, доступные в 2026 году.

Gitea: лёгкий стандарт де-факто

Gitea — самохостинг git-сервис на языке Go, запущенный в 2016 году как форк Gogs. Его девиз — «Git with a cup of tea»: цель проекта всегда была простой — маленький, быстрый сервер с интерфейсом, похожим на GitHub, который можно поднять даже на Raspberry Pi.

Ключевые характеристики:

• Язык: Go, единый бинарный файл или Docker-контейнер

• Лицензия: MIT

• Минимальные ресурсы: ~512 МБ RAM; свежая установка потребляет около 150 МБ в простое, загрузка с SQLite — менее секунды

• Функции: pull request, issues, wiki, release, code review, интеграции

• Gitea Actions (с v1.21): совместимый с GitHub Actions раннер — ваш .github/workflows/ci.yml переносится в .gitea/workflows/ci.yml почти без изменений

• Реестры пакетов: npm, Maven, Container, Helm и другие

• Базы данных: SQLite (по умолчанию), MySQL/MariaDB, PostgreSQL

Для команды из 5 человек, пишущей на Go или Node.js, Gitea — как правило, всё, что нужно. UI давно перестал быть «упрощённым GitHub» и предлагает сопоставимый набор функций.

💡 Совет: если планируете CI с реальными нагрузками, вынесите раннеры Actions на отдельную машину и зарегистрируйте их удалённо. По умолчанию они делят ресурсы с самим Gitea, что может тормозить веб-интерфейс во время сборки.

Forgejo: community-форк с упором на независимость

Forgejo — hard fork Gitea, созданный в конце 2022 года (первый публичный релиз — декабрь 2022) после того, как проект Gitea был передан под управление коммерческой компании. Авторы форка хотели сохранить git-сервер в руках некоммерческого сообщества. Проект развивается под эгидой non-profit организации Codeberg e.V., а хостинг основного репозитория — на собственной платформе Codeberg, а не GitHub.

Отличия от Gitea:

• Лицензия: AGPLv3+ (copyleft); файлы, пришедшие из Gitea, остаются под MIT

• Управление: некоммерческая организация, ежеквартальные встречи контрибьюторов, прозрачный roadmap

• Функциональность: ~95% кодовой базы совпадает с Gitea; различия — в управлении и отдельных решениях по приватности

• Ресурсы: те же что у Gitea (Go, ~512 МБ RAM минимум)

Выбор между ними во многом идеологический: если важна независимость от коммерческой компании и copyleft-лицензия — Forgejo; если важнее активный upstream с более быстрым набором фич — Gitea. Для типовой команды из 1–10 человек функциональная разница минимальна.

⚠️ Нюанс миграции: между Gitea и Forgejo миграция не тривиальна — это разные кодовые базы после hard fork. Если сомневаетесь в выборе, протестируйте оба на копии репозиториев перед переездом.

GitLab Community Edition: all-in-one платформа

GitLab CE — совсем другой класс продукта. Это не просто git-сервер, а полная DevOps-платформа: git + CI/CD + реестр контейнеров + issues + wiki + сканеры безопасности (SAST/DAST) + интеграция с Kubernetes. Community Edition бесплатна и open source; Enterprise добавляет seat-based платные функции.

Характеристики:

• Стек: Ruby on Rails, Postgres, Redis, Gitaly, Sidekiq workers

• Минимальные ресурсы: 4 ГБ RAM (официальный минимум), на практике комфортно от 8 ГБ

• Установка: Omnibus-пакет или Docker Compose со множеством сервисов

• Для кого: команды от 20+ разработчиков, которым нужен единый инструмент для всего цикла разработки

GitLab имеет смысл, когда вы действительно используете встроенный CI, реестр и security-сканеры. Как «красивый git push» для трёх человек он неоправдан: RAM-бюджет в разы выше, чем у Gitea/Forgejo.

⚠️ Типичная ошибка: выбор GitLab «на вырост» по привычке из туториалов по CI. В итоге вы годами держите 4–8 ГБ простаивающей памяти, пользуясь только git-частью. Подбирайте инструмент под текущий размер команды, а не гипотетический рост.

Gogs: минимализм в чистом виде

Gogs — предшественник Gitea (сам Gitea начинался как его форк). Это максимально простой self-hosted git-сервис на Go: хостинг кода, pull request, issues, минимум настроек. Поддерживает запуск одним бинарником или Docker-контейнером.

Официальная позиция проекта — «невероятно низкое потребление ресурсов»: заявлена работоспособность даже при 64 МБ RAM и четверти vCPU. Gogs активно поддерживается, но развитие идёт медленнее, чем у Gitea: новых фич (Actions, реестры пакетов) здесь нет.

Gogs подходит, если нужен буквально только git-хостинг без лишнего — например, для личного бэкапа репозиториев или очень простой команды. Для всего остального Gitea/Forgejo дают больше за сопоставимые ресурсы.

Другие варианты кратко

• OneDev — self-hosted платформа со встроенным CI/CD и управлением проектами; Community Edition бесплатна, Enterprise — платно по числу пользователей.

• Gitness — современная dev-платформа с «Gitspaces» (код + CI + окружения разработки).

• cgit / gitweb — лишь веб-просмотр репозиториев без полноценного интерфейса; для одного пользователя, которому нужен только доступ «только на чтение» к своим репо.

• GitHub Enterprise Server — self-hosted версия GitHub; мощно, но дорого и ориентировано на enterprise-команды.

Сравнительная таблица

Как развернуть: базовые шаги

Разберём самый частый сценарий — Gitea в Docker Compose. Это применимо и к Forgejo (образ другой, конфигурация почти идентичная).

Вариант 1: быстрая установка одним бинарником

Для тестирования или одного пользователя проще всего скачать бинарник с официального сайта и запустить:

# Linux: распаковать архив и запустить один раз для генерации конфига
./gitea web

После первого запуска откройте браузер на порту 3000 — веб-мастер проведёт через настройку администратора, выбора базы данных (SQLite подходит для старта) и параметров. Весь процесс занимает несколько минут.

Вариант 2: Docker Compose для продакшена

Более надёжный вариант — контейнер с выделенным томом для данных:

# docker-compose.yml
services:
  gitea:
    image: gitea/gitea:latest
    restart: unless-stopped
    ports:
      - "3000:3000"   # веб-интерфейс
      - "2222:22"     # SSH для git clone/push
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__database__DB_TYPE=mysql
    volumes:
      - gitea-data:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    depends_on:
      - db

  db:
    image: mysql:8.0
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: change-me-root
      MYSQL_DATABASE: gitea
      MYSQL_USER: gitea
      MYSQL_PASSWORD: change-me-gitea
    volumes:
      - db-data:/var/lib/mysql

volumes:
  gitea-data:
  db-data:

Пояснения к конфигурации:

• USER_UID/USER_GID — права доступа к тому с данными; подставьте UID/GID пользователя, от которого работает Docker.

• База данных: для одного пользователя или пары репозиториев достаточно SQLite (тогда секцию db и строку DB_TYPE=mysql можно убрать). Для небольшой команды MySQL/MariaDB надёжнее при росте нагрузки.

• Порт 2222 — SSH, чтобы не конфликтовать с системным sshd на 22.

Запуск: docker compose up -d. После первого старта веб-мастер предложит создать администратора и заполнить базовые параметры.

Настройка за reverse proxy

Если сервер доступен по доменному имени, Gitea ставится за Caddy/Nginx/Traefik с TLS. Критически важный параметр — ROOT_URL в app.ini: он определяет, какой URL будет подставляться в webhooks и ссылки на репозитории. Неправильный ROOT_URL — самая частая причина «сломанных» webhook-уведомлений у новичков.

# app.ini (фрагмент)
[server]
  ROOT_URL = https://git.example.com/
  SSH_DOMAIN = git.example.com
  SSH_PORT = 22

💡 Совет по безопасности: ограничьте доступ к веб-интерфейсу и SSH списком IP или VPN, включите двухфакторную аутентификацию для всех пользователей. Открытый в интернет git-сервер без этих мер — прямой путь к компрометации кода.

Бэкапы

Минимум два объекта резервного копирования:

1. Том с данными (/data у Gitea) — содержит bare-репозитории, аватары, вложения.

2. База данных — dump через mysqldump / pg_dump (или backup-утилиту самого Gitea).

Настройте регулярный автоматический дамп на внешнее хранилище. Без бэкапов self-hosting превращается в способ гарантированно потерять код при сбое диска.

Как выбрать: практическая логика

Короткое правило выбора по размеру команды и задачам:

Дополнительные факторы:

• Миграция с GitHub: у Gitea и GitLab есть встроенные импортёры (репозитории, issues, PR, wiki, релизы). Учёт коммитов корректно привязывается к пользователям после их первого логина.

• Переезд из GitLab наружу — больнее всего: чистого one-shot импортёра в Gitea нет; репозитории клонируются скриптом, issues переносятся через API. Если есть вероятность покинуть GitLab в будущем, ранний переезд дешевле позднего.

• Ресурсы: не берите GitLab «на всякий случай» — разница в RAM (4–8 ГБ против 512 МБ) напрямую бьёт по стоимости инфраструктуры.

⚠️ Про безопасность ещё раз: выбор инструмента — лишь половина задачи. Вторая половина — корректная реализация: TLS, аутентификация, права доступа, бэкапы, обновления патчей. Поверхностное копирование конфигов из интернета без понимания edge-кейсов создаёт скрытые уязвимости. Для критичных проектов стоит привлекать специалистов — это инвестиция, которая окупается снижением риска утечки кода и простоя.

Заключение

Для одного пользователя или небольшой команды self-hosted git-сервер — практичное и экономичное решение. В 2026 году выбор фактически сводится к трём вариантам:

• Gitea — самый универсальный лёгкий вариант: GitHub-подобный опыт, Actions, реестры пакетов, ~512 МБ RAM. Хороший дефолт для команд до 30 человек.

• Forgejo — тот же функционал при упоре на независимое сообщество и copyleft-лицензию; выбор во многом идеологический.

• GitLab CE — полноценная DevOps-платформа, но требует 4–8 ГБ RAM и оправдана только при реальном использовании встроенного CI/реестра/сканеров командами от 20 разработчиков.

Gogs остаётся нишевым минималистичным вариантом для чистого git-хостинга. Ключевые шаги внедрения — Docker Compose с выделенным томом, корректный ROOT_URL за reverse proxy, двухфакторная аутентификация и регулярные бэкапы данных и базы.

Главное правило: подбирайте инструмент под текущий размер команды и реальные задачи, а не «на вырост». И помните — self-hosting перекладывает ответственность за безопасность на вас; для продакшн-инфраструктуры с критичным кодом разумно привлекать специалистов по настройке и защите.

Источники

• Gitea vs GitLab: Which Self-Hosted Git Server in 2026? — Elestio

• Forgejo — сравнение с Gitea

• Forgejo — Wikipedia (history, governance)

• Gitea vs Forgejo vs Gogs: Self-Hosted Git 2026 — PkgPulse

• 7 Best Open-Source GitHub Alternatives You Can Self-Host — Contabo

• Gogs: безболезненный self-hosted Git-сервис (официальная документация)