Pourquoi cette question est urgente en 2026
La CVE-2026-59774 a été publiée le 4 août 2026. Elle touche Gitea versions 1.22.1 à 1.27.0 inclus — score CVSS 9.9, 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.
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 identique à Gitea Actions (GitHub Actions-compatible), compatible avec Woodpecker CI et les runners Docker, active sur Codeberg depuis 2024
- Forgejo v16.0 en juillet 2026 — commentaires de revue multi-lignes, authentification JWT externe pour l'API, durcissement SSRF, réduction de bande passante sur les avatars
- GitLab CE toujours complet mais lourd — la version communautaire intègre CI/CD, registre de conteneurs, scanning de sécurité et Pages ; le prix : 4 Go de RAM minimum, 8 Go recommandés
- Cinq comparatifs indépendants publiés en 2026 convergent vers la même hiérarchie : 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 : 4 Go de RAM est le minimum absolu pour démarrer, 8 Go pour une utilisation confortable, avec Postgres, Redis, Gitaly et Sidekiq qui tournent en parallèle. Prévoyez au moins 4 vCPU et 50 Go de stockage SSD. 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
| Critère | Forgejo / Gitea | GitLab CE |
|---|---|---|
| RAM minimale | 512 Mo – 1 Go | 4 Go (8 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 : beta opt-in · Gitea : non prévu | Non |
| Migration depuis Gitea | Forgejo : même schéma de base, une commande · GitLab : import API ou migrator | 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. Les deux projets ont partagé le même schéma de base de données depuis l'origine et Forgejo maintient la compatibilité ascendante. 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 migration est testée depuis les versions récentes — une instance très ancienne peut nécessiter une mise à jour intermédiaire), et vérifiez que vos runners CI utilisent la même syntaxe (Forgejo Actions et Gitea Actions sont compatibles). La migration dans l'autre sens — vers GitLab CE — est plus longue : GitLab propose un outil d'import via API (dépôts, issues, merge requests, 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).
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 fichier compose.yml avec un service forgejo pointant l'image codeberg.org/forgejo/forgejo:latest, un volume persistant pour /data, les ports 3000:3000 (HTTP) et 2222: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 avec docker compose ps et consultez les logs avec docker compose logs -f forgejo. L'interface d'installation est disponible sur http://<ip-du-vps>:3000.
Configurer Nginx en reverse proxy HTTPS
Installez Nginx et Certbot : apt install -y nginx python3-certbot-nginx. Créez un virtual host pour git.votre-domaine.com qui proxifie vers http://localhost:3000 avec 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 avec curl -I https://git.votre-domaine.com que le code est bien 200.
Finaliser l'installation via l'interface web
Ouvrez https://git.votre-domaine.com dans 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=true dans compose.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 : docker run -d --name forgejo-runner -v /var/run/docker.sock:/var/run/docker.sock codeberg.org/forgejo/runner:latest daemon --config config.yml.
Vérifier la sécurité de base
Contrôlez que FORGEJO__server__LOCAL_ROOT_URL ne pointe pas vers une IP interne exposée (vecteur SSRF). Depuis Forgejo v16.0, le durcissement SSRF est actif par défaut pour le mirroring Git — vérifiez FORGEJO__migrations__ALLOW_LOCALNETWORKS dans votre config si vous avez des besoins de mirroring vers des dépôts internes.
Pour une forge Gitea existante affectée par la CVE-2026-59774 (versions 1.22.1 à 1.27.0) : la migration vers Forgejo et la mise à jour vers Gitea 1.27.1 corrigent toutes les deux la vulnérabilité. Si vous choisissez de rester sur Gitea, appliquez le patch immédiatement. Si vous envisagez Forgejo depuis un moment, la migration résout les deux problèmes en une opération : patchez en migrant plutôt qu'en mettant à jour puis en migrant. Dans tous les cas, invalidez INTERNAL_TOKEN et SECRET_KEY dans app.ini après toute exposition suspectée, et rotez les tokens d'accès personnels de vos utilisateurs.
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— Forgejo cherche les clés SSH dans/data/gitea/.ssh; si le volume n'est pas monté ou si les permissions sont incorrectes, lancezdocker compose exec forgejo forgejo admin regenerate keyspour les régénérerx509: 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
Quel outil choisir selon votre situation
Pour une nouvelle installation en 2026 : Forgejo est le choix par défaut dans la quasi-totalité des comparatifs indépendants publiés cette année. La gouvernance communautaire, les correctifs de sécurité indépendants de Gitea Ltd., 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. 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. 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, DORA metrics — 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.
