Auto-héberger sa forge Git : un guide pratique pour la souveraineté des données

Chez Dumontix, nous travaillons exclusivement avec des fournisseurs cloud européens. Ce n’est pas un argument marketing ni une posture philosophique adoptée parce qu’elle sonnait bien ; c’est une exigence pratique pour nombre de nos clients. Lorsqu’on manipule des données d’entreprises européennes, particulièrement celles dans des secteurs réglementés, « utilise simplement GitHub » n’est pas toujours une option. Parfois, votre code, vos tickets, vos pipelines CI/CD et vos secrets de déploiement doivent rester dans des limites juridictionnelles que vous pouvez réellement vérifier.

Nous avons passé des années à développer notre expertise autour de Scaleway, Hetzner, OVH et d’autres fournisseurs d’infrastructure européens. Nous connaissons leurs particularités, leurs modèles tarifaires, leurs délais de réponse du support. Nous savons lesquels offrent les meilleures performances de stockage bloc et lesquels éviter pour les charges de travail sensibles à la latence. Cette spécialisation signifie que nous devons parfois résoudre des problèmes qui seraient triviaux si nous pouvions simplement orienter nos clients vers une solution SaaS américaine.

L’hébergement Git est l’un de ces problèmes.

Le tutoriel devenu projet

Tout a commencé comme un article de blog. J’allais écrire un tutoriel sympathique : « Comment déployer Forgejo sur Scaleway en 30 minutes ». J’avais les configurations Terraform, quelques tâches Ansible, des notes sur Let’s Encrypt et les reverse proxies. Ça allait être simple.

Puis j’ai commencé à écrire, et les cas particuliers se sont accumulés. Qu’en est-il des sauvegardes ? Des mises à jour ? Comment gérer la base de données : conteneurisée ou sur l’hôte ? Que se passe-t-il quand quelqu’un veut utiliser Hetzner au lieu de Scaleway (c’est notre fournisseur, donc j’avais initialement écrit pour leur cas) ? Provisionne-t-on le stockage séparément ou utilise-t-on le disque de démarrage ? Comment gérer les secrets sans les commiter dans le dépôt qu’on essaie d’auto-héberger ?

Le temps d’avoir traité toutes ces questions, je n’écrivais plus un tutoriel. Je construisais de l’infrastructure as code que je voudrais vraiment utiliser en production. J’ai donc arrêté de prétendre que c’était un article de blog et j’en ai fait un vrai projet.

Le résultat est forgejo-autohebergement, une boîte à outils complète pour déployer Forgejo sur des fournisseurs cloud européens. Elle gère le provisionnement d’infrastructure avec Terraform, la configuration serveur avec Ansible, les sauvegardes automatisées, les certificats HTTPS, les règles de pare-feu, et même l’accès SSH via VPN. Vous pouvez avoir une forge Git prête pour la production en moins d’une heure, et surtout, vous pouvez comprendre et modifier chaque élément.

On mange nos propres cookies aux saveurs d’ops

L’instance Forgejo sur git.dumontix.eu tourne sur exactement ce template. Nous avons fait quelques ajustements selon nos préférences : des périodes de rétention de logs différentes, quelques hooks de monitoring supplémentaires, un calendrier de sauvegarde légèrement plus agressif ; mais le cœur est identique à ce que vous trouverez dans le dépôt public.

Ce n’est pas du dogfooding pour la crédibilité, c’est plutôt partager notre repas. Quand on trouve un bug ou qu’on a besoin d’une nouvelle fonctionnalité, on le corrige dans la même base de code qu’utilisent nos clients. Quand Forgejo sort une nouvelle version, on met à jour notre instance d’abord puis on pousse les changements testés. Le template s’améliore parce qu’on en dépend.

Notre déploiement utilise des instances DEV1-S de Scaleway à Paris, avec du stockage bloc pour le volume de données. PostgreSQL tourne directement sur l’hôte plutôt que dans un conteneur ; nous préférons la simplicité opérationnelle et la possibilité d’utiliser les outils Debian standards pour la maintenance de la base de données. Caddy gère la terminaison TLS et le reverse proxy, ce qui élimine toute une catégorie de maux de tête liés au renouvellement des certificats qui affligeaient nos anciennes configurations nginx.

La question Tailscale

Un composant de notre stack n’est pas européen : Tailscale. Nous l’utilisons pour sécuriser l’accès SSH à nos serveurs, créant un réseau zero-trust où le port d’administration n’est jamais exposé à l’internet public.

C’était un choix délibéré, et je veux être transparent sur le raisonnement. Je connais les fondateurs pour avoir passé du temps dans la communauté Go. Je les ai vus construire l’entreprise et je fais confiance à leur approche de la sécurité et de la vie privée. Quand on choisit des composants d’infrastructure, les humains derrière le projet comptent autant que les spécifications techniques.

Cela dit, je reconnais que cela crée une dépendance envers un service américain. Pour les clients avec des exigences strictes de résidence des données, nous discutons des alternatives. Headscale, le serveur de contrôle Tailscale open source, est une option. Netbird en est une autre. WireGuard directement, avec votre propre distribution de clés, fonctionne bien si vous êtes à l’aise pour le gérer. Les rôles Ansible dans notre template sont conçus pour être interchangeables : Tailscale est le choix par défaut parce qu’il offre la meilleure expérience développeur, mais les règles de pare-feu et la configuration SSH ne présupposent aucune solution VPN particulière.

À terme, nous adopterons probablement une alternative entièrement européenne par défaut. L’écosystème mûrit, et des projets comme Netbird atteignent un niveau de qualité production. Pour l’instant, nous avons fait un choix pragmatique que nous sommes à l’aise d’expliquer à nos clients (et puis, il faut choisir ses batailles ; on peut toutes les mener, mais une à la fois).

Pourquoi Forgejo ?

J’ai choisi Forgejo plutôt que Gitea, GitLab ou d’autres alternatives pour plusieurs raisons. C’est suffisamment léger pour tourner sur une infrastructure minimale : notre instance de production utilise un serveur à 2 vCPU et 2 Go de RAM et remarque à peine la charge. Il est activement développé par une fondation à but non lucratif avec un modèle de gouvernance clair, ce qui compte quand on mise son code source sur un projet. Et il a la parité fonctionnelle avec ce dont la plupart des équipes ont réellement besoin : pull requests, tickets, intégration CI via webhooks, registres de conteneurs, et une bonne couverture API (et puis il me plaît).

GitLab est excellent mais nécessite significativement plus de ressources et de complexité opérationnelle. Pour les équipes qui n’ont pas besoin de ses fonctionnalités CI/CD avancées ou de ses intégrations entreprise, c’est excessif. Gitea aurait convenu techniquement, mais la situation de gouvernance nous mettait mal à l’aise. Forgejo a émergé de la communauté Gitea précisément pour répondre à ces préoccupations, et le projet s’est avéré stable et fiable.

Comment ça marche

Le processus de déploiement a deux phases. D’abord, Terraform provisionne l’infrastructure cloud : une instance de calcul, un volume de stockage bloc, des enregistrements DNS si vous les gérez via le fournisseur, et les règles de pare-feu nécessaires au niveau cloud. Ensuite, Ansible configure le serveur : installe les dépendances, configure PostgreSQL, déploie Forgejo en tant que conteneur Docker, configure Caddy pour HTTPS, établit les routines de sauvegarde, et durcit le système.

Un assistant de configuration vous guide à travers la configuration initiale :

./setup-wizard.sh

Il vous demande les identifiants de votre fournisseur cloud, votre nom de domaine, et génère les secrets nécessaires. Vous pouvez aussi tout configurer manuellement si vous préférez ; l’assistant crée simplement les mêmes fichiers YAML que vous écririez à la main.

Le Makefile fournit des raccourcis pour les opérations courantes :

make help              # Afficher toutes les commandes disponibles
make install           # Déploiement complet depuis zéro
make deploy            # Mettre à jour la configuration
make backup            # Créer une sauvegarde
make backup-cron       # Sauvegarde non interactive pour les tâches cron
make ssh               # Se connecter au serveur

Les sauvegardes incluent la base de données PostgreSQL, tous les dépôts Git, les objets LFS, et la configuration de Forgejo. Elles peuvent rester localement sur le stockage bloc du serveur ou se synchroniser vers un stockage objet compatible S3. La restauration est une seule commande qui arrête le service, remplace les données, et redémarre le tout.

Contribuer sans inscription

Puisque git.dumontix.eu n’autorise pas l’inscription publique, nous avons mis en place un workflow pour les contributions externes. Il y a un miroir synchronisé sur Codeberg à codeberg.org/dumontix/forgejo-autohebergement. Les contributeurs forkent le miroir, font leurs modifications et créent une Pull Request. Nous examinons les changements et les fusionnons avec l’attribution appropriée.

Ce n’est pas aussi fluide qu’une pull request sur une plateforme avec inscription ouverte, mais ça fonctionne. Les fonctionnalités de fédération de Forgejo permettront à terme des pull requests inter-instances via le protocole ForgeFed ; la spécification est en cours de développement et des implémentations précoces apparaissent. En attendant que ce soit prêt pour la production, le workflow fork-et-lien est un compromis raisonnable.

Pour commencer

Si vous voulez faire tourner votre propre instance, clonez le dépôt et lancez l’assistant :

git clone https://codeberg.org/dumontix/forgejo-autohebergement.git
cd forgejo-autohebergement
./setup-wizard.sh

Vous aurez besoin de comptes chez le fournisseur cloud de votre choix et d’un nom de domaine pointant vers l’emplacement du serveur. L’assistant s’occupe du reste, y compris la génération de mots de passe sécurisés et de clés de chiffrement.

La documentation couvre les détails spécifiques à chaque fournisseur, les options de personnalisation et les procédures opérationnelles. Si vous rencontrez des problèmes, ouvrez un ticket. Si vous apportez des améliorations, nous serions ravis de les voir.

L’auto-hébergement n’est pas pour tout le monde. Cela demande une maintenance continue, une conscience de la sécurité, et une volonté de débuguer des problèmes à 2 heures du matin quand quelque chose casse. Mais pour les organisations qui ont besoin de contrôler leur infrastructure de code source, que ce soit pour la conformité réglementaire, la souveraineté des données, ou simplement par préférence philosophique, c’est tout à fait réalisable. Les outils ont suffisamment mûri pour qu’on n’ait plus besoin d’une équipe plateforme dédiée pour faire tourner une forge Git fiable.

Nous faisons tourner la nôtre depuis un moment maintenant. Ça marche.

–

Si cela fait écho aux défis que votre entreprise affronte au quotidien, parlons-en et voyons comment nous pouvons vous aider