Forgejo : un Gitea sous gouvernance communautaire

Gitea a popularisé l'idée d'une plateforme Git self-hosted légère et complète, alternative crédible à GitLab pour les équipes qui n'avaient pas besoin de toute la richesse de la suite GitLab. En 2022, le projet est passé sous le contrôle d'une société commerciale (Gitea Limited), avec un transfert de marque et de gouvernance qui a inquiété une partie de la communauté. Plusieurs contributeurs ont alors lancé un fork sous le nom Forgejo, hébergé sur Codeberg.

Aujourd'hui, Forgejo a divergé : nouvelle gouvernance, licence GPLv3, fonctionnalités exclusives (notamment la fédération ActivityPub en cours). Cet article fait le point sur les différences avec Gitea, les choix structurants du projet, et les cas où Forgejo est le bon choix.

• Pourquoi Forgejo existe
• Compatibilité avec Gitea
• Forgejo Actions
• Fédération ActivityPub
• Comparaison Forgejo vs Gitea vs GitLab CE
• Déploiement et migration depuis Gitea
• Limites et points d'attention

Gitea a été créé en 2016 comme fork de Gogs, sous gouvernance communautaire et licence MIT. En 2022, l'annonce de la création de Gitea Limited, société commerciale qui héritait de la propriété de la marque "Gitea", du domaine et du compte GitHub, a déclenché des tensions. Une partie de la communauté contributrice y a vu une privatisation contraire à l'esprit initial du projet.

En octobre 2022, ces contributeurs ont annoncé Forgejo : un fork sous l'égide de Codeberg e.V. (association à but non lucratif allemande), sous gouvernance communautaire stricte, sans entité commerciale dominante. Le nom "Forgejo" combine "forge" (au sens DevOps) et "ejo" (suffixe espéranto signifiant "place de").

Aujourd'hui :

• Licence : GPLv3+ depuis Forgejo v9 (avant : MIT, comme Gitea). Le passage à la GPLv3 vise à empêcher des relicensages commerciaux non concertés.
• Gouvernance : conseil élu, contributeurs identifiés, processus public de prise de décision documenté dans le dépôt forgejo/governance.
• Pas d'entité commerciale dominante. Codeberg e.V. héberge le projet sans en être propriétaire au sens commercial.
• Mainteneurs salariés financés par des sponsors et donations.

La dernière version stable au moment de la rédaction est la v15.0.1.

Forgejo et Gitea partagent l'essentiel de leur codebase historique. Cela se traduit par :

• Migration trivial depuis Gitea jusqu'à la version 1.20 environ. Le binaire Forgejo lit la base SQLite/Postgres/MySQL/MariaDB d'un Gitea sans modification ; les repos Git sur disque sont identiques.
• API REST : très largement compatible. Les outils tiers (CLI gitea-tea, intégrations Renovate, etc.) fonctionnent avec Forgejo dans la majorité des cas.
• Fichiers de configuration : le même app.ini est consommé par les deux projets.

Les divergences s'accumulent mais restent gérables :

• Fonctionnalités exclusives Forgejo : Forgejo Actions stable, fédération ActivityPub (alpha), améliorations UI/UX, refonte de la modération.
• Fonctionnalités exclusives Gitea : suite Gitea (issues, projets, packages avec extensions commerciales), thème custom plus poussé.
• Compatibilité de migration retour : possible mais pas garantie au-delà de quelques versions de divergence.

Pour une instance Gitea < 1.21, la migration vers Forgejo est une opération de quelques minutes (changement de binaire, migration des migrations DB éventuelles). Au-delà, c'est à étudier au cas par cas.

Forgejo Actions est un système CI/CD intégré, compatible avec la syntaxe GitHub Actions. Cela signifie qu'on peut réutiliser une grande partie des workflows GitHub directement, et la majorité des actions du Marketplace GitHub fonctionnent (sauf celles qui dépendent d'API GitHub spécifiques comme les commentaires ou les checks API).

Architecture :

• Forgejo héberge les workflows et les logs d'exécution.
• Forgejo Runner : agent qui exécute les jobs (équivalent gitea-act_runner).

Exemple de workflow .forgejo/workflows/ci.yaml :

name: CI
on: [push, pull_request]

jobs:
  test:
    runs-on: docker
    container:
      image: node:22
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

  build:
    needs: test
    runs-on: docker
    container:
      image: docker:dind
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t my-app .

Pour déployer un runner :

# Récupérer le binaire
wget https://code.forgejo.org/forgejo/runner/releases/download/v6.4.0/forgejo-runner-linux-amd64
chmod +x forgejo-runner-linux-amd64

# Enregistrer le runner contre l'instance Forgejo
./forgejo-runner-linux-amd64 register \
  --instance https://forge.example.com \
  --token <runner-token-from-admin-ui> \
  --name builder-1 \
  --labels docker,ubuntu

# Démarrer le runner
./forgejo-runner-linux-amd64 daemon

Pour les équipes qui veulent un CI/CD self-hosted intégré sans monter un GitLab CI complet, c'est une option pragmatique avec une courbe d'apprentissage minimale (syntaxe GitHub Actions déjà connue).

