Gitea vs GitLab : quelle forge Git self-hosted sur VPS ?

Une forge Git auto-hébergée garde ta propriété intellectuelle hors des plateformes publiques et supprime toute limite arbitraire sur le nombre de dépôts privés, de collaborateurs ou de minutes de CI. Sur un VPS, tu maîtrises la localisation des données, les sauvegardes et l'intégration avec ton pipeline interne. Gitea (et son fork Forgejo) est écrit en Go : un binaire unique, démarrage instantané, empreinte mémoire minime, idéal pour un VPS modeste. GitLab CE est une suite intégrée (issues, CI/CD, registre Docker, registre de paquets, wiki, environnements) mais consomme bien plus de RAM. Le choix dépend de ton besoin : un Git propre et rapide, ou une plateforme DevOps complète en un seul produit.

Gitea est publié sous licence MIT : tu peux lire le code, le modifier, le redistribuer et l'héberger sans contrainte commerciale. Forgejo, son fork communautaire né en 2022, applique la même licence. GitLab CE est lui aussi MIT — mais uniquement la couche Community Edition. GitLab EE (Enterprise Edition) est propriétaire : les fonctionnalités premium (SAML SSO avancé, approbations de MR multiples, SAST/DAST intégrés, epics, roadmaps) sont verrouillées derrière un abonnement payant qui commence à plusieurs centaines d'euros par utilisateur et par an. Pour une équipe qui self-host GitLab CE, le risque principal n'est pas la licence mais l'effet d'aspiration : les fonctionnalités manquantes du CE poussent progressivement vers l'EE payant. Avec Gitea ou Forgejo, l'intégralité des fonctionnalités disponibles est incluse dans la version libre, sans tier payant. Si la compliance ou les audits de licence comptent dans ton contexte — administration, sous-traitance publique ou grands comptes — cette différence est structurante.

Gitea consomme environ 100 à 150 Mo de RAM au repos pour un déploiement Docker standard avec PostgreSQL. Avec une dizaine de runners actifs et quelques pipelines simultanés, tu restes sous 400 Mo pour la forge elle-même. C'est dimensionnable sur un VPS à 2 Go de RAM en laissant de la place pour le système et la base. GitLab CE en omnibus est dans une catégorie différente : PostgreSQL, Redis, Sidekiq, Gitaly, Puma et NGINX tournent en parallèle. Au repos, l'ensemble dépasse couramment 3 à 4 Go de RAM sur un déploiement neuf et peut grimper à 6 à 8 Go sous charge CI. GitLab recommande officiellement 8 Go de RAM pour un usage en production avec CI activé. Sur le CPU, Gitea est quasi invisible au repos ; GitLab déclenche des processus Sidekiq en arrière-plan (indexation, webhooks, nettoyages) qui consomment du CPU de manière intermittente même sans activité visible.

Gitea Actions est apparu dans Gitea 1.19 (2023) et reprend exactement la syntaxe des workflows GitHub Actions : les fichiers .github/workflows/*.yml existants sont réutilisables sans modification dans la plupart des cas. L'exécuteur sous-jacent est act (le moteur open source qui simule GitHub Actions localement), encapsulé dans un runner Docker. C'est suffisant pour la majorité des pipelines : build, test, lint, push d'image, déploiement SSH. Les limites apparaissent sur les cas avancés : pas de caches partagés entre runners à l'échelle, pas d'environnements de review nativement, gestion des artefacts plus limitée. GitLab CI est plus mature sur ces points : runners distribués sur plusieurs machines, exécuteurs Kubernetes, caches partagés, environnements dynamiques, review apps, pages de rapports de test inline, règles rules: et include: puissantes. Si ton pipeline dépasse la dizaine de jobs parallèles, gère des environnements de review par MR ou requiert un SAST/DAST intégré au rapport de merge, GitLab CI est irremplaçable dans sa version CE (pour la CI/CD elle-même — les SAST restent EE). La règle pratique : Gitea Actions suffit pour les équipes de 1 à 20 développeurs avec des pipelines standards ; GitLab CI s'impose dès que la maturité du pipeline devient un critère de choix en soi.

La CVE-2026-85706 est une vulnérabilité de type Server-Side Request Forgery (SSRF) découverte dans GitLab CE et EE affectant les versions antérieures au correctif de mars 2026. Elle permet à un attaquant authentifié de forcer GitLab à effectuer des requêtes HTTP vers des ressources internes du réseau via la fonctionnalité d'import de dépôt distant. Sur un VPS où GitLab partage le réseau interne avec d'autres services (bases de données, registres, APIs), l'exposition est réelle. Gitea n'est pas affecté par cette CVE spécifique — son code d'import distant est distinct. La migration GitLab → Gitea est documentée et couverte par l'outil gitea-migration-tool : il importe les dépôts, les issues, les labels, les milestones, les pull requests et les commentaires depuis l'API GitLab. Les pipelines CI/CD ne migrent pas automatiquement (syntaxe GitLab CI ≠ Gitea Actions), mais pour les équipes utilisant une syntaxe proche de GitHub Actions dans leur CI GitLab, la conversion est légère. Si tu utilises une version de GitLab CE non patchée sur un VPS exposé, la migration vers Gitea ou la mise à jour urgente sont les deux seules options raisonnables.

Gitea est frugal : 1 vCPU et 1 Go de RAM suffisent pour une petite équipe, 2 Go avec la base de données et quelques runners. GitLab CE est bien plus gourmand : vise au minimum 4 Go de RAM (8 Go recommandés en usage réel avec CI), 4 vCPU et un disque rapide, car la suite embarque PostgreSQL, Redis, Sidekiq et Gitaly. Dans les deux cas il te faut Docker et Compose, un sous-domaine (git.tondomaine.com), un reverse proxy pour le TLS, et idéalement un second sous-domaine si tu actives le registre Docker. Prévois un volume dédié aux dépôts et une stratégie de sauvegarde.