Forgejo: почему независимость важнее функций

Forgejo: зачем кому-то нужен форк Gitea

В 2022 году группа бывших мейнтейнеров Gitea ушла из проекта после того, как контроль над ним перешёл к коммерческой компании Gitea Ltd. Они не просто продолжили разработку — они создали Forgejo, платформу, которая не скрывает своей идеологии: свобода от корпоративного контроля важнее любых функций. Четыре года спустя Forgejo не только сохранил позиции, но и стал заметным игроком среди инструментов для самохостинга. Речь здесь не о технических деталях, а о том, что Forgejo предлагает независимость как принцип — и именно это оказывается весомым аргументом для многих команд.

Откуда взялся Forgejo и почему это не просто форк

Gitea начинался как лёгкий, быстрый и простой в установке инструмент — идеальное решение для самохостинга. Но в 2022 году его мейнтейнеры столкнулись с тем, что контроль над проектом перешёл к коммерческой компании Gitea Ltd. Для части сообщества это стало тревожным сигналом: проект, который изначально строился вокруг сообщества, теперь подчиняется корпоративным интересам. Группа разработчиков, не согласных с таким поворотом, ушла и основала Forgejo под эгидой некоммерческой организации Codeberg e.V., зарегистрированной в Германии.

Это не просто смена логотипа. Forgejo — это платформа с чёткой позицией. В документации нет обещаний enterprise-функций, зато есть прямое заявление: проект существует для сообществ, которые хотят избежать зависимости от корпоративных платформ. Если Gitea стал инструментом, который может быть куплен или изменён по коммерческим соображениям, то Forgejo гарантирует, что его будущее не будет зависеть от решений инвесторов или корпоративных стратегий.

Но идеология — это не только слова. Это юридические гарантии. Codeberg e.V. — некоммерческая организация, что означает, что проект не может быть продан, его лицензия не изменится, а ключевые функции не будут закрыты ради монетизации. Для команд, которые хотят избежать рисков, связанных с коммерциализацией, это принципиальный момент.

Три блока, которые отличают Forgejo от Gitea и GitLab

1. Независимость — не лозунг, а юридическая защита

Forgejo курируется некоммерческой организацией, что юридически защищает его от внезапных коммерциализаций. В отличие от Gitea Ltd, которая может изменить условия обслуживания или закрыть проект, Forgejo юридически защищён от таких рисков. Это значит, что если Gitea Ltd решит ввести платные функции или свернуть бесплатный хостинг, пользователи Forgejo не окажутся перед фактом вынужденной миграции.

Команды, которые выбирают Forgejo, получают не только инструмент, но и гарантию, что его развитие не будет зависеть от корпоративных интересов.

2. Федерация через ActivityPub: децентрализация, а не маркетинг

Forgejo поддерживает ForgeFed — расширение протокола ActivityPub для форджей. Это позволяет экземплярам Forgejo обмениваться пулл-реквестами, подписками на репозитории и issue-трекингами с другими форджами.

Пример: если ваш проект хостится на git.your-org.org, а коллега работает на codeberg.org, вы можете открыть пулл-реквест напрямую, без посредников вроде GitHub. Это не просто удобство — это децентрализация контроля над разработкой.

Однако федерация пока экспериментальна. Нет единого стандарта, и реализация варьируется между экземплярами. Это значит, что пока рано говорить о полноценной федеративной разработке, но потенциал есть — и это принципиальное отличие от закрытых платформ, где федерация невозможна в принципе.

3. Совместимость с GitHub Actions: миграция без боли

Forgejo Actions — это система CI/CD, совместимая с синтаксисом GitHub Actions. Это значит, что вы можете перенести воркфлоу из GitHub почти без изменений.

Пример: если в вашем проекте уже есть .github/workflows/test.yml, он будет работать и в Forgejo. Это упрощает миграцию с GitHub и делает переход менее болезненным.

Однако есть нюансы. Не все действия из GitHub Marketplace работают. Например, действия с Docker требуют дополнительной настройки раннеров, а некоторые проприетарные интеграции (например, с AWS) могут не поддерживаться. Это не фатальный недостаток, но о нём нужно помнить — и это лишний раз напоминает, что Forgejo пока не тянет на enterprise-решение.

Что на самом деле требует Forgejo: железо, время и терпение

Железо: не требователен, но не всесилен

