Forgejo : Pourquoi Quitter GitHub pour Héberger son propre Git en 2026

En 2026, la question n'est plus vraiment "faut-il quitter GitHub ?" mais plutôt "pourquoi ne l'a-t-on pas fait plus tôt ?". Entre le rachat par Microsoft en 2018, les limitations croissantes sur les comptes gratuits, la centralisation massive du code open source sur une seule plateforme commerciale, et les récentes inquiétudes autour de la confidentialité des données — notamment l'utilisation du code public pour entraîner des modèles IA sans consentement explicite —, de plus en plus de sysadmins et de développeurs cherchent une alternative sérieuse.

La centralisation est un problème structurel. Aujourd'hui, une part écrasante du code open source mondial est hébergée sur une seule plateforme détenue par une seule entreprise américaine. C'est un risque pour l'écosystème : une panne, une décision commerciale, un changement de politique — et des milliers de projets sont impactés. On l'a vu avec le blocage de certains dépôts dans des pays soumis à des sanctions, ou avec la suppression arbitraire de projets jugés "problématiques".

Ce guide s'adresse à ceux qui veulent reprendre la main. Pas juste installer un outil de plus, mais réellement héberger leur propre infrastructure Git, avec la souveraineté totale sur leur code. Forgejo est aujourd'hui la réponse la plus aboutie à cette question — légère, moderne, communautaire, et complète.

C'est quoi Forgejo ?

Forgejo est un fork communautaire de Gitea, né en décembre 2022 suite aux inquiétudes sur la direction prise par Gitea Ltd (la société commerciale derrière Gitea). Lorsque Gitea Ltd a commencé à recruter des développeurs à temps plein sans transparence sur leur financement, et à prendre des décisions de gouvernance sans consulter la communauté, plusieurs contributeurs historiques ont décidé de créer un fork 100% dirigé par sa communauté.

Forgejo est développé sous l'égide de Codeberg e.V., une association à but non lucratif allemande enregistrée. C'est une garantie importante : pas d'investisseurs à satisfaire, pas de pivot commercial possible, pas de "rug pull" de licence comme on a pu le voir chez HashiCorp (BSL), Elastic (SSPL) ou Redis Labs. Le code restera MIT, point final.

Quelques faits clés :

• Licence : MIT — libre, permissive, utilisable commercialement sans restriction
• Version actuelle : Forgejo 11.x / v14.0 (LTS, janvier 2026) — support garanti jusqu'en 2027
• Site officiel : https://forgejo.org
• Instance publique de référence : https://codeberg.org — 100 000+ utilisateurs actifs
• Hébergement du code source : Sur Codeberg lui-même — dogfooding total, ce qui est rassurant
• Compatibilité : API REST et webhooks GitHub-compatibles, migration depuis GitHub/GitLab facilitée
• Langues : Interface disponible en plus de 30 langues dont le français

Fonctionnellement, Forgejo propose tout ce qu'on attend d'une forge moderne : gestion de repositories Git, issues trackers avec labels et milestones, pull requests avec revue de code, wikis par projet, gestion des releases et des artefacts, webhooks configurables, et même un système de CI/CD natif appelé Forgejo Actions — entièrement compatible avec la syntaxe GitHub Actions.

La légèreté est un argument majeur : là où GitLab nécessite au minimum 4 GB de RAM (et souvent 8 GB en pratique pour être confortable), Forgejo tourne parfaitement avec 256 MB à 512 MB de RAM pour une utilisation personnelle ou une petite équipe. C'est un game changer pour héberger sur un petit VPS ou même un Raspberry Pi.

Forgejo vs GitHub vs GitLab vs Gitea — Comparatif

Avant de se lancer, voici une vue d'ensemble des principales options disponibles pour héberger votre propre forge Git :

GitLab CE est une alternative puissante mais gourmande en ressources — comptez minimum 4 GB RAM, souvent 8 GB en pratique, et plusieurs Go de dépendances Ruby/PostgreSQL. Forgejo tourne confortablement sur un VPS à 1 vCPU / 1 GB RAM — ce qui change tout pour un usage personnel ou une petite équipe de développeurs.

