Migrer de GitLab vers Gitea sur VPS en 2026

Le 15 août 2026, GitLab a appliqué une nouvelle politique sur son offre gratuite : tout namespace regroupant plus de cinq membres passe automatiquement en lecture seule (source : support.gitlab.com/hc/en-us/articles/28301407860508). Concrètement, les développeurs supplémentaires ne peuvent plus pousser de code, ouvrir des merge requests ni déclencher des pipelines CI/CD. La seule issue proposée par GitLab est la souscription à un abonnement payant — dont le coût par siège devient rapidement significatif pour une startup ou une agence.

Cette décision intervient dans un contexte plus large de monétisation accélérée de la plateforme SaaS. Elle touche en priorité les équipes open-source à faible budget, les agences multi-projets et les développeurs indépendants qui mutualisent un namespace. Ce n'est pas la première restriction de ce type : GitLab avait déjà supprimé les pipelines CI/CD gratuits pour les nouveaux utilisateurs en 2021. Le mouvement est structurel.

Face à cette contrainte, auto-héberger sa forge Git sur un VPS reprend tout son sens. Vous contrôlez les accès, les données restent sur votre infrastructure, et le coût est fixe — celui du serveur, pas celui des sièges.

Côté serveur, Gitea v1.27.3 tourne confortablement avec 512 Mo de RAM pour un usage minimal ; prévoyez 1 Go si vous activez les Actions Gitea avec des runners concurrents. Le template VPS ServOrbit part sur une image Debian 12 avec Docker pré-installé — c'est le mode de déploiement recommandé car il isole le processus Gitea et simplifie les mises à jour.

Côté réseau, pointez un sous-domaine vers l'IP de votre VPS avant de lancer l'installation : Gitea génère les URLs des clones SSH et HTTPS au premier démarrage, et il est fastidieux de les corriger après coup. Un enregistrement A git.mondomaine.com suffit. Prévoyez également un certificat TLS — Caddy ou Traefik peuvent le générer automatiquement via Let's Encrypt en frontal de Gitea.

Sur GitLab.com, vérifiez que vous disposez des droits Owner sur le groupe ou les projets à migrer : l'export nécessite ce niveau d'accès. Générez un token d'API personnel avec les scopes api et read_repository — il servira lors de l'export via l'API REST.

Gitea v1.27.3 intègre Gitea Actions, un moteur de CI/CD dont la syntaxe YAML est volontairement compatible avec GitHub Actions. Si vos pipelines existaient sur GitLab CI, une adaptation est nécessaire — les étapes stages et script de GitLab se traduisent en jobs et steps Gitea Actions — mais la logique reste identique.

Pour activer les runners, installez act_runner sur votre VPS ou sur une machine dédiée : act_runner register --no-interactive --instance https://git.mondomaine.com --token <runner-token> --name mon-runner --labels ubuntu-latest:docker://node:20-bullseye. Le token de registration se trouve dans Site Administration > Runners.

Si vous préférez une CI/CD plus découplée, Woodpecker CI est une alternative mature qui s'intègre nativement à Gitea via OAuth2 et propose une interface de supervision des builds. Son fichier de pipeline .woodpecker.yml est également proche de la syntaxe Drone CI, ce qui simplifie les migrations depuis d'anciens stacks. Dans les deux cas, la première pipeline devrait valider le build, exécuter les tests et, si tout est vert, pousser une image vers le registre Docker de Gitea.

Gitea organise les accès en trois niveaux : les organisations (équivalentes aux groupes GitLab), les équipes au sein d'une organisation, et les permissions par dépôt. Commencez par créer tous les comptes utilisateurs — soit manuellement, soit en activant l'auto-enregistrement temporairement, soit via LDAP/SSO si vous en disposez déjà.

Créez ensuite les équipes dans votre organisation : Owners, Developers, Reporters correspondent aux rôles Owner, Developer et Reporter de GitLab. Gitea permet d'affiner les permissions par dépôt à l'intérieur d'une même équipe — un sous-ensemble de membres peut avoir accès en écriture uniquement à certains repos.

Pour migrer en lot les memberships, l'API Gitea accepte des appels de ce type : curl -X PUT "https://git.mondomaine.com/api/v1/orgs/mon-organisation/teams/<team-id>/members/<username>" -H "Authorization: token <gitea-token>". Un script shell bouclant sur votre liste d'utilisateurs exportée de GitLab suffit pour automatiser cette étape sur des équipes de moins de cinquante personnes. Au-delà, évaluez une intégration LDAP pour synchroniser les groupes automatiquement.

remote: repository not found lors du push miroir. Le dépôt cible n'existe pas encore dans Gitea, ou le token utilisé n'a pas les droits d'écriture. Vérifiez que le dépôt a bien été créé (étape 2 de l'import) et que votre token possède le scope write:repository.

error: src refspec refs/merge-requests/... does not match any lors du push --mirror. Les références internes de GitLab (refs/merge-requests/) ne sont pas acceptées par Gitea. Filtrez-les explicitement : git -C votre-projet.git push --mirror peut être précédé d'une suppression locale des refs parasites avec git -C votre-projet.git for-each-ref --format='%(refname)' refs/merge-requests | xargs -I{} git update-ref -d {}.

Error 413: Request Entity Too Large à l'import d'une archive volumineuse. La taille maximale des uploads est configurée dans app.ini de Gitea sous la clé MAX_UPLOAD_SIZE. Augmentez-la (MAX_UPLOAD_SIZE = 2048 pour 2 Go) et rechargez le service : docker compose restart gitea.

Les issues importées n'affichent pas les bons auteurs. Gitea associe les issues aux comptes locaux par nom d'utilisateur. Si le nom GitLab diffère du nom Gitea, les issues sont attribuées à l'utilisateur qui a lancé l'import. Créez d'abord tous les comptes avec les mêmes usernames que sur GitLab avant de lancer la migration des issues.

La restriction GitLab.com du 15 août 2026 a accéléré une tendance déjà engagée : les équipes qui avaient accepté la dépendance à une plateforme SaaS gratuite se retrouvent face à un choix tarifaire non anticipé. Gitea v1.27.3 répond à l'essentiel des besoins d'une forge Git d'équipe — repositories, pull requests, CI/CD, registre de paquets, SSO — dans une empreinte qui tient sur un VPS entrée de gamme.

La migration n'est pas instantanée, mais elle est séquentielle et réversible à chaque étape : l'historique Git est intégral dès le push --mirror, les issues et pull requests suivent via l'import natif, et la CI/CD se reconfigure en quelques heures si vos workflows étaient déjà en YAML. Le template VPS Gitea de ServOrbit vous évite la phase d'installation et de configuration initiale — Gitea est prêt, Docker est en place, il reste à coller votre domaine et à dérouler les étapes décrites ici.

Retrouvez les guides complémentaires sur la stack IA self-hosted avec Gitea et Ollama, le remplacement de GitHub Actions par Woodpecker CI, et l'installation de GitLab CE sur VPS si vous évaluez encore les deux options.