Votre propre serveur Git.
Le dépôt, c'est l'organigramme.

Presque tous les débats sur l'auto-hébergement de Git portent sur le code source, alors que le code source est la partie qui compte le moins. La plupart du temps, il n'a rien de remarquable, une grande partie n'est qu'une fine couche par-dessus des bibliothèques open source, et s'il fuitait demain, le dommage pratique relèverait le plus souvent de la gêne plutôt que du préjudice. C'est pourquoi « mon code n'est pas secret » a l'air d'une réponse complète — et pourquoi ça n'en est pas une.

Ce qui entoure le code est la partie intéressante. Un dépôt est un enregistrement de travail daté, attribué et en haute résolution : les horodatages de commits décrivent quand vous dormez, les lignes de co-auteur décrivent avec qui vous travaillez, les noms de branches décrivent des produits que personne n'a annoncés, un gestionnaire de tickets décrit ce qui est cassé et à quel point, et un premier commit date le projet tout entier. Lisez cent dépôts de cette façon et vous ne lisez plus du logiciel — vous lisez une entreprise, sa feuille de route, ses effectifs et ses ennuis.

Sur une plateforme, cet enregistrement ne vous appartient pas au sens propre. Il repose sur une infrastructure que vous ne contrôlez pas, sous un compte lié à une identité que vous avez vérifiée, dans une juridiction dont la procédure judiciaire peut l'atteindre, scruté par des systèmes dont la portée est fixée par un document qui peut être modifié. Rien de tout cela n'exige de mauvaise foi de la part de qui que ce soit : c'est simplement ce que signifie louer le gestionnaire de tickets. Quatre configurations, et ce que chacune révèle réellement :

La troisième ligne est celle qui piège les équipes qui pensent avoir déjà réglé la question. Une forge que vous avez installée vous-même, sur une machine louée avec une carte d'entreprise sous un compte de société vérifié, a fait sortir l'application de la plateforme mais a laissé l'identité exactement où elle était. C'est un vrai gain en contrôle et aucun gain en exposition.

Et la quatrième ligne énonce clairement son propre coût, car le reste de ce guide consiste surtout à le payer. Le mode de défaillance de l'auto-hébergement n'est pas la surveillance, c'est la perte. Une plateforme conserve des sauvegardes auxquelles vous ne pensez jamais. Votre serveur conserve les sauvegardes que vous avez configurées. L'étape 06 n'est pas la finition optionnelle de la fin — c'est l'étape qui rend les cinq autres sûres.

Commandez d'abord la machine. Dans le panel : Order → VPS → Sentinel, image Debian 12, dans le bastion où vous voulez que l'historique vive — Helsinki, Stockholm, Oslo ou Reykjavík. Aucune adresse e-mail n'est requise pour ouvrir le compte, et la facture se règle en Monero, Bitcoin, Lightning ou tout autre actif pris en charge. Cela compte plus ici que pour la plupart des charges de travail : une forge est le seul service dont toute la proposition de valeur repose sur le fait que l'enregistrement de votre travail n'est attaché à aucun nom.

Passez ensuite la check-list de durcissement de la première heure — SSH par clé uniquement sur un port déplacé, mises à jour automatiques, pare-feu qui refuse par défaut — car tout ce qui suit suppose une machine qui n'est pas déjà celle de quelqu'un d'autre.

Pointez un nom d'hôte vers la machine — un enregistrement A, et un AAAA si vous la voulez joignable en IPv6 — et laissez-le se propager avant de commencer, car le reverse proxy va tenter d'obtenir un certificat pour ce nom dès son premier démarrage, et un challenge échoué est une façon déroutante de commencer. Écrivez ensuite les règles de pare-feu pendant que rien n'écoute encore.

Le problème des deux SSH. Une forge parle SSH pour Git, et votre serveur parle déjà SSH pour l'administration. Ils ne peuvent pas posséder le port 22 tous les deux, et c'est en les mélangeant qu'on finit avec un démon d'administration qui doit aussi comprendre Git. Gardez-les séparés : l'administration sur le port déplacé du guide de durcissement, Git sur un port public dédié qui pointe vers le conteneur. 2222 est le choix conventionnel, et il n'a rien de sacré.

