Ihr eigener Git-Server.
Das Repository ist das Organigramm.

Fast jedes Argument über das Self-Hosting von Git ist ein Argument über den Quellcode, und der Quellcode ist der Teil, der am wenigsten zählt. Das meiste davon ist unauffällig, ein großer Teil davon ist nur eine dünne Schicht über Open-Source-Bibliotheken, und würde er morgen durchsickern, wäre der praktische Schaden meist Peinlichkeit statt echter Schaden. Deshalb fühlt sich „mein Code ist nicht geheim“ wie eine vollständige Antwort an — und deshalb ist es keine.

Was den Code umgibt, ist der interessante Teil. Ein Repository ist eine datierte, zugeordnete, hochauflösende Aufzeichnung von Arbeit: Commit-Zeitstempel, die verraten, wann Sie schlafen, Co-Autor-Zeilen, die verraten, mit wem Sie arbeiten, Branch-Namen, die Produkte verraten, die niemand angekündigt hat, ein Issue-Tracker, der verrät, was kaputt ist und wie schlimm, und ein erster Commit, der das ganze Projekt datiert. Lesen Sie hundert Repositories auf diese Weise, und Sie lesen keine Software mehr — Sie lesen ein Unternehmen, seine Roadmap, seinen Personalstand und seine Schwierigkeiten.

Auf einer Plattform gehört Ihnen diese Aufzeichnung in keinem nennenswerten Sinn. Sie liegt auf Infrastruktur, die Sie nicht kontrollieren, unter einem Konto, das an eine von Ihnen verifizierte Identität gebunden ist, in einem Rechtsraum, dessen Rechtsweg sie erreicht, gescannt von Systemen, deren Umfang von einem Dokument festgelegt wird, das geändert werden kann. Nichts davon erfordert bösen Willen von irgendjemandem: Es ist einfach das, was es bedeutet, den Tracker zu mieten. Vier Konstellationen, und was jede davon tatsächlich preisgibt:

Zeile drei ist die Zeile, die Teams erwischt, die glauben, das Problem schon gelöst zu haben. Eine Forge, die Sie selbst installiert haben, auf einer Maschine, die mit einer Firmenkarte unter einem verifizierten Firmenkonto gemietet wurde, hat die Anwendung von der Plattform weggeholt und die Identität exakt dort belassen, wo sie war. Das ist ein echter Gewinn an Kontrolle und überhaupt kein Gewinn bei der Exposition.

Und Zeile vier benennt ihre eigenen Kosten unverblümt, denn der Rest dieses Leitfadens handelt größtenteils davon, sie zu bezahlen. Der Fehlermodus des Self-Hostings ist nicht Überwachung, sondern Verlust. Eine Plattform führt Backups, über die Sie nie nachdenken. Ihr Server führt die Backups, die Sie konfiguriert haben. Schritt 06 ist nicht der optionale Feinschliff am Ende — er ist der Schritt, der die anderen fünf sicher macht.

Bestellen Sie zuerst die Maschine. Im Panel: Bestellen → VPS → Sentinel, Image Debian 12, in welcher Bastion auch immer die Historie leben soll — Helsinki, Stockholm, Oslo oder Reykjavík. Für die Kontoeröffnung ist keine E-Mail-Adresse nötig, und die Rechnung wird in Monero, Bitcoin, Lightning oder jeder anderen unterstützten Kryptowährung beglichen. Das zählt hier mehr als bei den meisten Workloads: Eine Forge ist der eine Dienst, dessen gesamtes Wertversprechen darin besteht, dass die Aufzeichnung Ihrer Arbeit an keinen Namen gebunden ist.

Durchlaufen Sie dann die Checkliste zur Härtung der ersten Stunde — SSH nur mit Schlüssel auf einem verlegten Port, unbeaufsichtigte Updates, eine Default-Deny-Firewall — denn alles Folgende setzt eine Maschine voraus, die nicht schon jemand anderem gehört.

Richten Sie einen Hostnamen auf die Maschine — einen A-Record, und einen AAAA, wenn sie über IPv6 erreichbar sein soll — und lassen Sie ihn propagieren, bevor Sie beginnen, denn der Reverse Proxy wird beim ersten Hochfahren versuchen, ein Zertifikat für diesen Namen zu beziehen, und eine fehlgeschlagene Challenge ist ein verwirrender Einstieg. Schreiben Sie dann die Firewall-Regeln, solange noch nichts lauscht.

