Gitea против GitLab: что выгоднее и когда

MAATRIX

Задача одна — свой git-сервер, — но решения разного веса: Gitea укладывается в один процесс и двести мегабайт памяти, GitLab CE поднимает полтора десятка служб и просит восемь гигабайт. Сравнение по спискам возможностей врёт: половина того, ради чего берут GitLab, в бесплатной редакции недоступна, а часть того, чего «нет в Gitea», там как раз есть. Разберём, Gitea или GitLab, по замерам и стоимости эксплуатации.

Что вы на самом деле выбираете: программа против дистрибутива

Главная разница не в фичах, а в форме поставки — из неё вытекает всё остальное. Gitea — один исполняемый файл на Go, около 120 МБ. Конфиг /etc/gitea/app.ini, данные в /var/lib/gitea, база на выбор: SQLite, PostgreSQL или MySQL. Один systemd-юнит, один процесс:

# systemctl status gitea
● gitea.service - Gitea (Git with a cup of tea)
     Active: active (running) since Fri 2026-08-21 09:14:02 UTC
     Memory: 186.4M

GitLab CE — не программа, а дистрибутив в deb-пакете. Пакет весит порядка 1,2 ГБ, разворачивается в /opt/gitlab примерно на 2,5 ГБ и приносит собственные PostgreSQL, Redis, Nginx и супервизор runit:

# gitlab-ctl status
run: gitaly: (pid 1994) 5240s
run: postgresql: (pid 1902) 5261s
run: puma: (pid 1961) 5247s
run: sidekiq: (pid 1972) 5244s

Полный список — 15 служб, до 19 с реестром образов и Pages, и обновляются они только вместе с пакетом. Лицензии у обоих MIT, но у GitLab всё интересное живёт в проприетарной EE.

Ресурсы: замер вместо обещаний из документации

«Минимум 4 ГБ RAM» из документации GitLab — формально правда, практически только с урезанным конфигом. Замеры машин в простое, без активных пайплайнов:

Четыре гигабайта расходятся так: puma с двумя воркерами — 1,6–2,0 ГБ, sidekiq — 700–950 МБ, prometheus с экспортёрами — 350–550 МБ, gitaly — 200–350 МБ, postgresql — около 200 МБ. Ужать это можно, и заметно, в /etc/gitlab/gitlab.rb:

puma['worker_processes'] = 2
puma['per_worker_max_memory_mb'] = 1024
sidekiq['max_concurrency'] = 9
prometheus_monitoring['enable'] = false
gitlab_rails['env'] = { 'MALLOC_ARENA_MAX' => '2' }

После sudo gitlab-ctl reconfigure расход падает до 2,8–3,2 ГБ — минус гигабайт ценой графиков и скорости фоновой обработки. И обязательно swap, минимум 2 ГБ: без него апгрейд на четырёхгигабайтной машине кончается строкой в dmesg:

Out of memory: Killed process 2731 (bundle) total-vm:3941204kB, anon-rss:1863452kB

Аппетит Gitea растят две вещи: REPO_INDEXER_ENABLED = true с bleve добавляет 200–600 МБ плюс место под индекс, раннер с Docker — ещё 200–350 МБ (сколько RAM нужно для Gitea). Ориентир: 2 vCPU и 4 ГБ тянут Gitea с Postgres, раннером и полусотней разработчиков — GitLab CE там откроется, но каждая сборка уйдёт в swap.

Функции: где Gitea хватает, а где нет

Сравнивать надо не «GitLab против Gitea», а GitLab CE против Gitea — то, что вы получите, не платя. Бесплатно есть у обоих: задачи и метки, пул-реквесты с ревью по строкам, защищённые ветки, вики, релизы, Git LFS, вебхуки, зеркалирование, LDAP, OAuth2 и OIDC, реестр пакетов и образов, двухфакторка.

Чего в Gitea нет вовсе:

• сканирования кода и зависимостей (SAST, DAST, secret detection);
• эпиков, дорожных карт, портфельного планирования;
• окружений с ручным подтверждением деплоя;
• аудит-лога: есть лента действий, а не журнал для комплаенса;
• GitLab Pages, Service Desk, агента для Kubernetes;
• поиска по коду уровня Elasticsearch: bleve находит подстроки, и только.