Gitea reste une option valide, mais la question de la gouvernance (Gitea Ltd, sociéte privée) reste un point d'interrogation. Forgejo offre les mêmes fonctionnalités avec une gouvernance communautaire explicitement ancrée dans le monde associatif européen.

Prérequis

Pour héberger Forgejo dans de bonnes conditions, voici ce dont vous avez besoin avant de commencer :

Serveur minimum

• CPU : 1 vCPU (x86_64 ou ARM64 — les deux sont supportés nativement)
• RAM : 1 GB minimum, 2 GB recommandé pour un usage multi-utilisateurs
• Stockage : 20 GB SSD minimum — les repositories Git sont efficaces, mais les uploads et artefacts peuvent grossir
• OS : Linux — Debian 12, Ubuntu 22.04/24.04, Rocky Linux 9, ou toute distribution récente
• Réseau : Adresse IP publique fixe ou floating IP

Logiciels requis

• Docker 24.x+ (méthode recommandée dans ce guide) — ou Docker Compose pour une gestion plus propre
• Nginx — reverse proxy pour l'exposition HTTPS
• Certbot — pour générer et renouveler automatiquement les certificats Let's Encrypt
• Un nom de domaine pointant vers votre serveur (ex: git.example.com) — le certificat Let's Encrypt l'exige

Ports à ouvrir dans votre firewall