L'une des promesses originales de Forgejo : fédérer les forges via ActivityPub, le protocole qui propulse Mastodon et le fediverse. L'objectif à terme : pouvoir suivre un repo, ouvrir une issue ou commenter une PR sur une instance Forgejo distante depuis sa propre instance, sans devoir y créer un compte.

L'implémentation est en cours et explicitement en alpha au moment de la rédaction. Les fonctionnalités déjà disponibles ou à des stades de développement avancés :

• Suivi de profils utilisateurs entre instances.
• Annonce d'événements (push, release) cross-instance.
• Création d'issues à distance (en construction).

C'est une fonctionnalité à suivre, qui pourrait à terme rendre Forgejo unique dans le paysage des forges Git self-hosted. Pour le moment, ce n'est pas un argument de production.

Pour des équipes qui veulent du simple, léger et communautaire, Forgejo est aujourd'hui le choix le plus rationnel. Gitea reste une option viable, surtout pour ceux qui veulent les extensions Pro/Enterprise. GitLab CE garde son leadership pour les organisations qui veulent une plateforme tout-en-un et acceptent l'empreinte associée.

Le déploiement minimal d'une instance Forgejo via docker-compose :

services:
  forgejo:
    image: codeberg.org/forgejo/forgejo:15.0.1
    container_name: forgejo
    restart: unless-stopped
    environment:
      USER_UID: 1000
      USER_GID: 1000
      FORGEJO__database__DB_TYPE: postgres
      FORGEJO__database__HOST: db:5432
      FORGEJO__database__NAME: forgejo
      FORGEJO__database__USER: forgejo
      FORGEJO__database__PASSWD: ${DB_PASS}
    volumes:
      - ./data:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - '3000:3000'
      - '2222:22'
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: forgejo
      POSTGRES_PASSWORD: ${DB_PASS}
      POSTGRES_DB: forgejo
    volumes:
      - ./postgres:/var/lib/postgresql/data

Au premier accès (http://forge.example.com:3000), un assistant guide la création du compte administrateur et la finalisation de la configuration. Le fichier app.ini est ensuite éditable manuellement pour les ajustements.

Migration depuis Gitea :

1. Arrêter Gitea.
2. Sauvegarder la base de données et le répertoire data/.
3. Démarrer Forgejo en pointant vers la même base et le même data/.
4. Forgejo applique les éventuelles migrations DB.
5. Vérifier le fonctionnement (push/pull, issues, runners).

Pour une instance Gitea récente (1.22+), vérifier la note de migration de la version Forgejo cible : certaines versions Gitea ont introduit des schémas DB que Forgejo gère via des migrations spécifiques.

Écosystème un peu plus restreint que Gitea. Certains thèmes custom ou intégrations spécifiques sont nés du côté Gitea ; leur portage Forgejo n'est pas toujours immédiat. La situation s'améliore mais l'écart reste perceptible.

Pas de version Enterprise commerciale. Si l'organisation veut un support commercial avec SLA, c'est à organiser via des prestataires (les contributeurs principaux acceptent des contrats de support, pas l'éditeur "officiel").

Fédération encore alpha. À ne pas considérer comme une fonctionnalité de production. Pour des cas d'usage sérieux multi-instance, prévoir un plan B.

Risque de divergence accélérée avec Gitea. Plus le temps passe, plus Forgejo et Gitea divergent. La migration retour Gitea → Forgejo (ou inverse) devient progressivement plus complexe.

• Self-hosting personnel ou associatif : alternative GitHub légère, gouvernance ouverte, GPL compatible avec d'autres briques copyleft.
• Forge interne pour une équipe technique qui ne veut pas la lourdeur GitLab CE.
• CI/CD compatible GitHub Actions sans dépendance GitHub (ou comme étape avant migration).
• Organisations attachées à la souveraineté logicielle et à la gouvernance communautaire des outils.

Pour une équipe qui mise sur la richesse fonctionnelle (epics, roadmaps, security scanners intégrés), GitLab CE reste plus complet. Pour celles qui veulent les extensions commerciales du Gitea Pro, rester sur Gitea fait sens.

• Gitea : déployer une forge légère
• GitLab CE en docker-compose
• GitLab CI sur Kubernetes
• GitHub runners auto-hébergés
• Argo CD et GitOps

• Forgejo (dépôt Codeberg) code, releases, version v15.0.1
• Site officiel forgejo.org, documentation
• Gouvernance Forgejo, règles, conseil
• Forgejo Actions documentation, CI/CD
• Annonce du fork Forgejo (oct 2022), historique

Forgejo n'est pas un fork de circonstance : c'est une affirmation de gouvernance qui a abouti à un projet stable, régulièrement amélioré, avec des choix structurants (GPLv3, Codeberg, fédération) qui le distinguent durablement de Gitea. Pour une équipe qui veut une forge Git self-hosted légère et une gouvernance communautaire stricte, c'est aujourd'hui l'option la plus alignée.