Quel serveur Git auto-hébergé choisir ?

Quel serveur Git auto-hébergé utiliser

Un serveur Git auto-hébergé n’est pas un produit unique. La RAM (mémoire vive) de votre VPS détermine la version que vous pouvez installer. Git n’a pas besoin de son propre daemon : un dépôt bare et un compte SSH (secure shell) constituent déjà un serveur fonctionnel sur le plus petit serveur que vous pouvez louer. Tout ce qui dépasse ce niveau est une application web que vous choisissez d’exécuter à côté. Chaque niveau supplémentaire consomme de la mémoire qu’un petit VPS ne possède peut-être pas.

Il existe quatre niveaux. Un dépôt bare accessible via SSH, sans aucun service supplémentaire en écoute. cgit, une interface web rapide en lecture seule, sans base de données. Forgejo ou Gitea, une forge complète avec des comptes, des issues et des pull requests, en quelques centaines de mégaoctets. GitLab, qui nécessite un serveur plusieurs fois plus puissant que les autres.

Décidez en fonction des tâches à effectuer, puis comparez la quantité de mémoire nécessaire avec celle incluse dans l’offre que vous payez.

Les besoins réels en RAM de chaque option

Seuls deux de ces projets publient une configuration matérielle. Considérez cette valeur comme un minimum, pas comme une garantie. Mesurez votre propre instance une fois qu’elle fonctionne, avec systemd-cgtop ou ps -o rss= -C forgejo.

[
  {
    "label": "Gitea, small team",
    "ram_gb": 1
  },
  {
    "label": "GitLab, memory constrained",
    "ram_gb": 8
  },
  {
    "label": "GitLab, single node baseline",
    "ram_gb": 16
  }
]

Gitea indique que 1 Go de RAM avec 2 cœurs CPU suffisent généralement pour les petites équipes et les petits projets. Le projet indique aussi qu’un Raspberry Pi 3 convient aux petites charges. GitLab indique 16 Go comme base pour une installation sur un seul nœud, et 8 Go comme valeur basse pour ce que sa propre documentation appelle un environnement limité en mémoire. Forgejo ne publie aucune configuration matérielle. C’est un fork de Gitea et son comportement est similaire. La valeur indiquée pour Gitea constitue donc le meilleur repère publié dont vous disposez.

Sur un VPS de 1 Go, les dépôts bare et cgit tiennent avec de la marge, car aucun des deux n’exécute de service résident. Forgejo ou Gitea démarreront et pourront servir une petite équipe avec SQLite. Vous êtes toutefois au minimum documenté. Laissez donc PostgreSQL et le runner CI (intégration continue) désactivés sur cette machine. Si l’interface web disparaît sans afficher d’erreur, exécutez sudo dmesg -T | grep -i oom et recherchez une ligne comme Out of memory: Killed process 1181 (forgejo). Cela signifie que l’out-of-memory killer du kernel a arrêté le processus. GitLab sur une machine de 1 Go n’est pas un problème de tuning. Il ne fonctionnera pas.

Niveau 0 : un dépôt bare via SSH

Git ne possède aucun daemon réseau que vous devez démarrer. git push via SSH exécute git-receive-pack sur l’hôte distant comme un processus Unix ordinaire. Tout compte auquel vous pouvez accéder avec une clé est donc déjà un remote Git. Créez un compte pour les dépôts et stockez les dépôts en dehors de son répertoire personnel. Sous Ubuntu 24.04, un nouveau répertoire personnel est créé avec le mode 0750, et une interface web ajoutée ultérieurement ne pourrait pas y accéder en lecture.

sudo adduser --system --shell /bin/bash --gecos 'Git Version Control' \
  --group --disabled-password --home /home/git git
sudo install -d -m 0755 -o git -g git /srv/git
sudo -u git git init --bare /srv/git/project.git

--bare crée un dépôt sans working copy, ce qui correspond à ce qu’un serveur conserve. Un push vers un dépôt qui possède une working copy est refusé avec refusing to update checked out branch: refs/heads/main. C’est l’erreur la plus fréquente à ce niveau.

Donnez maintenant une clé au compte et clonez le dépôt.