Встречное — чего вы не получите в бесплатном GitLab CE, хотя многие уверены в обратном: правил обязательных апрувов на merge request, принудительного CODEOWNERS, merge trains, синхронизации групп LDAP и SAML, поиска на Elasticsearch, полного аудит-лога. Всё это Premium — около 29 долларов за пользователя в месяц, то есть 3 500 в год на команду из десяти человек, и оплатить их из России в 2026-м отдельная задача.

Отсюда парадокс, переворачивающий выбор: обязательное число апрувов на защищённой ветке и CODEOWNERS в Gitea работают бесплатно, а в GitLab CE — нет. Если в чек-листе было «обязательные ревью перед мержем», Gitea закрывает его на голом MIT.

CI: Gitea Actions против GitLab CI

Здесь разрыв в зрелости самый большой, и его стоит признать честно.

Gitea Actions — реализация синтаксиса GitHub Actions. Файлы кладутся в .gitea/workflows/ci.yaml, выполняет их отдельный бинарник act_runner:

./act_runner register --no-interactive --instance https://git.example.com \
  --token <REGISTRATION_TOKEN> \
  --labels ubuntu-latest:docker://gitea/runner-images:ubuntu-latest

Грабля, на которую налетают почти все: Gitea по умолчанию тянет экшены со своего зеркала gitea.com, и если нужного там нет, job падает сразу:

Unable to resolve action `actions/checkout@v4`, repository not found

Лечится в app.ini, после чего сервер обязан свободно ходить на github.com:

[actions]
ENABLED = true
DEFAULT_ACTIONS_URL = github

Следствие для локации прямое: с российского адреса такой поход работает через раз, и чинить вы будете не пайплайн, а доступ (Gitea Actions не запускаются). Матрицы, сервисные контейнеры, needs:, кэш и секреты организации работают нормально; переиспользуемые workflow и OIDC-федерация в облака — нет. И actions/upload-artifact@v4 требует свежего сервера: на старых ветках шаг выгрузки отдаёт 404.

GitLab CI — другой класс инструмента: .gitlab-ci.yml, исполнители shell, docker и kubernetes, rules: с полноценными условиями, DAG через needs:, отчёты JUnit и покрытия в merge request, окружения и review apps. С версии 16.0 раннер регистрируется командой gitlab-runner register --url https://gitlab.example.com --token glrt-…, а старый --registration-token не принимается.

Общее правило для обоих: раннер держите на отдельной машине (настройка GitLab CI-раннера). Сборка Next.js на двух ядрах занимает около пяти минут и забирает процессор целиком: рядом с git это тормозящий веб-интерфейс и push.

Эксплуатация: обновления, бэкапы и что ломается

Разница в сопровождении даже больше, чем в памяти. Обновление Gitea — замена файла:

systemctl stop gitea && mv /usr/local/bin/gitea /usr/local/bin/gitea.prev
curl -fsSL -o /usr/local/bin/gitea https://dl.gitea.com/gitea/1.25.2/gitea-1.25.2-linux-amd64
chmod +x /usr/local/bin/gitea && systemctl start gitea

Миграции проходят за секунды, простой — 5–10 секунд. Откат честно ограничен: вернуть прежний бинарник можно, только пока миграции не отработали; после мажорного апгрейда это уже восстановление из дампа.

Обновление GitLab — процедура. Прыгать через версии нельзя, есть обязательный upgrade path (например, 17.11 → 18.0 → 18.5 → 19.0), и между шагами должны доехать фоновые миграции: Admin → Monitoring → Background Migrations, пока список не опустеет, иначе следующий шаг падает на проверке. Каждый шаг — apt install gitlab-ce=<версия> и gitlab-ctl reconfigure на 4–10 минут простоя.

Бэкапы тоже разного веса:

# Gitea: строго от пользователя git, иначе дамп ляжет с правами root
sudo -u git /usr/local/bin/gitea dump -c /etc/gitea/app.ini -f /var/backups/gitea-$(date +%F).zip
# GitLab: архив и — обязательно отдельно — секреты
sudo gitlab-backup create STRATEGY=copy
sudo cp /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab.rb /secure/backup/