Das Zwei-SSH-Problem. Eine Forge spricht SSH für Git, und Ihr Server spricht bereits SSH für die Administration. Beide können nicht Port 22 besitzen, und sie zu vermischen ist der Weg, auf dem Menschen bei einem administrativen Daemon landen, der auch noch Git verstehen muss. Halten Sie sie getrennt: Administration auf dem verlegten Port aus der Härtungs-Checkliste, Git auf einem eigenen öffentlichen Port, der in den Container gemappt wird. 2222 ist die konventionelle Wahl, und daran ist nichts Heiliges.

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.

Installieren Sie Docker aus dem offiziellen Repository statt aus dem Distributionspaket, damit Compose v2 vorhanden und die Version aktuell ist. Legen Sie dann ein Verzeichnis für den Stack an, und machen Sie es zur einzigen Stelle auf der Maschine, die Zustand hält — es ist das Verzeichnis, das Schritt 06 sichert.

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

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

Fügen Sie Ihren öffentlichen Schlüssel in die Profileinstellungen ein, und bringen Sie Ihrem Client dann bei, wo die Forge liegt. Weil Git auf einem nicht standardmäßigen Port läuft, lohnt sich ein Eintrag in Ihrer SSH-Konfiguration die dreißig Sekunden — er hält den Port aus jeder URL heraus, die Sie je eintippen werden, und macht die Remotes portabel.

# ~/.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

Dieser letzte Befehl ist derjenige, der Ihnen verrät, ob das Port-Mapping, der SSH-Server im Container und Ihr Schlüssel zusammenpassen. Eine Begrüßung von Forgejo bedeutet, dass die ganze Kette funktioniert. Eine Passwortabfrage bedeutet, dass Sie stattdessen den administrativen sshd des Hosts erreicht haben, und dass das Port-Mapping falsch ist.

Signieren Sie jetzt Ihre Commits. Das ist der Schritt, den die meisten Self-Hosting-Leitfäden auslassen, und auf einer selbstgehosteten Forge zählt er mehr als auf einer Plattform. Das Autor-Feld eines Commits ist Freitext — jeder, der pushen kann, kann Ihren Namen hineinschreiben. Eine Signatur ist der Beweis, dass ein bestimmter Schlüssel einen bestimmten Commit erzeugt hat, und sie bleibt Beweis, auch nachdem der Server, zu dem gepusht wurde, kompromittiert, migriert oder weggeworfen wurde. Git kann mit dem SSH-Schlüssel signieren, den Sie bereits haben, sodass es keinen Umweg über PGP mehr braucht:

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

Fügen Sie dann denselben öffentlichen Schlüssel ein zweites Mal in der Forge hinzu, als Signaturschlüssel statt als Authentifizierungsschlüssel. Forgejo verifiziert die Signatur serverseitig und zeigt den Commit als verifiziert an; ohne diesen zweiten Eintrag hat es keine Möglichkeit, die Signatur mit Ihrem Konto zu verknüpfen, und jeder Commit erscheint als nicht verifiziert, obwohl er korrekt signiert ist.

Deploy-Keys, für die Maschinen, die nur lesen. Ein Produktionsserver, eine Build-Maschine oder ein Mirror braucht kein Benutzerkonto auf der Forge. Geben Sie ihm stattdessen einen Deploy-Key: ein Schlüsselpaar, das zu einem Repository hinzugefügt wird, schreibgeschützt, sofern Sie nicht ausdrücklich Schreibrechte gewähren, und das keinen Zugriff auf sonst irgendetwas auf der Instanz gewährt. Ihn zu widerrufen bedeutet, einen einzigen Eintrag zu löschen. Das ist die mit Abstand wirksamste Gewohnheit, um eine selbstgehostete Forge aufgeräumt zu halten, denn Benutzerkonten sammeln Berechtigungen an, Deploy-Keys können das nicht.

Die Migration von einer Plattform ist ein guter Moment, das Ganze richtig zu machen. Forgejos New-Migration-Ablauf nimmt eine Repository-URL und ein Access Token entgegen und überträgt Branches, Tags, Issues, Kommentare, Labels, Meilensteine, Releases und Pull Requests. Lassen Sie zuerst ein Repository laufen, um die Form des Ergebnisses zu sehen, rechnen Sie damit, dass API-Rate-Limits große Stapel verlangsamen, und lassen Sie die Quelle einige Wochen lang schreibgeschützt, statt sie noch am selben Tag zu löschen.