sudo -u git install -d -m 700 /home/git/.ssh
sudo -u git tee -a /home/git/.ssh/authorized_keys <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexamplekeyhere alice@laptop
EOF
sudo -u git chmod 600 /home/git/.ssh/authorized_keys

git remote add origin git@vps.example.com:/srv/git/project.git
git push -u origin main

Un premier push réussi se termine par * [new branch] main -> main. Un push qui se termine par git@vps.example.com: Permission denied (publickey) n’a jamais été authentifié. Consultez donc le journal du serveur avec sudo journalctl -u ssh -n 20. Une ligne contenant Authentication refused: bad ownership or modes for file /home/git/.ssh/authorized_keys signifie que le mode du fichier est incorrect, car sshd ignore un fichier de clés accessible en écriture aux autres utilisateurs.

Retirez ensuite le shell du compte.

command -v git-shell | sudo tee -a /etc/shells
sudo chsh -s "$(command -v git-shell)" git

git-shell n’accepte que les quelques commandes que Git envoie via SSH. Une connexion interactive s’arrête donc avec un message au lieu d’afficher une invite :

fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.

C’est tout ce qu’il faut pour le serveur. Il n’y a ni base de données ni processus web à mettre à niveau. En contrepartie, vous renoncez à toutes les fonctions d’une forge : pas de navigation dans les dépôts, pas de suivi des tickets, pas de pull requests et pas de permissions par utilisateur. Chaque clé de ce fichier peut lire et modifier tous les dépôts appartenant à l’utilisateur git.

Niveau 1 : cgit fournit une interface web sans base de données

cgit est un programme CGI (common gateway interface) écrit en C. Le serveur web l’exécute une fois par requête, il lit directement les dépôts sur le disque et ne conserve aucun état propre. Ubuntu 24.04 le fournit dans le composant universe.

sudo apt update
sudo apt install -y cgit fcgiwrap nginx
sudo install -d -o www-data -g www-data /var/cache/cgit

Indiquez-lui le répertoire des dépôts dans /etc/cgitrc :

root-title=Git on example.com
css=/cgit.css
logo=/cgit.png
cache-size=1000
cache-root=/var/cache/cgit
snapshots=tar.gz zip
scan-path=/srv/git

scan-path parcourt ce répertoire et répertorie tous les dépôts trouvés. Un nouveau dépôt bare apparaît donc sans configuration supplémentaire. cache-size correspond au nombre de pages mises en cache. La mise en cache reste désactivée tant que cette valeur est égale à zéro. Consultez le contenu que votre paquet a déjà placé dans /etc/cgitrc avant d’ajouter des lignes, car le paquet Debian ou Ubuntu fournit ses propres valeurs par défaut.

Chaque entrée affiche la première ligne du fichier description du dépôt. Un nouveau dépôt bare apparaît donc sous le nom Unnamed repository; edit this file 'description' to name the repository.. Corrigez cela une fois par dépôt :

echo 'Project X, internal tooling' | sudo -u git tee /srv/git/project.git/description

server {
    listen 80;
    server_name git.example.com;
    root /usr/share/cgit;

    try_files $uri @cgit;

    location @cgit {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME /usr/lib/cgit/cgit.cgi;
        fastcgi_param PATH_INFO $uri;
        fastcgi_param QUERY_STRING $args;
        fastcgi_param HTTP_HOST $server_name;
        fastcgi_pass unix:/run/fcgiwrap.socket;
    }
}

sudo systemctl enable --now fcgiwrap.socket
sudo nginx -t && sudo systemctl reload nginx
systemctl show fcgiwrap.socket -p Listen

Deux limites sont importantes avant de vous appuyer sur cette solution. cgit est en lecture seule et ne propose aucune authentification. Tout ce qui se trouve sous scan-path est donc public. Gardez un dépôt privé en dehors de ce répertoire ou placez une authentification HTTP basic devant l’ensemble du site. Le CGI s’exécute également avec l’utilisateur du serveur web. Cet utilisateur doit donc pouvoir traverser /srv/git et lire chaque dépôt. Un répertoire auquel il ne peut pas accéder apparaît comme un index vide plutôt que comme une erreur.