ufw default deny incoming
ufw allow 47222/tcp                  # administrative SSH, moved
ufw allow 80/tcp                     # ACME HTTP-01 challenge
ufw allow 443/tcp                    # the web interface
ufw allow 2222/tcp                   # git over SSH, into the container
ufw enable
ufw status numbered

# Nothing else is open. In particular: PostgreSQL stays on the Docker
# network and is never published to the host, let alone the internet.

Installez Docker depuis le dépôt officiel plutôt que le paquet de la distribution, afin que Compose v2 soit présent et que la version soit à jour. Créez ensuite un répertoire pour la stack et faites-en le seul endroit de la machine qui conserve un état — c'est le répertoire que l'étape 06 sauvegarde.

curl -fsSL https://get.docker.com | sh
docker compose version

install -d -m 0750 /srv/forgejo
cd /srv/forgejo

Collez votre clé publique dans les réglages du profil, puis indiquez à votre client où se trouve la forge. Comme Git est sur un port non standard, une entrée dans votre config SSH vaut bien les trente secondes que ça prend — elle garde le port hors de chaque URL que vous taperez jamais, et rend les remotes portables.

# ~/.ssh/config
Host git.example.com
    Port 2222
    User git
    IdentityFile ~/.ssh/id_ed25519

# Then, in any repository:
git remote set-url origin git@git.example.com:you/project.git
git push -u origin main
ssh -T git@git.example.com        # expect a greeting, not a shell

Cette dernière commande est celle qui vous dit si le mappage de port, le serveur SSH du conteneur et votre clé sont bien d'accord entre eux. Un message d'accueil de Forgejo signifie que toute la chaîne fonctionne. Une demande de mot de passe signifie que vous avez atteint le sshd d'administration de l'hôte à la place, et que le mappage de port est incorrect.

Signez maintenant vos commits. C'est l'étape que la plupart des guides d'auto-hébergement sautent, et sur une forge auto-hébergée elle compte plus que sur une plateforme. Le champ auteur d'un commit est du texte libre — quiconque peut pousser peut y écrire votre nom. Une signature est la preuve qu'une clé précise a fait un commit précis, et elle reste une preuve même après que le serveur sur lequel il a été poussé a été compromis, migré ou jeté. Git peut signer avec la clé SSH que vous possédez déjà, il n'y a donc plus besoin de détour par PGP :

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
git config --global tag.gpgsign true

git commit --allow-empty -m "signed"
git log --show-signature -1

Ajoutez ensuite la même clé publique une seconde fois dans la forge, comme clé de signature plutôt que comme clé d'authentification. Forgejo vérifie la signature côté serveur et affiche le commit comme vérifié ; sans cette seconde entrée, il n'a aucun moyen de relier la signature à votre compte, et chaque commit s'affiche comme non vérifié même s'il est signé correctement.

Les clés de déploiement, pour les machines qui ne font que lire. Un serveur de production, une machine de build ou un miroir n'a pas besoin d'un compte utilisateur sur la forge. Donnez-lui plutôt une clé de déploiement : une paire de clés ajoutée à un seul dépôt, en lecture seule sauf si vous accordez explicitement l'écriture, et qui ne donne accès à rien d'autre sur l'instance. La révoquer, c'est supprimer une seule entrée. C'est l'habitude la plus efficace pour garder une forge auto-hébergée bien rangée, parce que les comptes utilisateurs accumulent les permissions, alors que les clés de déploiement ne le peuvent pas.

Migrer depuis une plateforme est un bon moment pour bien faire tout cela dès le départ. Le circuit New Migration de Forgejo prend une URL de dépôt et un jeton d'accès, et rapatrie branches, tags, tickets, commentaires, labels, jalons, releases et pull requests. Migrez un premier dépôt pour voir la forme du résultat, attendez-vous à ce que les limites de débit de l'API ralentissent les gros lots, et gardez la source en lecture seule pendant quelques semaines plutôt que de la supprimer le jour même.

Git est étonnamment indulgent ici, et cela vaut la peine d'être précis sur pourquoi. Chaque clone est une copie complète de l'historique, donc tant qu'un développeur a une copie de travail à jour, le code survit au serveur. C'est réellement rassurant, et cela couvre exactement l'une des deux choses que détient votre forge. L'autre — tickets, discussions de pull requests, fils de revue, releases, pages de wiki, utilisateurs, équipes, permissions, historique de CI — n'existe que dans la base de données, personne n'en a de clone, et c'est généralement la partie qui a mis trois ans à s'accumuler.

D'abord, un miroir push. C'est gratuit et ça tourne tout seul. Dans un dépôt : Settings → Mirror settings → ajoutez un miroir push avec l'URL et un jeton d'accès pour la destination. Forgejo réplique alors chaque branche et chaque tag après chaque push, vers une seconde instance Forgejo, vers Codeberg, ou vers une plateforme que vous avez décidé de garder comme vitrine plutôt que comme domicile. Une mise en garde qui mérite d'être dite clairement : un miroir push republie l'historique fidèlement, y compris un secret que vous vouliez retirer.

Puis une vraie sauvegarde, qui n'est pas l'archive intégrée. Forgejo fournit une commande forgejo dump qui compresse la configuration, les dépôts, les données et un dump de la base de données dans un unique zip. C'est réellement utile à remettre à un mainteneur lors du signalement d'un bug. Ce n'est pas ce sur quoi vous devriez compter pour revenir d'entre les morts : le SQL qu'elle produit a des problèmes connus de longue date à la réimportation, et l'archive réécrit l'ensemble des dépôts à chaque exécution, ce qui, sur une vraie instance, signifie un gros fichier réécrit de zéro chaque nuit. Utilisez plutôt la voie ennuyeuse et vérifiable — dumpez la base de données avec l'outil propre à la base de données, et sauvegardez le répertoire de données sous forme de fichiers :

#!/bin/sh
# /usr/local/bin/forgejo-backup — run from a systemd timer, nightly
set -eu
cd /srv/forgejo

# 1. Consistent database dump, written next to the data.
docker compose exec -T db pg_dump -U forgejo -Fc forgejo > ./db.dump

# 2. Everything that matters, to an encrypted offsite repository.
restic backup ./data ./db.dump ./docker-compose.yml ./.env ./Caddyfile

# 3. Retention, then prove the repository is still readable.
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
restic check

Envoyez-la vers une machine située dans une juridiction différente de celle de la forge, via un dépôt en ajout seul, afin qu'une compromission de la forge ne puisse pas effacer son propre historique — le guide des sauvegardes chiffrées est la version longue des trois lignes ci-dessus, minuteur systemd et restriction de clé en ajout seul compris.

Restaurez-la ensuite une fois, volontairement. Commandez un VPS de test, restaurez-y le snapshot, démarrez le même fichier Compose sur le répertoire de données restauré, chargez le dump de la base de données, pointez une entrée du fichier hosts vers lui et connectez-vous. Chronométrez l'ensemble. Ce chiffre — et non l'existence de la tâche de sauvegarde — est votre véritable position de reprise, et tous ceux qui ont fait cet exercice ont trouvé au moins un élément manquant dans la liste d'inclusion la première fois.

# restic keeps absolute paths, so the stack reappears under the target.
restic restore latest --target /srv/restore
cd /srv/restore/srv/forgejo

docker compose up -d db                # empty volume: the entrypoint creates the database
docker compose exec -T db pg_restore -U forgejo -d forgejo \
  --clean --if-exists --no-owner < db.dump

docker compose up -d                   # then sign in and walk the issue tracker

Les mises à jour, brièvement. Épinglez l'image à une version majeure plutôt qu'à :latest, pour qu'un pull automatique ne vous fasse pas franchir un changement cassant pendant votre sommeil. Lisez les notes de version avant de franchir une limite majeure, prenez d'abord un snapshot, et souvenez-vous qu'une migration de base de données s'exécute au premier démarrage de la nouvelle version — ce qui est une porte sans retour. La mise à jour automatique façon Watchtower est une bonne idée pour un site statique et une mauvaise pour la machine qui détient chacune de vos branches.

Quatre vérifications avant de considérer que c'est terminé. Déconnectez-vous et vérifiez que l'instance n'offre aucun moyen de créer un compte. Depuis un navigateur sans session, vérifiez qu'un dépôt privé est invisible plutôt que simplement interdit. Vérifiez que le runner ne peut pas lire le répertoire de données de la forge. Et vérifiez que le dernier restic check a réussi — la tâche de sauvegarde qui échoue silencieusement, tout le monde en a une, jusqu'au jour où on en a besoin.