Forgejo — лёгкий инструмент. Минимальные требования:

• 512 МБ RAM
• 1 ядро CPU
• 50 МБ на установку (без зависимостей)

На практике это означает, что VPS за 5–10 €/мес. (например, на Hetzner или DigitalOcean) хватает с запасом. Реальное потребление: ~400–450 МБ RAM в простое.

Для сравнения: GitLab CE требует 4+ ГБ RAM даже на минимальной нагрузке. Это принципиальная разница для команд с ограниченным бюджетом на инфраструктуру.

Установка и обновление: простота — это фича

Установка Forgejo — это один бинарный файл:

1. Скачайте forgejo-11.0.2-linux-amd64.
2. Сделайте его исполняемым.
3. Запустите.

Обновление: замените бинарник и перезапустите сервис. Нет миграции базы данных, нет долгих процедур.

Это критически важно для тех, кто не хочет тратить время на администрирование. В отличие от GitLab, где обновление может занять часы, в Forgejo это вопрос минут.

Типичные грабли

• Обратный прокси (NGINX): если не указать / в proxy_pass и не прокинуть заголовки (X-Script-Name, X-Forwarded-For), то URL-ы репозиториев будут битыми. Это не баг, а последствие неверной конфигурации — и таких нюансов хватает.
• LDAP/PAM: аутентификация через LDAP или PAM работает, но требует ручной настройки. Если у вас нет опыта с PAM, лучше использовать OIDC или OAuth2.
• CI/CD раннеры: их нужно устанавливать отдельно (как бинарник, Docker-контейнер или пакет). Нет встроенной интеграции, как в GitLab.

Где Forgejo проигрывает: три слабых места, которые не исправятся скоро

1. CI/CD: совместимость не равна зрелости

Forgejo Actions совместим с GitHub Actions, но не поддерживает продвинутые фичи, которые есть в GitLab CI/CD:

• Нет DAG-пайплайнов (зависимости между задачами).
• Нет окружений (environments) для деплоя (например, staging/production).
• Нет встроенной поддержки SAST/DAST (статический анализ кода, сканирование уязвимостей).

Это означает, что для команд, которым нужны продвинутые DevOps-инструменты, Forgejo может оказаться недостаточно зрелым.

2. Документация: фрагментирована и не всегда актуальна

Документация Forgejo разбросана по вики, блогам и форумам. Например:

• Инструкции по федерации требуют перехода по нескольким ссылкам.
• Настройки CI/CD описаны не всегда чётко.

Это не смертельно, но заметно усложняет жизнь администраторам, особенно если у них нет опыта работы с самохостингом.

3. Сообщество: меньше людей — меньше поддержки

Сообщество Forgejo активно, но меньше по размеру, чем у GitLab или даже Gitea. Это означает, что ответы на специфические вопросы могут приходиться ждать дольше.

Если вы столкнётесь с нестандартной задачей (например, настройкой федерации или кастомизацией UI), то придётся искать решение самостоятельно или полагаться на форумы.

Кому стоит переезжать на Forgejo — и кому лучше остаться на GitHub

Forgejo — это инструмент для сообществ, которые хотят независимости от корпоративных платформ. Если ваша команда:

• Маленькая (до 50 человек).
• Хочет избежать зависимости от GitHub или GitLab.
• Готова мириться с ограничениями CI/CD и федерации.

...то Forgejo может стать для вас лучшим выбором.

Но если вашей команде нужны:

• Продвинутые DevOps-инструменты (DAG-пайплайны, окружения, SAST/DAST).
• Enterprise-безопасность (глубокая интеграция с Kubernetes, продвинутый контроль доступа).
• Готовая поддержка и документация.

...то лучше рассмотреть GitLab или другие платформы.

Итог: не обещания, а реальность

Forgejo не обещает революции. Он не изменит индустрию, не отменит GitHub и не станет новой эрой разработки. Но он предлагает альтернативу — инструмент, который не подчиняется корпоративным интересам, лёгкий в установке и совместимый с GitHub Actions.

Это не панацея. Это рабочий вариант для тех, кто готов мириться с ограничениями ради независимости. Если ваша команда маленькая, бюджет ограничен, а идеология важнее функциональности — Forgejo может стать тем, что вам нужно.

А если нет — всегда можно вернуться к GitHub. Но тогда вы снова будете зависеть от решений, принимаемых за вашей спиной.