Niveau 2 : Forgejo ou Gitea pour les issues et les pull requests

Forgejo et Gitea reposent sur le même principe : un binaire Go qui fournit une forge web avec des utilisateurs, des organisations, des issues, des pull requests, des releases, un registre de paquets et un système de CI intégré. Le binaire et SQLite constituent toute l’installation, ce qui permet de les faire fonctionner sur du matériel trop limité pour GitLab. Le fichier Compose ci-dessous est celui de la documentation de Forgejo, avec le tag d’image indiqué en août 2026.

networks:
  forgejo:
    external: false

services:
  server:
    image: codeberg.org/forgejo/forgejo:16
    container_name: forgejo
    environment:
      - USER_UID=1000
      - USER_GID=1000
    restart: always
    networks:
      - forgejo
    volumes:
      - ./forgejo:/data
      - /etc/localtime:/etc/localtime:ro
    ports:
      - '3000:3000'
      - '222:22'

docker compose up -d
docker compose ps
curl -sI http://127.0.0.1:3000 | head -1

La ligne curl doit afficher une ligne de statut HTTP. Avant de terminer la configuration initiale, il peut s’agir d’une redirection vers /install, ce qui signifie tout de même que le service fonctionne. Si le conteneur s’arrête à la place, la cause habituelle est un problème de propriétaire : le répertoire ./forgejo doit appartenir à l’UID (identifiant utilisateur) indiqué dans USER_UID, sinon le processus ne peut pas écrire dans son propre répertoire de données. Docker Compose sur un VPS explique en détail cette organisation des fichiers et la règle de propriété des volumes.

Deux réponses sur la page de configuration déterminent si les URL de clone fonctionnent. Le port SSH doit être 222, car le fichier Compose mappe le port 222 de l’hôte vers le port 22 du conteneur, et le domaine doit être celui que les utilisateurs saisiront réellement. Une seule erreur suffit pour que chaque page de dépôt propose une commande de clone qui échoue pour toutes les personnes qui la copient. Ces deux paramètres se trouvent ensuite dans la section [server] de app.ini, sous la forme de SSH_PORT, SSH_DOMAIN et ROOT_URL.

Pour une instance publique, publiez le port web uniquement sur l’adresse loopback ('127.0.0.1:3000:3000'), puis placez nginx devant pour gérer TLS (sécurité de la couche transport). Gitea s’installe de la même manière depuis l’image gitea/gitea, ou sous la forme d’un binaire unique avec une unité systemd et un seul app.ini. Sa version stable actuelle est 1.27.1 en août 2026.

Restez sur SQLite tant que possible. L’instance se limite ainsi à un processus et un fichier, et elle redémarre sans nécessiter de service supplémentaire à superviser. PostgreSQL justifie sa complexité lorsque plusieurs personnes écrivent simultanément, car SQLite sérialise les écritures et les longues exécutions de CI écrivent en permanence. Les deux projets permettent ensuite de migrer une instance existante vers PostgreSQL. Vous n’êtes donc pas définitivement lié à ce choix.

Forgejo ou Gitea : quelles sont les différences concrètes

Leur origine est commune. Gitea a été forké de Gogs en 2016. Fin 2022, le contrôle du domaine et de la marque Gitea a été transféré à une société, Gitea Ltd, et plusieurs mainteneurs ont lancé Forgejo avec Codeberg. Forgejo est publié par Codeberg e.V., une association à but non lucratif enregistrée en Allemagne. En 2024, le projet est passé de la licence MIT à la GPLv3 (GNU general public license version 3). Gitea reste sous licence MIT et son développement bénéficie d’un soutien commercial.

Au quotidien, les fonctionnalités sont proches. En revanche, la migration entre les deux projets ne l’est pas. Forgejo v10.0, publié en janvier 2025, est la dernière release capable d’utiliser directement une base de données Gitea, et uniquement depuis Gitea v1.22 ou une version antérieure. Gitea est en version 1.27.1 en août 2026. Une instance Gitea actuelle ne dispose donc d’aucune procédure prise en charge pour passer à Forgejo sur place. Choisissez l’un des deux projets avant d’y importer des données. Considérez toute migration ultérieure comme un export suivi d’une réimportation.

