Qu'est-ce qu'une forge Git et laquelle exploiter ?

Une forge Git est un serveur Git doté d'une interface web, de comptes, de revues de code et, le plus souvent, d'une CI et d'un registre de paquets. L'auto-héberger, c'est en devenir l'administrateur : vous gérez la base, le stockage, le proxy, les sauvegardes et les montées de version. Cette leçon s'adresse à qui doit choisir et exploiter une forge pour une équipe. Elle donne l'architecture type, six critères pour trancher, et le verdict de la formation : Forgejo 15 LTS est la forge de référence, GitLab le choix quand il faut une plateforme complète, Gitea une alternative laissée en référence.

Ce que vous allez apprendre

• Distinguer un simple serveur Git d'une forge, et mesurer ce que l'auto-hébergement vous impose.
• Nommer les briques d'une forge (application, accès SSH, base, stockage, proxy, runner) et ce qu'il faut en sauvegarder ou surveiller.
• Appliquer six critères d'exploitant : licence et gouvernance, cycle de support, ressources, fonctions d'administration, CI intégrée, migration.
• Comparer Forgejo, Gitea et GitLab avec ces critères, puis justifier un choix.
• Situer la haute disponibilité et Kubernetes comme des limites du périmètre.

Quels sont les prérequis ?

Il faut savoir ce qu'est Git : un dépôt, un commit, un push. Rien d'autre n'est requis, et la leçon ne contient aucune commande à rejouer. Si vous n'avez jamais hébergé un dépôt vous-même, le guide Héberger un serveur Git montre le plus petit serveur possible, sans interface.

Quelques mots reviennent partout. Un reverse proxy est le serveur placé devant l'application pour recevoir les requêtes à sa place et porter le chiffrement HTTPS (le TLS), voir le guide Reverse proxy. Un runner est le programme qui exécute les tâches de CI (intégration continue), c'est-à-dire des tests et des builds automatiques déclenchés par un commit. Une version LTS (Long Term Support) reçoit des correctifs pendant plus longtemps que les versions ordinaires.

Qu'est-ce qui distingue une forge d'un simple serveur Git ?

Un serveur Git stocke et transmet des dépôts ; une forge y ajoute tout ce qui fait travailler une équipe autour. Le serveur du guide d'hébergement accepte git push et git clone par SSH ou HTTP, rien de plus. Une forge ajoute des comptes et des organisations, des droits par dépôt, des pull requests (la demande de fusion relue par un collègue), des tickets, un wiki, des webhooks (appels HTTP envoyés à un autre outil quand un événement survient), et souvent un registre de paquets et une CI.

Ce confort se paie en exploitation. Un dépôt bare (le dépôt réduit à son historique, sans fichiers de travail) dans un répertoire se sauvegarde avec un rsync ; une forge répartit son état entre une base de données, des fichiers de dépôts et des réglages, qu'il faut sauvegarder ensemble. Elle expose en plus une application web à vos utilisateurs, donc une surface d'attaque à patcher. Choisir l'auto-hébergement se justifie par le contrôle des données, un réseau isolé ou la maîtrise du coût ; le guide Plateformes Git compare les offres du point de vue de l'utilisateur, et cette leçon prend celui de l'exploitant.

De quoi se compose une forge auto-hébergée ?

Une forge tient en six briques : l'application, l'accès SSH, la base, le stockage, le reverse proxy et le runner. Le schéma montre comment un client les traverse. Suivez d'abord les traits épais : le navigateur, l'API ou git en HTTPS arrivent au reverse proxy, qui termine le TLS et transmet en HTTP à l'application. Regardez ensuite la flèche du SSH : elle contourne le proxy, car un proxy HTTP ne parle pas SSH. Enfin, le runner, en pointillé, vit sur une autre machine et vient lui-même chercher ses tâches.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Le tableau dit, pour chaque brique, son rôle et ce qu'elle réclame de vous. Lisez la dernière colonne comme la liste de vos futures tâches d'administrateur, brique par brique.