Классическая катастрофа: восстановили tar без gitlab-secrets.json. Репозитории на месте, а CI-переменные, интеграции и секреты 2FA расшифровать нечем — в логах OpenSSL::Cipher::CipherError, и перезаводить их придётся руками. У Gitea то же в миниатюре: отдельно унесите app.ini с SECRET_KEY и INTERNAL_TOKEN (бэкап всего сервера целиком).

И две мелочи из практики. /var/opt/gitlab за полгода набирает 30–60 ГБ артефактов и слоёв образов — уборка через sudo gitlab-ctl registry-garbage-collect. А «Whoops, GitLab is taking too much time to respond» — не поломка, а puma: она либо ещё стартует после reconfigure, либо упёрлась в память; смотрите sudo gitlab-ctl tail puma, а не логи Nginx.

Таблица и честный вывод: Gitea или GitLab

Берите Gitea, если команда до полусотни человек; нужен приватный git с ревью и защищёнными ветками; каждый гигабайт на счету; вы не хотите тратить вечера на upgrade path; CI простой — собрать, прогнать тесты, задеплоить по SSH. Здесь GitLab даёт то же самое за десятикратный расход памяти.

Берите GitLab, если пайплайны сложные: окружения, ручные подтверждения деплоя, отчёты о покрытии в merge request, десятки джобов с зависимостями; нужен комплаенс и аудит; вы готовы платить за Premium. Его покупают ради процесса, а не ради хранения кода.

Не берите ни то, ни другое, если вы один: bare-репозиторий и SSH-ключи — ноль обслуживания.

И про цену ошибки: направления переезда неравноценны. GitLab → Gitea проходит штатно: импорт по токену забирает репозиторий, задачи, комментарии, метки, вехи, релизы и вики. Обратный путь хуже — импортёр из Gitea в GitLab умеет мало, надёжнее git push --mirror плюс перенос задач через API. Сомневаетесь — начинайте с Gitea.

Какой сервер взять в MAATRIX под Gitea или GitLab

Нагрузка у git-сервера неровная: почти всё время простой, а в момент git push и сборки нужны и диск, и процессор.

Gitea, минимум: 1 vCPU, 2 ГБ RAM, 20–40 ГБ NVMe. Хватает команде до 10–15 человек на SQLite. Ограничение честное: раннер здесь не запускайте и индексатор кода не включайте — первая же сборка выест память, а git gc на большом репозитории добьёт остаток.

Gitea, комфортный вариант: 2 vCPU, 4 ГБ RAM, 80 ГБ NVMe. PostgreSQL рядом, act_runner с Docker, поиск по коду, полсотни разработчиков и место под LFS и образы.

GitLab CE, честный минимум: 4 vCPU, 8 ГБ RAM, 100 ГБ NVMe и swap на 4 ГБ. Четыре гигабайта из документации работают только с урезанным gitlab.rb из второго раздела и без раннера рядом; раннеры выносите отдельно — 2–4 vCPU и 4–8 ГБ по тяжести сборок.

Локация — Лондон, по двум причинам. Круговая задержка Москва — Лондон держится в районе 45–60 мс: git push субъективно мгновенный, ревью в вебе не отличается от локального. Важнее вторая: сервер с CI постоянно ходит наружу — github.com за экшенами, ghcr.io и Docker Hub за образами, npm, PyPI. Британская площадка ходит туда без ухищрений, и локация здесь экономит не миллисекунды, а часы отладки. Франция равноценна для команды в континентальной Европе, Россия — когда код обязан оставаться в РФ по 152-ФЗ, но тогда закладывайте зеркала реестров.

Gitea есть в каталоге apps.maatrix.io и разворачивается автоматически при заказе сервера — вставлять команды из этой статьи не нужно. Автоустановка работает на Ubuntu и Debian, адрес панели, логин и пароль появляются в личном кабинете в разделе «Доступ». GitLab так не поставить: берите чистую Ubuntu 24.04 и разворачивайте омнибус сами.

Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT: иностранная карта не нужна, даже когда сервер в Лондоне. Машину выбрать можно на странице аренды VPS, развёртывание по шагам — в статье как установить и настроить Gitea на VPS.

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