Voici une règle simple pour choisir. Si la gouvernance est importante pour vous ou si vous souhaitez que le projet reste porté par une association à but non lucratif, utilisez Forgejo. Si vous voulez la base d’installations la plus large et une possibilité de support commercial, utilisez Gitea. Les deux projets sont développés ouvertement et publient régulièrement des releases : Forgejo publie une release stable tous les trois mois et une release LTS (long term support) chaque année. En août 2026, la version actuelle est v16.0.2 et la version LTS est v15.0.6.

Niveau 3 : ce que GitLab consomme avant de faire quoi que ce soit

GitLab CE appartient à une autre catégorie de logiciels. Une instance regroupe plusieurs services qui coopèrent : Puma pour l’application web, Sidekiq pour les tâches en arrière-plan, PostgreSQL, Redis, Gitaly pour l’accès aux dépôts et nginx en frontal. Le paquet Omnibus les installe ensemble, ce qui simplifie l’installation, mais augmente fortement la mémoire minimale nécessaire.

La page des prérequis de GitLab indique 16 GB de RAM et 8 vCPU comme référence pour l’installation sur un nœud unique. Elle mentionne aussi 8 GB comme limite basse dans un environnement où la mémoire est limitée. Cette même page recommande de désactiver le swap, car son utilisation sous charge dégrade fortement l’instance. Il s’agit des valeurs publiées en août 2026. Elles ont augmenté au fil des années. Consultez donc à nouveau cette page avant de dimensionner un serveur.

Ce budget vous apporte des fonctionnalités concrètes : un container registry, un package registry, des permissions détaillées, des fonctions de conformité et d’audit, ainsi qu’une CI testée à grande échelle. Si personne dans votre équipe ne peut citer une fonctionnalité de cette liste dont elle a besoin ce trimestre, vous payez simplement un VPS plus puissant sans rien obtenir en échange.

Le modèle d’accès SSH : un utilisateur git et plusieurs clés

Chaque niveau s’authentifie de la même manière. Il existe un compte Unix nommé git, et chaque clé publique est ajoutée au fichier ~/.ssh/authorized_keys de ce compte. La clé assure l’authentification. L’autorisation dépend des options placées devant la clé sur la même ligne.

Une ligne contenant uniquement une clé donne à son détenteur tous les droits de ce compte. Une commande forcée limite ces droits à Git :

restrict,command="git-shell -c \"$SSH_ORIGINAL_COMMAND\"" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexamplekeyhere alice@laptop

restrict, disponible depuis OpenSSH 7.2, désactive en un seul mot la redirection de ports, la redirection de l’agent, X11 et l’allocation d’un PTY (pseudo-terminal). command= remplace la commande demandée par le client par celle que vous indiquez, et Git continue de fonctionner parce qu’il envoie sa requête dans $SSH_ORIGINAL_COMMAND.

Une forge génère ce fichier pour vous. C’est la véritable différence entre le niveau 0 et le niveau 2. Forgejo et Gitea réécrivent authorized_keys avec une ligne par clé enregistrée. Chaque ligne contient une commande forcée qui identifie la clé par son identifiant en base de données :

command="/usr/local/bin/forgejo --config=/etc/forgejo/app.ini serv key-3",no-port-forwarding,no-x11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexamplekeyhere alice

Cette commande forcée permet de transformer un compte Unix partagé en autorisations par utilisateur : key-3 indique à la forge quel utilisateur se connecte, puis la forge vérifie les droits de cet utilisateur sur le dépôt avant tout transfert d’objet. Ne modifiez pas manuellement ce fichier sur un serveur géré par une forge. Il est régénéré depuis la base de données et votre ligne disparaîtrait. Les deploy keys utilisent le même mécanisme : une deploy key est une clé SSH ordinaire enregistrée pour un seul dépôt, généralement en lecture seule. La vérification est effectuée par la forge, et non par sshd.

Deux pratiques comptent davantage que toutes les configurations précédentes. Utilisez une clé par personne ou par machine, jamais une clé partagée. Révoquer une clé partagée obligerait à la remplacer pour tout le monde en même temps. Supprimez également les clés le jour du départ d’une personne. Une ancienne clé présente dans ce fichier constitue un accès permanent que personne ne surveille. Bien gérer les clés SSH sur un serveur présente les types de clés et les phrases secrètes. Tout cela s’applique ici sans modification. Si le serveur est neuf, les dix premières minutes sur un nouveau VPS est la bonne procédure à suivre avant d’y placer des dépôts.

Puis-je exécuter GitHub Actions sur mon propre serveur Git ?

Vous pouvez exécuter des workflows écrits avec la syntaxe de GitHub Actions. Vous ne pouvez pas exécuter GitHub. Forgejo Actions est activé par défaut depuis Forgejo v1.21 et lit les fichiers de workflow dans .forgejo/workflows de chaque dépôt. Gitea Actions fonctionne de la même manière et lit .gitea/workflows. Les deux nécessitent un second programme, le runner, installé et enregistré auprès de votre instance avec un token obtenu dans les paramètres d’administration. De nombreuses actions publiées s’exécutent sans modification. En revanche, celles qui appellent l’API GitHub ou attendent une infrastructure hébergée par GitHub ne fonctionnent pas.

Prévoyez deux conséquences. Le runner démarre un conteneur pour chaque job. Il a donc besoin d’un container engine et de ressources mémoire qui lui sont propres. C’est pourquoi il ne doit pas être installé sur le même serveur de 1 GB que la forge. Le runner exécute aussi tout ce qu’indique un fichier de workflow. La documentation de Forgejo le dit clairement : le runner permet l’exécution de code à distance. Si possible, installez-le sur son propre hôte. Sinon, utilisez au minimum son propre utilisateur sans privilèges et un token d’enregistrement limité à un seul dépôt.

Si vos dépôts restent sur GitHub et que vous voulez seulement exécuter les jobs sur du matériel que vous contrôlez, il s’agit d’une configuration différente, avec d’autres étapes : un runner GitHub Actions auto-hébergé s’attache à un dépôt GitHub et ne nécessite rien de tout cela. Si vous évaluez encore le coût d’un départ, ce que GitHub vous apporte réellement distingue l’hébergement Git du réseau qui l’entoure.

Sauvegardes : les dépôts ne représentent que la moitié de l’état

Un dépôt bare est un répertoire. Le copier permet donc de tout copier. Un clone mirror depuis une autre machine constitue une véritable sauvegarde et se met à jour sur place :

git clone --mirror git@vps.example.com:/srv/git/project.git
cd project.git && git remote update

Cette commande récupère toutes les références et tous les objets. Elle ne récupère pas les hooks côté serveur ni le fichier description. Si vous utilisez des hooks, conservez donc aussi une copie au niveau des fichiers du répertoire.

Un forge conserve les issues, les pull requests, les utilisateurs, les clés et les permissions dans sa base de données. Une simple copie des dépôts supprime toutes ces données. Les deux projets fournissent une commande dump qui écrit la base de données, les dépôts, la configuration et les pièces jointes dans une seule archive :

sudo -u git forgejo dump -c /etc/forgejo/app.ini -f /var/backups/forgejo-dump.zip

Avec Docker, la même commande s’exécute dans le conteneur. Le chemin de configuration dépend de l’image. Vérifiez-le avant de saisir la commande :

docker compose exec server ls /data/gitea/conf
docker compose exec -u git server forgejo dump -c /data/gitea/conf/app.ini

Exécutez la commande avec l’utilisateur propriétaire des données et écrivez l’archive dans un répertoire où cet utilisateur peut écrire. Copiez ensuite l’archive hors du serveur. Une sauvegarde qui existe uniquement sur la machine sauvegardée n’est pas une sauvegarde. La restauration est l’étape souvent oubliée : décompressez dès maintenant un dump sur une machine de secours. Vous apprendrez ainsi la procédure à un moment calme, plutôt que pendant une panne.

Choisir selon le scénario

