GitLab CE или Forgejo: что выгоднее и когда

MAATRIX

Команда выросла из бесплатных лимитов GitHub, а куда переезжать — не очевидно. GitLab CE знаком половине рынка и тянет за собой весь DevOps-цикл, но просит под себя приличный сервер и минуты на каждый рестарт. Forgejo — форк Gitea, который поднимается за секунды и почти не просит памяти, но моложе как платформа для CI. Разберём по фактам, где каждый вариант объективно выгоднее.

Откуда они взялись и чем отличаются по сути

GitLab CE — community-редакция коммерческой DevOps-платформы GitLab Inc. Модель open core: часть функций живёт в открытом ядре, часть — платно, в Premium и Ultimate. Пакет ставится как omnibus-дистрибутив: внутри свой PostgreSQL, Redis, Nginx, Gitaly и с десяток служб под управлением runit. Это не «программа», а мини-стек.

Forgejo — жёсткий форк Gitea, отделившийся в октябре 2022 года. Причина раскола была не техническая: часть сообщества не устроил переход Gitea под контроль коммерческой Gitea Ltd и связанные с этим вопросы лицензирования вклада. Forgejo развивается под некоммерческим Forgejo e.V. (Codeberg), с открытым голосованием по решениям. Технически это один бинарник на Go, конфиг в app.ini, база — SQLite, PostgreSQL или MySQL на выбор.

Практический вывод: GitLab CE — это установка целой платформы со своими зависимостями, Forgejo — установка одного сервиса. Разница в философии определяет всё остальное — ресурсы, скорость апдейтов, порог входа.

Сколько железа нужно на самом деле

Официальная документация GitLab называет для омнибус-установки минимум 4 GB RAM и 2 vCPU даже для небольшой команды — это не с запасом, а нижняя граница, при которой gitlab-ctl reconfigure вообще проходит без ошибок нехватки памяти. На практике комфортный порог для команды в 10-20 человек — 8 GB RAM, если параллельно крутятся CI-джобы на self-hosted раннере на том же сервере (что часто и делают на VPS).

Forgejo по документации проекта работает на 1 vCPU и 512 MB — этого достаточно для несколько сотен репозиториев без Actions. Если добавляете act_runner для Forgejo Actions на этом же сервере, закладывайте от 2 GB, потому что раннер поднимает контейнеры под каждую джобу.

Это ориентир по официальным рекомендациям, а не замер под конкретную нагрузку — у вас цифры сдвинутся в зависимости от числа проектов, параллельных CI-джоб и того, включён ли встроенный container registry.

Установка и повседневная эксплуатация

GitLab CE ставится одной командой из официального репозитория:

curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
sudo EXTERNAL_URL="https://git.example.com" apt install gitlab-ce

Первый gitlab-ctl reconfigure занимает 5-10 минут и создаёт полтора десятка процессов. Любое изменение конфига в /etc/gitlab/gitlab.rb требует повторного reconfigure — на VPS с медленным диском это ощутимая пауза. Обновление минорной версии — тоже apt upgrade + reconfigure, обычно без сюрпризов, но с риском словить долгую миграцию БД на major-версиях.

Forgejo в варианте docker compose поднимается так:

services:
  forgejo:
    image: codeberg.org/forgejo/forgejo:9
    environment:
      - USER_UID=1000
      - USER_GID=1000
    volumes:
      - ./data:/data
      - /etc/timezone:/etc/timezone:ro
    ports:
      - "3000:3000"
      - "222:22"

docker compose up -d — и сервис готов за несколько секунд. Обновление — смена тега образа и docker compose up -d заново, без отдельного шага пересборки конфигурации. Разница в скорости итерации ощутима, если вы держите dev-стенд и часто перезаливаете сервер: Ubuntu 24.04 с нуля под Docker — базовая подготовка сервера под оба варианта.

CI/CD: GitLab CI против Forgejo Actions

GitLab CI — зрелый инструмент с полноценным DAG между стадиями, кэшированием артефактов, rules/needs, поддержкой Docker, Kubernetes и shell-executor для self-hosted раннеров. Синтаксис .gitlab-ci.yml мощный, но и многословный — сложные пайплайны с матрицами и условными деплоями требуют времени на освоение.

Forgejo Actions появились позже (стабилизировались в 2023-2024) и намеренно совместимы по синтаксису с GitHub Actions: тот же uses: actions/checkout@v4, тот же формат workflow.yml в .forgejo/workflows/. Если команда уже писала пайплайны под GitHub — порог входа почти нулевой. Честная оговорка: экосистема моложе GitLab CI — часть сложных сценариев (глубокая визуализация пайплайна, богатые политики хранения артефактов, встроенные security-сканеры) либо не реализована, либо требует сторонних Actions с GitHub Marketplace, которые не всегда стабильно работают в самостоятельно хостящемся act_runner.

Раннер в обоих случаях нужен отдельный процесс — на том же VPS или на выделенной машине:

# GitLab: регистрация раннера
sudo gitlab-runner register --url https://git.example.com --token glrt-xxxx

# Forgejo: аналогично, но раннер отдельный проект
./forgejo-runner register --instance https://git.example.com --token xxxx

Подробнее по настройке раннера GitLab — gitlab-ci-cd-na-vps-nastrojka.

Что теряете и что не теряете при переходе на Forgejo

Не будет: встроенного Auto DevOps, Web IDE в браузере, полноценных Epics и roadmap-планирования (в CE их и так нет, это Premium), встроенного security-дашборда с агрегацией уязвимостей по проектам.

Останется рабочим: issues с метками и milestones, Kanban-доски, wiki на каждый репозиторий, pull request'ы с ревью и обязательными проверками, встроенный package registry (npm, Docker, Maven, generic) — та же логика, что и в GitLab CE, только без части UI-обвязки.

Плюс, которого нет у GitLab CE «из коробки» в обратную сторону: Forgejo умеет мигрировать репозитории напрямую из GitLab по URL и токену прямо через интерфейс создания нового репозитория — issues, PR-историю, вики и релизы переносит один визард, без отдельных скриптов на python-gitlab. Обратная миграция (Forgejo → GitLab) официального визарда не имеет, придётся переносить через git clone --mirror и ручной перенос issues по API.

Когда выбирать что — по сценарию, а не по хайпу

Берите GitLab CE, если: нужен встроенный CI с матрицами и сложными зависимостями между стадиями, команда больше 20 человек и нужны roles/protected branches тонкой настройки, есть compliance-требование именно на «GitLab» как бренд (для аудита или интеграции со сторонними SOC-инструментами), сервер не жалко — от 8 GB RAM найдётся.

Берите Forgejo, если: это команда до 15-20 человек или личный/командный self-hosted git без претензий на энтерпрайз-фичи, VPS ограничен 2-4 GB RAM, важна скорость бэкапа/переноса (один бинарник + папка данных куда проще перенести, чем омнибус-инсталляцию), команда уже пишет пайплайны в синтаксисе GitHub Actions.

Для честной картины по самой Gitea (родителю Forgejo) в сравнении с GitLab есть отдельный разбор: Gitea против GitLab — цифры по памяти и функциям во многом переносятся и на Forgejo, так как форк сохранил архитектуру предка. Пошаговая установка GitLab CE — в статье gitlab-ce-na-ubuntu-24-04-poshagovaya-ustanovka, Forgejo — в forgejo-na-ubuntu-24-04-poshagovaya-ustanovka.

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