Brique	Rôle	Ce que l'administrateur en fait
Application	interface web, API, logique Git (droits, revues, webhooks)	la monter en version, la configurer, lire ses journaux
Accès SSH	git clone et git push par clé	choisir entre le sshd du système et le serveur SSH intégré de la forge
Base de données	comptes, tickets, métadonnées des dépôts	la choisir dès le départ, la sauvegarder avec le reste
Stockage	dépôts Git, fichiers LFS (gros fichiers gardés hors de l'historique Git), paquets, pièces jointes	le dimensionner et le sauvegarder
Reverse proxy	TLS, redirection HTTP vers HTTPS	renouveler le certificat, ne pas exposer l'application en direct
Runner	exécute les tâches de CI	l'isoler de la forge, l'enregistrer, le sécuriser

Glissez pour voir

La base est le choix le plus lourd de conséquences. D'après la documentation de Forgejo, quatre moteurs sont pris en charge : MariaDB 10.6 ou plus, MySQL 8.4 ou plus, PostgreSQL 14 ou plus et SQLite (préparation de la base). SQLite convient à un essai ; une équipe prend PostgreSQL, que l'on sauvegarde et surveille comme les autres bases. GitLab, lui, ne gère que PostgreSQL (prérequis GitLab). Choisissez le moteur dès l'installation : la documentation de Gitea avertit que convertir une base d'un type à un autre est un processus mal éprouvé (préparation de la base de Gitea).

Le SSH mérite une précision. Par défaut, Forgejo laisse le sshd du système authentifier les clés (le réglage START_SSH_SERVER vaut false) ; il peut aussi embarquer son propre serveur SSH (fiche de configuration). La leçon Installer Forgejo LTS fait un troisième choix, publier le SSH du conteneur sur le port 2222, et montre ce que cela change pour l'adresse de clonage.

Le runner est la brique à traiter avec le plus de prudence. La documentation de Forgejo précise que l'instance n'exécute pas elle-même les workflows : elle les confie à des runners, et le runner « performs remote code execution », c'est-à-dire exécute du code envoyé par vos utilisateurs (Forgejo Actions). Une forge dont le runner tourne sur la même machine que l'application met donc ses dépôts à portée d'un job malveillant. Voilà pourquoi le schéma le place à part.

Les ressources de la forge vivent surtout dans le stockage. GitLab prévient que l'espace réservé à ses dépôts doit valoir au moins la somme de tous les dépôts et déconseille les systèmes de fichiers réseau comme NFS pour sa couche Gitaly, qui sert les dépôts (prérequis GitLab). Retenez la règle générale : un disque lent ou partagé se paie en temps de clone.

Sur quels critères choisir une forge à exploiter ?

Six critères séparent les forges du point de vue d'un exploitant : licence et gouvernance, cycle de support, ressources, fonctions d'administration, CI intégrée et migration. Une liste de fonctionnalités vous renseigne sur ce que les utilisateurs verront ; ces six critères disent ce que vous subirez dans trois ans. Chacun est traité ci-dessous avec la source qui l'établit.

La licence et la gouvernance protègent-elles votre choix ?

La licence dit ce que vous avez le droit de faire du code, la gouvernance dit qui décide de l'avenir du projet. Forgejo est sous GPL v3 ou ultérieure depuis la version 9.0 (MIT jusqu'à la 8.0 incluse), selon sa FAQ ; il est placé sous l'égide de l'association à but non lucratif Codeberg e.V., qui garde ses domaines, mais dont la gouvernance reste indépendante, définie par ses contributeurs. Quant à Gitea, elle est sous licence MIT selon le site du projet, qui indique une direction et un support commerciaux assurés par CommitGo Inc., éditrice des offres payantes Gitea Enterprise et Gitea Cloud. GitLab est édité par une société : dans son dépôt, le code hors des répertoires ee/, jh/ et doc/ est sous MIT Expat, la documentation en CC BY-SA 4.0 et ee/ sous une licence à part (licence).