• 80/tcp — HTTP (uniquement pour la redirection HTTPS et les challenges ACME)
• 443/tcp — HTTPS (interface web Forgejo via Nginx)
• 2222/tcp — SSH Git (ou 22 si ce port n'est pas déjà utilisé par votre SSH système)

Sur un VPS OVH/Hetzner/Scaleway, pensez à vérifier le firewall dans le panel d'administration en plus du firewall logiciel (ufw ou firewalld).

Installation via Docker

Docker est la méthode la plus propre et la plus recommandée pour déployer Forgejo en production : isolation complète du système hôte, mises à jour simplifiées en une commande, pas de dépendances système à gérer, et portabilité totale si vous devez migrer vers un autre serveur.

1. Récupérer l'image officielle

docker pull codeberg.org/forgejo/forgejo:latest

L'image est hébergée sur Codeberg (pas sur Docker Hub) — cohérent avec l'éthique du projet. Si vous préférez une version LTS stable pour la production, remplacez latest par la version explicite comme 11.0.

2. Préparer les volumes de données

mkdir -p /srv/forgejo/{data,config}
chown -R 1000:1000 /srv/forgejo/

Le UID/GID 1000 correspond à l'utilisateur git dans le conteneur Forgejo. Ces deux dossiers contiendront respectivement les données (repositories, uploads, base SQLite) et la configuration (app.ini).

3. Lancer le conteneur Forgejo

docker run -d \
  --name forgejo \
  --restart always \
  -p 3000:3000 \
  -p 2222:22 \
  -v /srv/forgejo/data:/data \
  -v /srv/forgejo/config:/etc/gitea \
  -e USER_UID=1000 \
  -e USER_GID=1000 \
  codeberg.org/forgejo/forgejo:latest

Quelques précisions sur les options :

• --restart always — redémarre automatiquement le conteneur si le daemon Docker redémarre (après un reboot serveur par exemple)
• -p 3000:3000 — interface web (sera ensuite masquée derrière Nginx)
• -p 2222:22 — SSH Git, mappé sur le port 2222 de l'hôte pour éviter le conflit avec le SSH système
• -v /srv/forgejo/data:/data — persistance des données même si le conteneur est recréé

4. Vérifier que ça tourne

docker ps | grep forgejo
curl -sI http://localhost:3000 | head -2

Vous devriez voir HTTP/1.1 200 OK. Si c'est le cas, Forgejo est opérationnel. Rendez-vous sur http://votre-ip:3000 pour l'assistant de configuration initial — il vous guidera pour créer l'utilisateur administrateur et configurer les paramètres de base.

Configuration de base (app.ini)

Forgejo se configure principalement via le fichier app.ini (situé dans /srv/forgejo/config/app.ini avec notre montage Docker). Ce fichier est généré automatiquement lors de la première installation via l'assistant web. Voici les paramètres essentiels à vérifier et ajuster :

Sections clés de app.ini

[server]
DOMAIN           = git.example.com
ROOT_URL         = https://git.example.com/
HTTP_PORT        = 3000
SSH_DOMAIN       = git.example.com
SSH_PORT         = 2222
START_SSH_SERVER = true

[database]
DB_TYPE = sqlite3
PATH    = /data/gitea/gitea.db

[security]
INSTALL_LOCK        = true
SECRET_KEY          = (généré automatiquement)
INTERNAL_TOKEN      = (généré automatiquement)
PASSWORD_COMPLEXITY = lower,upper,digit,spec

[service]
DISABLE_REGISTRATION = true
REQUIRE_SIGNIN_VIEW  = false

Après modification du app.ini, redémarrez le conteneur pour que les changements soient pris en compte :

docker restart forgejo

Conseil : Une fois votre compte admin créé, passez immédiatement DISABLE_REGISTRATION = true pour éviter que des inconnus créent des comptes sur votre instance. Si vous voulez inviter des collaborateurs, utilisez la fonction "Créer un compte" depuis le panel admin, ou activez les invitations par e-mail.

Pour la base de données, SQLite est parfaitement adapté à un usage personnel ou une petite équipe (jusqu'à ~50 utilisateurs actifs). Au-delà, envisagez PostgreSQL pour de meilleures performances en écriture concurrente.

Créer son premier repo et pousser du code

Une fois Forgejo configuré et accessible via HTTPS, créer un repository et y pousser du code se fait exactement comme sur GitHub — l'interface est quasi-identique, intentionnellement.

Depuis l'interface web

1. Connectez-vous à votre instance Forgejo
2. Cliquez sur + Nouveau dépôt (bouton en haut à droite)
3. Choisissez un nom, une description, la visibilité (public/privé/interne), initialisez avec un README si besoin
4. Cliquez sur Créer le dépôt

Premier push depuis votre machine locale

git init mon-projet
cd mon-projet
echo "# Mon projet" > README.md
git add .
git commit -m "Initial commit"
git remote add origin https://git.example.com/user/mon-projet.git
git push -u origin main

Pour utiliser SSH à la place de HTTPS (recommandé pour le quotidien — plus rapide, sans saisie de mot de passe) :

1. Ajoutez votre clé publique SSH dans Forgejo : Profil → Paramètres → Clés SSH/GPG
2. Changez la remote de votre repo local : git remote set-url origin git@git.example.com:user/mon-projet.git

Si vous avez mappé le port SSH sur 2222 (et non 22), configurez votre ~/.ssh/config :

Host git.example.com
    Port 2222
    User git

Forgejo Actions — CI/CD intégré

Forgejo Actions est le système de CI/CD intégré à Forgejo. Sa grande force : il utilise exactement la même syntaxe YAML que GitHub Actions. Si vous avez déjà des workflows GitHub Actions dans vos projets, ils fonctionneront avec peu ou pas de modifications — c'est un point critique pour migrer sereinement.

Architecture : runners auto-hébergés

Contrairement à GitHub Actions qui fournit des runners hébergés inclus dans l'abonnement, avec Forgejo vous déployez vos propres runners. Ce n'est pas un désavantage : vous contrôlez l'environnement d'exécution, les ressources allouées, et il n'y a pas de limite de minutes de CI par mois.

Déploiement d'un runner avec Docker :

docker run -d \
  --name forgejo-runner \
  --restart always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /srv/forgejo-runner:/data \
  -e FORGEJO_INSTANCE_URL=https://git.example.com \
  -e FORGEJO_RUNNER_REGISTRATION_TOKEN=votre_token \
  codeberg.org/forgejo/runner:latest

Le token de registration se trouve dans l'interface admin : Administration du site → Runners → Créer un runner.

Exemple de workflow CI

Créez le fichier .forgejo/workflows/ci.yml à la racine de votre repository :

on: [push]
jobs:
  test:
    runs-on: docker
    container:
      image: ubuntu:22.04
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: |
          echo "Tests en cours..."
          # Ajouter vos commandes de test ici

Ce workflow se déclenchera à chaque push sur n'importe quelle branche. Le job s'exécute dans un conteneur Ubuntu 22.04 frais — vous pouvez utiliser n'importe quelle image Docker disponible publiquement. Les cas d'usage courants incluent : tests unitaires, linting, build d'images Docker, déploiement sur un serveur de staging, génération de documentation.

Actions de l'écosystème disponibles

La plupart des actions GitHub Actions courantes fonctionnent directement avec Forgejo Actions. actions/checkout@v4, actions/setup-node, actions/setup-python, docker/build-push-action... sont toutes disponibles. Forgejo maintient également son propre registre d'actions hébergé sur Codeberg pour les actions spécifiques à l'écosystème Forgejo.

Migration depuis GitHub

Migrer ses repositories existants depuis GitHub vers Forgejo est l'une des fonctionnalités les plus appréciées, et l'une des plus complètes. Forgejo peut importer un repository GitHub en préservant : l'historique Git complet, les issues et leurs commentaires, les pull requests, les labels, les milestones, et même les réactions emoji sur les commentaires.

Via l'interface web (méthode simple)

Forgejo Admin → Explore → Migrate → GitHub
URL: https://github.com/user/repo
Token: ghp_xxxxxxxxxxxx (Personal Access Token GitHub)

Pour obtenir un Personal Access Token GitHub : rendez-vous dans GitHub → Settings → Developer settings → Personal access tokens → Generate new token (classic). Les scopes nécessaires sont repo pour les repositories privés, ou aucun scope particulier pour les repositories publics.

La migration peut prendre quelques minutes selon la taille du repository et le nombre d'issues. Forgejo affiche une barre de progression et envoie une notification par email (si configuré) une fois terminé.

Migration en masse via l'API Forgejo

Si vous avez de nombreux repositories à migrer, scriptez la migration via l'API REST de Forgejo, qui est compatible avec l'API GitHub v3 :

#!/bin/bash
FORGEJO_URL="https://git.example.com"
FORGEJO_TOKEN="votre_token_forgejo"
GITHUB_USERNAME="votre_username_github"

# Lister tous vos repos GitHub et les migrer un par un
for REPO_NAME in repo1 repo2 repo3; do
  curl -X POST "$FORGEJO_URL/api/v1/repos/migrate" \
    -H "Authorization: token $FORGEJO_TOKEN" \
    -H "Content-Type: application/json" \
    -d "{
      \"clone_addr\": \"https://github.com/$GITHUB_USERNAME/$REPO_NAME\",
      \"repo_name\": \"$REPO_NAME\",
      \"issues\": true,
      \"pull_requests\": true,
      \"wiki\": true,
      \"labels\": true,
      \"milestones\": true
    }"
done

Vous pouvez également configurer une synchronisation miroir — Forgejo récupère automatiquement les nouveaux commits depuis GitHub à intervalles réguliers. Utile pour une migration progressive sans couper le cordon d'un coup.

Bonnes pratiques sécurité

Un serveur Git héberge votre code source — potentiellement vos secrets, vos configurations d'infrastructure, vos clés API commentées dans du code de dev. La sécurité n'est pas optionnelle et mérite une attention particulière.

Nginx en reverse proxy + HTTPS obligatoire

Ne jamais exposer Forgejo directement sur le port 3000 en production. Utilisez toujours Nginx comme reverse proxy avec HTTPS. Cela permet aussi d'activer des headers de sécurité (HSTS, CSP) et de gérer le rate limiting au niveau du reverse proxy.

Créez le fichier /etc/nginx/conf.d/forgejo.conf :

server {
    listen 80;
    server_name git.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name git.example.com;

    ssl_certificate /etc/letsencrypt/live/git.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/git.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Certificat SSL avec Let's Encrypt

certbot --nginx -d git.example.com

Certbot configure automatiquement Nginx avec le certificat et met en place le renouvellement automatique via systemd timer ou cron. Vérifiez que le renouvellement fonctionne avec certbot renew --dry-run.

SSH key-only — désactiver l'authentification par mot de passe

Pour les connexions SSH Git, n'autorisez que les clés SSH — jamais les mots de passe. Dans app.ini, assurez-vous que :

[security]
PASSWORD_HASH_ALGO = pbkdf2

[service]
DISABLE_REGISTRATION     = true
ALLOW_ONLY_EXTERNAL_REGISTRATION = false

Et sur votre serveur hôte Linux, désactivez l'authentification par mot de passe dans /etc/ssh/sshd_config :

PasswordAuthentication no
PubkeyAuthentication yes

Fail2ban pour protéger l'interface web

Forgejo génère des logs détaillés que Fail2ban peut analyser pour bannir les IP qui font trop de tentatives d'authentification échouées. Créez un filtre /etc/fail2ban/filter.d/forgejo.conf :

[Definition]
failregex = .*Failed authentication attempt for .* from <HOST>
ignoreregex =

Puis la jail correspondante dans /etc/fail2ban/jail.local :

[forgejo]
enabled  = true
port     = http,https
filter   = forgejo
logpath  = /srv/forgejo/data/forgejo/log/forgejo.log
maxretry = 5
bantime  = 3600

Backup régulier — ne perdez pas votre code

Forgejo intègre une commande de backup qui génère une archive complète de l'instance : base de données, repositories Git, configuration, uploads et clés SSH. Automatisez-la :

docker exec forgejo forgejo admin forgejo-dump -c /etc/gitea/app.ini

L'archive générée (format ZIP) contient tout ce qu'il faut pour restaurer l'instance sur un nouveau serveur. Planifiez cette commande en cron (par exemple, toutes les nuits à 3h) et synchronisez les archives vers un stockage distant : S3/MinIO, Backblaze B2, ou un simple rsync vers un second serveur. La règle 3-2-1 s'applique ici comme ailleurs.

Ressources et liens utiles

• Site officiel Forgejo : https://forgejo.org
• Documentation officielle : https://forgejo.org/docs/latest/
• Code source (sur Codeberg) : https://codeberg.org/forgejo/forgejo
• Instance publique Codeberg : https://codeberg.org — parfait pour tester l'interface avant d'héberger soi-même
• Forgejo Actions docs : https://forgejo.org/docs/latest/user/actions/
• Forum communautaire : https://forum.forgejo.org
• Chat Matrix : #forgejo:matrix.org — réponses rapides de la communauté
• Annonces de sécurité : https://forgejo.org/security/ — à surveiller pour patcher rapidement
• Notes de version v14.0 LTS : https://forgejo.org/2026-01-release-v14-0/
• Comparatif forges Git : git.coopcloud.tech — ressource de la communauté libre pour comparer les options

Conclusion

Migrer vers Forgejo en 2026, ce n'est pas un caprice de puriste du libre. C'est une décision pragmatique, technique et politique pour tout sysadmin ou développeur qui prend au sérieux la souveraineté de son code et l'indépendance de son infrastructure.

En quelques heures de travail, vous avez une instance Forgejo pleinement fonctionnelle : interface web moderne et réactive, CI/CD intégré compatible avec vos workflows GitHub Actions existants, gestion complète des issues et pull requests, et surtout une sécurité que vous contrôlez de A à Z. Le tout sur un VPS à 5-10 euros par mois — moins cher qu'un abonnement GitHub Teams.

Les avantages sont concrets et immédiats :

• Confidentialité totale — votre code ne quitte jamais votre infrastructure, jamais utilisé pour entraîner des IA tiers
• Pas de dépendance commerciale — Codeberg e.V. est une association, pas une startup cherchant une exit
• Ressources modestes — 1 vCPU / 1 GB RAM suffisent largement pour une équipe de 10 à 20 personnes
• Migration facilitée — import GitHub/GitLab en quelques clics, API compatible, miroir possible en parallèle
• Communauté active et transparente — releases mensuelles, Forgejo v14.0 LTS maintenu jusqu'en 2027
• Zéro vendor lock-in — format Git standard, données accessibles à tout moment, migration vers une autre solution toujours possible

GitHub reste un excellent outil pour les projets open source qui veulent de la visibilité et attirer des contributeurs externes. Mais pour votre code propriétaire, vos projets internes, vos scripts d'infrastructure, vos configurations Ansible/Terraform — hébergez-les vous-même. Avec Forgejo, vous n'avez vraiment aucune excuse pour ne pas le faire.

Vous hébergez déjà votre propre Git ou vous venez de vous lancer ? Partagez votre setup et vos retours d'expérience en commentaire — les questions sont les bienvenues.