Pourquoi cette question est urgente en 2026
La CVE-2026-59774 a été publiée le 2 août 2026 dans l'avis de sécurité de Gitea. Elle touche Gitea versions 1.22.1 à 1.27.0 inclus — score CVSS 9.8, critique. Le vecteur : la directive #+INCLUDE du rendu Org-mode permet à un attaquant non authentifié de lire des fichiers arbitraires accessibles au compte de service Gitea, y compris app.ini et les tokens internes. L'exposition de INTERNAL_TOKEN ouvre ensuite la voie à une injection de hook Git et à l'exécution distante de code. Le correctif est dans la version 1.27.1. Si votre instance tourne sous une version antérieure et n'est pas isolée du réseau public, patcher est la première action. La seconde est de décider si vous restez sur Gitea ou si la situation accélère une migration que vous différiez. Forgejo, qui maintient ses propres correctifs de sécurité indépendamment de Gitea Ltd., avait déjà corrigé la même faille du rendu Org-mode dans ses versions v16.0.2 et v15.0.6, publiées le 30 juillet 2026, avant l'avis de Gitea.
Ce qui a changé depuis 2024 et qui pèse sur ce choix
- Forgejo est un fork dur depuis début 2024 — la base de code a divergé de Gitea ; les deux projets partagent encore l'essentiel, mais les chemins d'évolution diffèrent désormais clairement
- Gouvernance communautaire chez Forgejo — géré par une association à but non lucratif, sans accord de contribution signé par la maison mère ; les correctifs de sécurité arrivent indépendamment
- Forgejo Actions en production — syntaxe proche de GitHub Actions, comme Gitea Actions (Forgejo prévient qu'un workflow GitHub demande souvent quelques retouches), exécutée par des runners Docker ; Woodpecker CI reste une alternative qui s'intègre à Forgejo, et Codeberg ne propose encore Actions en hébergé que de façon limitée
- Forgejo v16.0 en juillet 2026 — commentaires de revue multi-lignes (sélection de plage de lignes dans le diff, threads inline), authentification JWT externe pour l'API (permet à des systèmes externes de s'authentifier sans token permanent), durcissement SSRF du mirroring Git (les règles
[migrations]s'appliquent partout et Git ne suit plus les redirections), réduction de bande passante sur les avatars ; branche non LTS, plus maintenue depuis le 29 octobre 2026 : ses nouveautés se retrouvent dans Forgejo v17.0 (octobre 2026) - Forgejo v15.0 en avril 2026 — workflow d'enregistrement de runner simplifié via l'interface web, tokens restreints par dépôt, 100e release de Forgejo
- GitLab CE toujours complet mais lourd — la version communautaire intègre CI/CD, registre de conteneurs, scanning de sécurité et Pages ; le prix : 8 Go de RAM au minimum, 16 Go recommandés
- La hiérarchie qui se dégage en 2026 : Forgejo pour démarrer, Gitea si vous y êtes déjà et à jour, GitLab CE si vous avez besoin d'une plateforme DevOps complète dans une seule installation
Prérequis selon votre choix
Forgejo et Gitea sont écrits en Go et livrent un binaire statique unique. Une instance modeste (jusqu'à vingt dépôts, quelques CI runners) tourne confortablement sur 1 vCPU et 1 Go de RAM ; une instance d'équipe (runners CI actifs, LFS, registre de paquets) préférera 2 vCPU et 2 à 4 Go. GitLab CE est dans une autre catégorie : sa documentation fixe le plancher à 8 Go de RAM et recommande 16 Go, avec Postgres, Redis, Gitaly et Sidekiq qui tournent en parallèle. Elle prévoit 8 vCPU et au moins 40 Go de stockage SSD pour l'application, plus la taille de vos dépôts. Pour les trois outils, vous aurez besoin d'un domaine pointé sur votre VPS, des ports 22 (SSH Git), 80 et 443 ouverts, et d'un reverse proxy (Nginx ou Caddy) pour le HTTPS.
Forgejo vs Gitea vs GitLab CE — tableau comparatif 2026
Faites défiler le tableau
| Critère | Forgejo / Gitea | GitLab CE |
|---|---|---|
| RAM minimale | Pas de minimum officiel (1 Go pour une petite équipe) | 8 Go (16 Go recommandés) |
| Format de distribution | Binaire statique unique ou image Docker | Omnibus (multi-processus) ou Helm chart |
| CI/CD natif | Forgejo Actions / Gitea Actions (syntaxe GitHub Actions) | GitLab CI/CD intégré, runners partagés ou dédiés |
| Gouvernance | Forgejo : association non-profit (Codeberg) · Gitea : Gitea Ltd. | GitLab Inc. (open-core, CE libre) |
| Registre de conteneurs | Oui (packages + container registry) | Oui, plus complet |
| Fédération / ActivityPub | Forgejo : expérimentale, désactivée par défaut · Gitea : non prévu | Non |
| Correctifs sécurité indépendants | Forgejo : oui (faille Org-mode corrigée en v16.0.2, juillet 2026) · Gitea : via Gitea Ltd. | Via GitLab Inc. |
| Nouveautés v16 (juillet 2026) | Forgejo : revues multi-lignes, JWT externe, SSRF renforcé · Gitea : 1.27.1 correctif seul | Sans objet |
| Migration depuis Gitea | Forgejo : reprise directe de la base jusqu'à Gitea 1.22, au-delà migration dépôt par dépôt · GitLab : importeur Gitea | Import partiel (dépôts, issues, PRs) |
| Idéal pour | Équipes de 1 à 50 développeurs, VPS modeste, CI légère | Organisation qui veut tout dans une seule install, budget infra disponible |
Migrer de Gitea vers Forgejo : ce que c'est vraiment
La migration Gitea → Forgejo est souvent décrite comme « une commande » — c'est vrai dans le cas simple. Mais seulement jusqu'à Gitea 1.22 : Forgejo indique que Gitea 1.22 est la dernière version reprise de façon transparente. Depuis Gitea 1.23, les schémas de base de données ont divergé, et la voie officielle consiste à migrer les dépôts un par un avec l'outil de migration intégré à Forgejo. Pour une instance en 1.22.x au plus, la procédure se résume à arrêter le conteneur Gitea, pointer le même volume de données vers une image Forgejo, démarrer. Forgejo détecte le schéma existant et applique ses propres migrations. Quelques points à vérifier avant : sauvegardez app.ini et la base de données, notez la version Gitea en cours (la reprise passe d'abord par Forgejo v10.0, puis vers une version plus récente), et relisez vos workflows CI (Forgejo Actions et Gitea Actions ont des syntaxes proches : testez-les sur un dépôt avant de basculer). La migration dans l'autre sens — vers GitLab CE — est plus longue : GitLab propose un importeur Gitea (dépôts, issues, pull requests, jalons, labels), mais les pipelines CI doivent être réécrits en syntaxe GitLab CI.
Déployer Forgejo sur un VPS avec Docker et Nginx
Préparer le VPS
Mettez le système à jour et installez Docker et Docker Compose :
apt update && apt install -y docker.io docker-compose-plugin. Ouvrez les ports nécessaires :ufw allow 22/tcp && ufw allow 80/tcp && ufw allow 443/tcp && ufw allow 2222/tcp(2222 pour SSH Git si vous ne voulez pas exposer le 22 du système). Attention : les ports publiés par Docker contournent les règles ufw ; ne publiez donc que ce qui doit l'être (étape suivante).Créer les répertoires et le fichier Compose
Créez un répertoire dédié :
mkdir -p /opt/forgejo && cd /opt/forgejo. Puis créez un fichiercompose.ymlavec un serviceforgejopointant l'imagecodeberg.org/forgejo/forgejo:17(tag de version majeure, comme dans la documentation officielle), un volume persistant pour/data, les ports127.0.0.1:3000:3000(HTTP, joignable par Nginx seulement) et2222:22(SSH), et des variables d'environnement minimales (FORGEJO__server__DOMAIN=git.votre-domaine.com,FORGEJO__server__SSH_PORT=2222).Démarrer Forgejo
Lancez le service :
docker compose up -d. Vérifiez que le conteneur est actif avecdocker compose pset consultez les logs avecdocker compose logs -f forgejo. Le port 3000 n'écoute que sur la machine : vérifiez aveccurl -I http://127.0.0.1:3000, et ne terminez l'assistant d'installation qu'une fois le HTTPS en place (étape 6), pour que personne ne le termine avant vous.Configurer Nginx en reverse proxy HTTPS
Installez Nginx et Certbot :
apt install -y nginx python3-certbot-nginx. Créez un virtual host pourgit.votre-domaine.comqui proxifie vershttp://localhost:3000avec les en-têtes proxy standard (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).Obtenir le certificat TLS
Exécutez
certbot --nginx -d git.votre-domaine.com. Certbot configure la redirection HTTP→HTTPS et programme le renouvellement automatique. Vérifiez aveccurl -I https://git.votre-domaine.comque le code est bien200.Finaliser l'installation via l'interface web
Ouvrez
https://git.votre-domaine.comdans un navigateur. L'assistant d'installation vous demande le type de base de données (SQLite pour démarrer, PostgreSQL pour la production), l'URL de l'instance, et les paramètres SSH. Créez le compte administrateur, puis désactivez les inscriptions publiques si l'instance est privée (FORGEJO__service__DISABLE_REGISTRATION=truedanscompose.yml).Activer un runner CI (optionnel)
Forgejo v15.0 (avril 2026) a introduit un workflow d'enregistrement de runner simplifié via l'interface web. Allez dans Paramètres du site → Actions → Runners, cliquez Créer un runner et copiez la commande d'enregistrement. Lancez le runner dans un second conteneur, à côté d'un service
docker:dindqui exécute les jobs, comme dans l'exemple Compose de la documentation officielle (imagedata.forgejo.org/forgejo/runner:13, commandeforgejo-runner daemon --config runner-config.yml). Évitez de monter/var/run/docker.sock: les workflows obtiendraient l'équivalent d'un accès root à l'hôte.Vérifier la sécurité de base (mise à jour v16)
Forgejo v16.0 a durci la protection SSRF du mirroring Git : les réglages
[migrations](ALLOWED_DOMAINS,BLOCKED_DOMAINS,ALLOW_LOCALNETWORKS) s'appliquent désormais à toutes les opérations de migration et de mirroring, et Git ne suit plus les redirections HTTP.FORGEJO__migrations__ALLOW_LOCALNETWORKSreste àfalsepar défaut : si vous avez des besoins de mirroring vers des dépôts internes sur le réseau local, déclarez-les dansFORGEJO__migrations__ALLOWED_DOMAINSplutôt que d'ouvrir tout le réseau local, et évaluez-en l'impact. LaissezFORGEJO__server__LOCAL_ROOT_URLà sa valeur par défaut (l'adresse locale par laquelle les processus internes joignent le service web), sauf si le SSH tourne sur une autre machine. Pour les instances migrées depuis Gitea affectées par la CVE-2026-59774 : régénérezINTERNAL_TOKEN(forgejo generate secret INTERNAL_TOKEN), puis rotez les tokens d'accès personnels de vos utilisateurs. Ne remplacez pasSECRET_KEYà la légère : il chiffre notamment les secrets 2FA, que la nouvelle clé ne pourrait plus déchiffrer.
Pour une forge Gitea existante affectée par la CVE-2026-59774 (versions 1.22.1 à 1.27.0) : la mise à jour vers Gitea 1.27.1 ou une version ultérieure corrige la vulnérabilité, et c'est la première chose à faire. Migrer vers Forgejo n'est un raccourci que depuis Gitea 1.22.x, dernière version dont Forgejo reprend la base ; depuis Gitea 1.23, patchez d'abord Gitea, puis migrez dépôt par dépôt si vous choisissez Forgejo. En migrant vers Forgejo v16.0+, vous bénéficiez en outre du durcissement SSRF du mirroring, des commentaires de revue multi-lignes et de l'authentification JWT externe — des fonctionnalités indisponibles dans Gitea 1.27.1. Dans tous les cas, après toute exposition suspectée, régénérez INTERNAL_TOKEN, rotez les tokens d'accès personnels de vos utilisateurs et vos secrets OAuth, et ne changez SECRET_KEY qu'en sachant que les secrets 2FA chiffrés avec l'ancienne clé deviendront illisibles.
Dépannage : erreurs fréquentes à l'installation
Les erreurs ci-dessous couvrent les cas les plus fréquents lors d'un premier déploiement ou d'une migration.
Erreurs courantes et leurs remèdes
level=fatal msg="Failed to initialize ORM engine" error="Error 1071: Specified key was too long"(MySQL/MariaDB) — la collation de la base n'est pasutf8mb4: créez la base avecCHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ciet redémarrezFailed to initialize SSH: ssh: no key found— une clé d'hôte SSH est vide ou illisible : vérifiez que le volume/dataest bien monté et appartient à l'UID/GID déclarés dans le Compose (1000:1000 par défaut), puis supprimez le fichier de clé vide et redémarrez le conteneur pour qu'il soit recréé ;forgejo admin regenerate keysne régénère que le fichierauthorized_keysx509: certificate signed by unknown authoritysur les webhooks sortants — votre instance appelle un service interne avec un certificat auto-signé ; ajoutezFORGEJO__webhook__SKIP_TLS_VERIFY=trueuniquement en dev, ou montez le certificat CA dans le conteneur viaSSL_CERT_FILEError response from daemon: conflict: unable to delete imagelors d'une mise à jour — arrêtez d'abord le conteneur (docker compose down), supprimez l'image (docker image rm codeberg.org/forgejo/forgejo), puis repullez (docker compose pull) avant de redémarrer- Runners CI bloqués sur
waiting for available runneraprès l'enregistrement — vérifiez que le runner peut joindre l'instance Forgejo :curl -s https://git.votre-domaine.com/api/v1/versiondepuis le conteneur runner doit retourner un JSON avec la version ; si le nom de domaine ne résout pas depuis le conteneur, ajoutez unextra_hostsdans le Compose ou passez par l'IP du VPS - Mirroring de dépôt refusé après migration vers v16 — Forgejo v16.0 applique strictement les réglages
[migrations], avecFORGEJO__migrations__ALLOW_LOCALNETWORKS=falsepar défaut : un mirror vers une adresse du réseau local, ou servi derrière une redirection HTTP, peut être refusé ; si votre mirror cible un GitLab ou Gitea interne, déclarez son domaine dansFORGEJO__migrations__ALLOWED_DOMAINSplutôt que d'ouvrir tout le réseau local
Quel outil choisir selon votre situation
Pour une nouvelle installation en 2026 : Forgejo est le choix par défaut que nous recommandons. La gouvernance communautaire, les correctifs de sécurité indépendants de Gitea Ltd. (illustrés par la faille Org-mode de la CVE-2026-59774, corrigée chez Forgejo dès le 30 juillet 2026), la compatibilité avec l'outillage existant (runners, webhooks, tokens) et l'empreinte mémoire identique à Gitea réunissent les arguments sans contrepartie notable pour un nouveau projet. Avec Forgejo v16.0, les commentaires de revue multi-lignes et l'authentification JWT externe comblent deux lacunes fonctionnelles qui justifiaient parfois le choix de GitLab CE. Si vous exploitez déjà une instance Gitea à jour (1.27.1+) et qu'elle répond à vos besoins, la migration n'est pas urgente — mais la prochaine fois que vous envisagez une mise à jour majeure, évaluez Forgejo à ce moment, sachant que depuis Gitea 1.23 le passage se fait dépôt par dépôt. GitLab CE s'impose quand votre équipe a besoin de l'intégralité de la chaîne DevOps dans une seule installation — scanning de sécurité, pages, environnements de déploiement, registre de conteneurs — et que vous disposez de l'infrastructure pour le faire tourner confortablement. Sur un VPS modeste, ce n'est pas le bon outil. Pour aller plus loin : notre guide d'installation détaillé de Forgejo, la mise en place d'un pipeline CI avec Woodpecker et l'article sur le durcissement initial d'un serveur Linux complètent ce comparatif.