Forgejo est né fin 2022 d'une fracture de la communauté Gitea, lorsque les domaines et la marque de Gitea sont passés à une société commerciale. Il est devenu un fork (une copie du projet qui évolue désormais séparément) tout à fait indépendant, un hard fork, début 2024 (comparaison avec Gitea). Cette page est écrite par le projet Forgejo : lisez-la comme un argumentaire, pas comme un arbitrage neutre. Pour un exploitant, la question utile est simple : que se passe-t-il si l'éditeur change de politique ? Une association et une licence copyleft (qui impose de redistribuer sous la même licence les versions modifiées) réduisent ce risque ; elles ne le suppriment pas.

Quel cycle de support promet chaque projet ?

Le cycle de support décide du rythme auquel vous devrez monter de version. Forgejo publie une version stable tous les trois mois et une version LTS par an (installation). Le calendrier de publication donne la 15.0 (LTS) supportée jusqu'au 15 juillet 2027, la 17.0 stable jusqu'au 28 janvier 2027 et la 14.0 en fin de vie depuis le 30 avril 2026. Une LTS reste supportée plus d'un an (quinze mois pour la 15.0), et la LTS suivante, la 19.0, est prévue le 15 avril 2027 : cela laisse trois mois pour monter. La stable, elle, réclame une montée par trimestre.

GitLab suit un autre rythme : une version mineure chaque mois, une majeure chaque année. Sa politique de maintenance corrige les bogues sur la seule version courante (19.5 au moment de l'écriture) et les failles de sécurité sur les deux versions précédentes. Rester longtemps sur une même version n'est donc pas prévu. Pour Gitea, la dernière version est la 28.1.0, publiée le 6 octobre 2026. La documentation consultée ne publie aucune politique de support pour l'édition communautaire, ni LTS, au 16 octobre 2026. La seule trace est la page cadence de publication de l'offre Enterprise : elle dit qu'aucune matrice de fin de vie par version n'est publiée et qu'une version majeure reste « courante » jusqu'à la sortie de la suivante. Pour la durée des correctifs sur une version précédente, la documentation renvoie au contrat de support : ne présumez pas d'une maintenance au-delà de la version courante.

Quelles ressources faut-il prévoir ?

GitLab réclame une machine nettement plus grosse que Forgejo ou Gitea. Pour une installation sur un seul nœud, sa documentation donne 8 vCPU et 16 Go de RAM comme base, et accepte au minimum 8 Go dans un environnement contraint (prérequis GitLab). La documentation de Gitea juge « 2 CPU cores and 1GB RAM » typiquement suffisants pour de petites équipes (documentation Gitea).

Forgejo ne publie pas, dans sa documentation d'installation, de configuration minimale chiffrée (aucune trouvée au 16 octobre 2026). Comme il partage son origine avec Gitea, on peut s'attendre à un ordre de grandeur proche, mais c'est une inférence : dimensionnez en mesurant sur votre charge réelle. Avec GitLab, au contraire, le dimensionnement se pense avant l'achat du serveur.

Quelles fonctions d'administration trouve-t-on ?

Une forge s'exploite par une interface d'administration et par une ligne de commande. GitLab a une zone d'administration très riche, les outils gitlab-ctl et la console Rails, et une formation officielle d'administration de plusieurs modules. Forgejo propose une documentation d'administration qui couvre l'authentification (par annuaire LDAP, par PAM ou par OIDC, des moyens de déléguer la connexion), la sauvegarde, les quotas, la modération et une commande forgejo pour les tâches d'administration (documentation d'administration). La documentation de Gitea est de même nature.

Le critère concret est ce que vous voulez automatiser : créer des comptes, verrouiller un utilisateur, sauvegarder, vérifier l'état de l'instance. Une commande scriptable vaut mieux qu'un clic, et les trois projets en offrent une en ligne de commande. La formation enseigne ces gestes sur Forgejo ; GitLab a son module optionnel.

La CI intégrée remplace-t-elle un outil séparé ?