Une personne avec un ordinateur portable et un VPS, sans besoin de navigation web : des dépôts bare via SSH. Aucun service supplémentaire ne s’exécute et rien n’est à mettre à niveau.

Même situation, avec le besoin de consulter le code dans un navigateur et de partager des liens vers celui-ci : ajoutez cgit. Toujours pas de base de données et aucun processus résident supplémentaire.

Une équipe qui relit le code des autres et suit les tickets : Forgejo ou Gitea, avec 2 GB de RAM ou plus. Déplacez le runner CI sur une deuxième machine lorsque les jobs deviennent réellement lourds.

Une organisation qui a besoin d’un registre de conteneurs et de pistes d’audit, avec 16 GB à consacrer au serveur : GitLab. En dessous de ce budget, ne le déployez pas.

Passer aux trois premiers niveaux coûte peu, car les dépôts sont dans chaque cas de simples répertoires Git sur disque. Commencez par le niveau le plus bas qui répond au besoin. Si vous déterminez quels autres services peuvent partager le même serveur, la liste restreinte des services qui méritent un auto-hébergement place un serveur Git parmi les autres services qui se disputent cette RAM.

FAQ

Un VPS de 1 GB peut-il faire fonctionner Forgejo ou Gitea ?

Oui, pour une petite équipe, avec SQLite et sans autre service lourd sur la machine. La documentation de Gitea indique que 1 GB de RAM et 2 cœurs CPU suffisent généralement pour les petites équipes et les petits projets. Forgejo est un fork de Gitea avec des besoins comparables. N’ajoutez pas PostgreSQL ni un runner CI sur cette machine. Si le service disparaît sans erreur dans son propre journal, exécutez sudo dmesg -T | grep -i oom : une ligne indiquant le processus tué signifie que l’out-of-memory killer du kernel l’a arrêté. La solution consiste alors à choisir une offre plus puissante plutôt qu’à modifier un flag de configuration.

Quelle est la différence entre Forgejo et Gitea ?

Ils partagent un historique de code et la plupart de leurs fonctionnalités. Gitea a forké Gogs en 2016, puis Forgejo a forké Gitea fin 2022, après le transfert du contrôle de la marque Gitea à une entreprise. Forgejo est publié par Codeberg e.V., une organisation à but non lucratif en Allemagne, sous GPLv3. Gitea reste sous licence MIT et bénéficie d’un soutien commercial. La différence pratique concerne la procédure de migration. Forgejo v10.0, publié en janvier 2025, était la dernière release capable d’utiliser directement une base de données Gitea, et uniquement depuis Gitea v1.22 ou une version antérieure. Une instance Gitea actuelle ne peut donc pas être basculée sur place avec une procédure prise en charge.

Puis-je exécuter des workflows GitHub Actions sur un serveur Git auto-hébergé ?

Forgejo Actions et Gitea Actions exécutent tous deux des workflows écrits dans la syntaxe YAML de GitHub Actions, lus depuis .forgejo/workflows et .gitea/workflows. Vous installez un programme runner distinct et vous l’enregistrez auprès de votre instance. De nombreuses actions publiées fonctionnent sans modification, mais celles qui appellent l’API GitHub ne fonctionnent pas. Le runner exécute du code arbitraire provenant de vos dépôts et démarre un conteneur pour chaque job. Donnez-lui donc son propre hôte ou, au minimum, son propre utilisateur non privilégié. Ne l’exécutez pas sur un serveur de 1 GB qui fait déjà fonctionner le forge.

Comment sauvegarder un serveur Git auto-hébergé ?

Pour les dépôts bare, git clone --mirror depuis une autre machine copie chaque ref et chaque objet, tandis que git remote update dans ce mirror le met à jour. Pour Forgejo ou Gitea, les dépôts ne représentent qu’une partie de l’état du service, car les issues, les pull requests, les utilisateurs et les clés sont stockés dans la base de données. Utilisez le dump intégré, sudo -u git forgejo dump -c /etc/forgejo/app.ini, ou la même commande à l’intérieur du conteneur dans le cas d’une installation Docker. Copiez l’archive hors du serveur et restaurez-la une fois sur une machine de secours pour vérifier que la procédure fonctionne.