Git ist hier ungewöhnlich nachsichtig, und es lohnt sich, genau zu sein, warum. Jeder Klon ist eine vollständige Kopie der Historie, solange also ein Entwickler eine aktuelle Arbeitskopie hat, überlebt der Code den Server. Das ist wirklich beruhigend, und es deckt genau eines der beiden Dinge ab, die Ihre Forge hält. Das andere — Issues, Pull-Request-Diskussionen, Review-Threads, Releases, Wiki-Seiten, Nutzer, Teams, Berechtigungen, CI-Historie — existiert nur in der Datenbank, niemand hat davon einen Klon, und es ist meist der Teil, der drei Jahre gebraucht hat, um sich anzusammeln.

Zuerst ein Push-Mirror. Er ist kostenlos und läuft von selbst. In einem Repository: Einstellungen → Mirror-Einstellungen → einen Push-Mirror hinzufügen mit der URL und einem Access Token für das Ziel. Forgejo repliziert dann nach jedem Push jeden Branch und Tag — zu einer zweiten Forgejo, zu Codeberg, oder zu einer Plattform, die Sie als Schaufenster statt als Zuhause behalten wollen. Ein Vorbehalt, den man klar aussprechen sollte: Ein Push-Mirror veröffentlicht die Historie originalgetreu erneut, einschließlich eines Secrets, das Sie eigentlich entfernen wollten.

Dann ein echtes Backup, das nicht das eingebaute Archiv ist. Forgejo liefert einen forgejo dump-Befehl, der Konfiguration, Repositories, Daten und einen Datenbank-Dump in eine einzige Zip-Datei packt. Das ist wirklich nützlich, um es einem Maintainer beim Melden eines Bugs in die Hand zu drücken. Es ist nicht das, worauf Sie sich verlassen sollten, um von den Toten zurückzukehren: Das erzeugte SQL hat seit Langem bekannte Probleme beim Re-Import, und das Archiv schreibt bei jedem Lauf den gesamten Repository-Bestand neu, was auf einer echten Instanz eine große, jede Nacht von Grund auf neu geschriebene Datei bedeutet. Verwenden Sie stattdessen den langweiligen, verifizierbaren Weg — die Datenbank mit dem eigenen Werkzeug der Datenbank dumpen, und das Datenverzeichnis als Dateien sichern:

#!/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

Schicken Sie es an eine Maschine in einem anderen Rechtsraum als die Forge, über ein Append-only-Repository, damit eine Kompromittierung der Forge nicht ihre eigene Historie löschen kann — der Leitfaden zu verschlüsselten Backups ist die lange Version der drei Zeilen oben, samt systemd-Timer und der Append-only-Schlüsselbeschränkung.

Stellen Sie es dann einmal absichtlich wieder her. Bestellen Sie eine Test-VPS, spielen Sie den Snapshot darauf ein, fahren Sie dieselbe Compose-Datei gegen das wiederhergestellte Datenverzeichnis hoch, laden Sie den Datenbank-Dump, richten Sie einen Hosts-Datei-Eintrag darauf aus und melden Sie sich an. Stoppen Sie die Zeit für das Ganze. Diese Zahl — nicht die bloße Existenz des Backup-Jobs — ist Ihre tatsächliche Wiederherstellungsposition, und jeder, der diese Übung gemacht hat, hat beim ersten Mal mindestens eine Sache gefunden, die in der Include-Liste fehlte.

# 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

Upgrades, kurz. Binden Sie das Image an eine Hauptversion statt an :latest, damit ein unbeaufsichtigter Pull Sie nicht im Schlaf über eine Breaking Change hinwegträgt. Lesen Sie die Release Notes, bevor Sie eine Hauptversionsgrenze überschreiten, machen Sie zuerst einen Snapshot, und denken Sie daran, dass eine Datenbankmigration beim ersten Start der neuen Version läuft — was eine Einbahnstraße ist. Automatisches Aktualisieren im Watchtower-Stil ist eine gute Idee für eine statische Seite und eine schlechte für die Maschine, die jeden Branch hält, den Sie haben.

Vier Prüfungen, bevor Sie es für erledigt erklären. Melden Sie sich ab und bestätigen Sie, dass die Instanz keine Möglichkeit bietet, ein Konto anzulegen. Bestätigen Sie aus einem Browser ohne Sitzung, dass ein privates Repository unsichtbar ist, statt nur verboten. Bestätigen Sie, dass der Runner das Datenverzeichnis der Forge nicht lesen kann. Und bestätigen Sie, dass der letzte restic check erfolgreich war — den Backup-Job, der lautlos fehlschlägt, hat jeder, genau bis zu dem Tag, an dem er ihn braucht.