Les trois forges embarquent une CI, mais leurs workflows ne sont pas interchangeables. Forgejo Actions est « designed to be familiar to users of GitHub Actions, but it is not designed to be compatible » : la syntaxe y ressemble à celle de GitHub, sans promesse de compatibilité (présentation de Forgejo Actions). Un workflow copié depuis GitHub peut donc demander des adaptations, à tester avant de promettre une migration. Gitea annonce de son côté une CI « compatible with GitHub Actions » ; c'est son affirmation, à vérifier sur vos workflows. GitLab CI utilise un format propre, .gitlab-ci.yml.

Dans les trois cas, l'exécution revient à un runner séparé, avec les mêmes risques de sécurité. Un outil de provisionnement de runners existe pour Gitea : GARM ne gère pas Forgejo, d'après le README du projet, et reste donc hors de cette formation. Si vous avez déjà une CI externe qui vous convient, une forge sans CI intégrée n'est pas un défaut.

Comment migrer vers une forge, et en repartir ?

Les dépôts Git se déplacent sans peine, le reste dépend des outils d'import. Un dépôt se copie par git clone --mirror puis git push --mirror. Les tickets, les pull requests, le wiki et les droits ne suivent que si la forge d'arrivée sait les importer depuis la forge d'origine. Avant de vous engager, essayez l'import d'une organisation de test, en comptant ce qui manque.

Forgejo documente un chemin depuis Gitea dans son guide de montée de version (installation). Comme Gitea 28 a divergé de Forgejo, la migration est limitée : le guide de migration accepte les versions de Gitea jusqu'à la 1.22.x incluse, vers Forgejo 10.0.x, puis de la 10.0.x vers une version plus récente. Une instance Gitea plus récente que la 1.22 sort donc du chemin documenté. La formation consacre une leçon à la migration d'une organisation ; le guide Plateformes Git traite la migration du point de vue de l'utilisateur.

Forgejo, Gitea ou GitLab : que choisir ?

Forgejo convient à une équipe qui veut une forge légère sous gouvernance communautaire ; GitLab, à celle qui veut une plateforme complète et peut en payer l'exploitation ; Gitea, à celle qui accepte un éditeur commercial et une licence MIT. Le tableau résume les six critères (la licence et la gouvernance y occupent deux lignes) et ajoute la base de données. Lisez-le colonne par colonne : chaque cellule renvoie à la source citée plus haut, et une cellule qui dit « pas de minimum publié » ou « aucune politique publiée » signale un fait que la documentation consultée n'établit pas.

Critère	Forgejo	Gitea	GitLab (CE)
Licence	GPL v3+ depuis la 9.0	MIT	MIT Expat hors ee/, jh/, doc/
Gouvernance	indépendante, domaines chez Codeberg e.V.	direction commerciale CommitGo Inc.	société GitLab
Support	stable trimestrielle, LTS annuelle (15 jusqu'au 2027-07-15)	aucune LTS ni politique publiée trouvées (édition communautaire)	mensuel, correctifs de sécurité sur 3 versions
Ressources	pas de minimum publié, à mesurer	2 cœurs et 1 Go pour une petite équipe	8 vCPU et 16 Go (8 Go minimum contraint)
Base de données	SQLite, MariaDB, MySQL, PostgreSQL	PostgreSQL, MySQL, MariaDB, SQLite, MSSQL	PostgreSQL seul
CI intégrée	Forgejo Actions, proche de GitHub Actions sans compatibilité promise	Gitea Actions, annoncée compatible	GitLab CI, format propre
Migration	depuis Gitea 1.22.x au plus	non évaluée ici	non évaluée ici

Glissez pour voir

Les trois colonnes ne pèsent pas pareil dans la formation. Forgejo 15 LTS est la forge de référence : sa LTS tient jusqu'à l'été 2027, ce qui laisse le temps de s'exercer sans courir derrière les versions. GitLab a un module optionnel, aligné sur le programme officiel d'administration de GitLab. Gitea garde ses pages de référence, dont la présentation de Gitea, mais n'est pas enseigné : sa version 28 diverge de Forgejo, et une commande ou un chemin valable chez l'un peut ne plus l'être chez l'autre.

Pour GitLab, la présentation de GitLab couvre la plateforme. Mon avis, pour une équipe de quelques dizaines de personnes sans besoin de gestion de portefeuille de projets : je prends Forgejo sur sa LTS. La raison tient à l'exploitation, pas aux fonctions : un rythme de montée de version prévisible et, très probablement, une machine modeste (à mesurer).

Et la haute disponibilité, et Kubernetes ?

La haute disponibilité (HA) sert à survivre à la panne d'une machine en exploitant plusieurs instances ; elle reste hors du périmètre de cette formation. Avant d'en avoir besoin, posez la question de l'exploitant : combien de temps l'équipe peut-elle rester sans forge ? Pour beaucoup d'équipes, une instance unique, une sauvegarde testée et une restauration rapide répondent au besoin ; la leçon Sauvegarder et restaurer Forgejo traite ce sujet.

La documentation de GitLab donne la mesure de l'effort : elle écrit que la HA est complexe et que les environnements requis peuvent être volumineux (architectures de référence). Elle prévoit une architecture « Cloud Native Hybrid » où les composants sans état tournent dans Kubernetes avec un chart Helm, tandis que PostgreSQL et Redis restent sur des machines ou des services managés, car faire tourner ces composants à état dans Kubernetes n'est pas pris en charge. Pour une forge répartie entre plusieurs régions, GitLab propose Geo.

Forgejo se déploie aussi dans des conteneurs, mais la formation ne traite ni sa HA ni son déploiement sur Kubernetes. Si ce besoin se présente, partez des notions de cette leçon : chaque brique du schéma devient alors une pièce à répliquer, et ce sont en général la base de données et le stockage, plus que l'application, qui compliquent l'opération. La place d'une forge dans une architecture plus large est traitée dans Forges, dépôts d'artefacts et registres.

Quelles erreurs de choix éviter ?

Cinq erreurs reviennent quand on choisit une forge sur sa liste de fonctions. Elles viennent presque toutes d'un coût d'exploitation sous-estimé.

• Dimensionner sur une vieille page. Les prérequis de GitLab changent d'une version à l'autre : lisez la page officielle de la version que vous installez, pas un billet ancien.
• Installer la stable sans plan de montée. Une version stable de Forgejo sort de support en un trimestre environ ; sans calendrier de montée, vous finissez hors support.
• Croire à la compatibilité GitHub Actions. Forgejo ne la promet pas : testez vos workflows avant de migrer une équipe.
• Laisser le runner sur la machine de la forge. Un job malveillant atteindrait alors les dépôts et la base.
• Viser la haute disponibilité trop tôt. Une sauvegarde restaurée avec succès vaut mieux qu'un cluster que personne ne sait exploiter.

À retenir

• Une forge est un serveur Git doté de comptes, de revues de code, et souvent de CI et de registre : l'auto-héberger vous rend responsable de la base, du stockage, du proxy, des sauvegardes et des montées de version.
• Ses briques sont l'application, l'accès SSH, la base, le stockage, le reverse proxy et le runner ; le SSH contourne le proxy HTTP et le runner s'isole de la forge.
• Six critères d'exploitant : licence et gouvernance, cycle de support, ressources, fonctions d'administration, CI intégrée, migration.
• Forgejo 15 LTS est supportée jusqu'au 15 juillet 2027 ; la stable 17 jusqu'au 28 janvier 2027 ; GitLab sort une version par mois et ne corrige la sécurité que sur trois versions (la courante et les deux précédentes).
• GitLab demande 8 vCPU et 16 Go de RAM sur un nœud (8 Go au minimum en environnement contraint) ; Gitea annonce 2 cœurs et 1 Go pour une petite équipe, et Forgejo ne publie pas de minimum : à mesurer.
• Forgejo Actions n'est pas compatible GitHub Actions : elle y ressemble, sans le promettre.
• La haute disponibilité et Kubernetes sont hors périmètre : on commence par une instance unique, une sauvegarde restaurée et une montée de version maîtrisée.

Contrôle de connaissances

Six questions tirées sur huit : par où passe le SSH, pourquoi isoler le runner, la base de GitLab, le choix de la LTS, la question à poser avant la haute disponibilité, et la licence de Forgejo.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →