Forgejo selbst hosten: eigener Git-Server mit Docker

Wer Forgejo selbst hosten will, holt sich den eigenen Git-Server nach Hause: Repositories, Issues, Pull Requests und Wiki auf einer Maschine, die euch gehört, statt auf der Plattform eines US-Konzerns. Diese Anleitung baut Forgejo mit Docker auf, stellt es hinter Caddy als Reverse Proxy, macht Git über SSH auf Port 222 erreichbar und zeigt, wie ihr eure Projekte von GitHub herüberholt und sauber sichert.

Der Zeitpunkt ist nicht zufällig. Am 15. Oktober 2026 erscheint Forgejo 17, zwei Wochen später endet der Support für Forgejo 16. Wer jetzt einsteigt, sollte deshalb wissen, welche Version er in die Compose-Datei schreibt, bevor er sie schreibt. Die Grundlagen zu Docker stehen in Docker Basics und Installation, sie werden hier nicht wiederholt.

Forgejo selbst hosten: was ihr bekommt

Forgejo ist eine sogenannte Forge: eine Weboberfläche rund um Git, die aus nackten Repositories eine Arbeitsumgebung macht. Dazu gehören Issues, Pull Requests, ein Wiki, Releases, Organisationen mit Teams und ein Paketregister. Git selbst bleibt dabei unverändert; Forgejo verwaltet nur, wer worauf zugreifen darf und was drumherum passiert.

Die Software hat eine Vorgeschichte, die ihren Charakter erklärt. Forgejo entstand im Oktober 2022 als Abspaltung von Gitea, nachdem ein kommerzielles Unternehmen die Domains und die Marke von Gitea übernommen hatte, ohne die Gemeinschaft zu fragen. Anfang 2024 wurde daraus ein Hard Fork, seither entwickeln sich beide Codebasen auseinander. Getragen wird Forgejo vom gemeinnützigen Verein Codeberg e.V. Mit Version 9.0 hat das Projekt ausserdem die Lizenz von MIT auf GPLv3+ umgestellt, mit der Begründung: "Copyleft licenses do not only benefit the developers. They also guarantee freedoms to users of the software."

Warum überhaupt weg von GitHub? GitHub gehört seit dem Kauf im Juni 2018 für 7,5 Milliarden Dollar Microsoft und unterliegt damit dem US-Recht, das wir in Der CLOUD Act: Eure Daten und die amerikanische Software ausführlich beschrieben haben. Für ein öffentliches Open-Source-Projekt mag das verschmerzbar sein. Für private Repositories mit Konfigurationen, Notizen und halbfertigen Ideen ist es eine andere Frage.

Was diese Anleitung bewusst nicht abdeckt, ist Forgejo Actions, das eingebaute CI-System. Es führt Workflows nicht selbst aus, sondern übergibt sie an separate Runner, und ist an GitHub Actions angelehnt, ohne auf Kompatibilität ausgelegt zu sein. Das ist ein eigenes Thema mit eigenen Sicherheitsfragen.

Welche Version: Forgejo LTS oder die stabile Reihe

Forgejo veröffentlicht alle drei Monate eine neue Hauptversion, und die jeweils erste des Jahres ist eine LTS-Version mit längerem Support. Der offizielle Release-Zeitplan nennt für die nächsten Monate folgende Daten:

• Forgejo 15.0 (LTS): erschienen am 16. April 2026, Support bis 15. Juli 2027
• Forgejo 16.0: erschienen am 16. Juli 2026, Support bis 29. Oktober 2026
• Forgejo 17.0: geplant für den 15. Oktober 2026, Support bis 28. Januar 2027
• Forgejo 19.0 (LTS): geplant für den 15. April 2027

Stand heute sind laut der Release-Übersicht Forgejo 16.0.5 und die LTS-Fassung 15.0.9 aktuell, beide vom 17. September 2026.

Für einen Server, den ihr nebenher betreibt, ist die LTS-Reihe die vernünftige Wahl. Die Docker-Installationsseite von Forgejo hält fest, dass der Sprung von einer Hauptversion zur nächsten, etwa von 12 auf 13, "a manual operation and human verification" verlangt. Mit der stabilen Reihe steht diese Handarbeit viermal im Jahr an, mit der LTS-Reihe einmal. Wer neue Funktionen sofort haben will, nimmt die stabile Reihe und plant die Quartalsupdates fest ein; alle anderen schreiben den Tag 15 in die Compose-Datei und bekommen Fehlerbehebungen und Sicherheitskorrekturen automatisch.

Ein Punkt spricht zusätzlich für Gelassenheit: Forgejo 16 ist ausdrücklich "a non-LTS release". Wer jetzt auf 16 einsteigt, muss in vier Wochen ohnehin auf 17 wechseln.

Voraussetzungen für den eigenen Git-Server

Ihr braucht einen Linux-Server mit Docker und dem Compose-Plugin aus dem offiziellen Docker-Repository. Achtung: Die Installationsanleitung in unserem Docker-Grundlagenartikel installiert das Compose-Plugin nicht mit. Holt es laut Docker-Dokumentation nach und prüft die Version:

sudo apt-get update
sudo apt-get install docker-compose-plugin
docker compose version

Dazu kommen eine Domain oder Subdomain, die auf euren Server zeigt, in dieser Anleitung git.example.ch, sowie ein laufendes Caddy. Feste Hardwareanforderungen nennt die offizielle Forgejo-Dokumentation nicht.

An Ports werden gebraucht: 80 und 443 für Caddy, wie gehabt, und 222 für Git über SSH. Port 22 bleibt für den SSH-Zugang zum Server selbst reserviert. Wer den Server über das Internet erreichbar macht, gibt Port 222 in der Firewall frei; wer Forgejo nur im Heimnetz oder über Wireguard nutzt, lässt ihn zu.

Kurz vor dem Loslegen noch ein Wort zur eigenen Motivation: Einen eigenen Git-Server aufzusetzen, um ein Dotfiles-Repository mit drei Commits zu hosten, ist klassische Selfhosting-Überdimensionierung. Wir machen es trotzdem, aus Prinzip.

Die Compose-Datei: Forgejo mit SQLite

Die Forgejo-Dokumentation empfiehlt in ihren Konfigurationsempfehlungen für Instanzen mit geringer bis mittlerer Last ausdrücklich SQLite, weil sie einfach ist, keine Wartung braucht und als eine einzige Datei auf der Platte liegt. PostgreSQL oder MySQL empfiehlt sie erst für viel Betrieb. Für einen privaten Git-Server heisst das: Ein Container genügt.

Legt ein Verzeichnis an und prüft, welche Benutzer- und Gruppen-ID euer Konto hat:

sudo mkdir -p /opt/forgejo
sudo chown $USER: /opt/forgejo
cd /opt/forgejo
id -u
id -g

Die beiden Zahlen gehören gleich in die Compose-Datei. Auf den meisten Einzelplatzsystemen ist es 1000. Legt nun /opt/forgejo/compose.yml mit folgendem Inhalt an:

networks:
  forgejo:
    external: false

services:
  server:
    image: codeberg.org/forgejo/forgejo:15
    container_name: forgejo
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - FORGEJO__server__DOMAIN=git.example.ch
      - FORGEJO__server__ROOT_URL=https://git.example.ch/
      - FORGEJO__server__SSH_DOMAIN=git.example.ch
      - FORGEJO__server__SSH_PORT=222
      - FORGEJO__server__SSH_LISTEN_PORT=22
    restart: always
    networks:
      - forgejo
    volumes:
      - ./forgejo:/data
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "127.0.0.1:3000:3000"
      - "222:22"

Der Aufbau folgt dem Beispiel aus der Docker-Installationsseite von Forgejo, mit drei Änderungen: dem Tag 15 statt 16, den Servereinstellungen als Umgebungsvariablen und der Bindung von Port 3000 an 127.0.0.1.

Was die einzelnen Zeilen tun

USER_UID und USER_GID legen fest, unter welcher ID Forgejo im Container läuft. Die Dokumentation verlangt, dass das Datenverzeichnis genau diesem Benutzer gehört. Stimmt das nicht, startet der Container nicht sauber.

Die Variablen mit FORGEJO__ am Anfang sind Einträge in der Konfigurationsdatei app.ini, geschrieben nach dem Muster FORGEJO__abschnitt__SCHLÜSSEL. So bleibt die gesamte Konfiguration in einer Datei, die ihr versionieren und sichern könnt. Eine Einschränkung nennt die Dokumentation selbst: Einen bestehenden Wert könnt ihr über Umgebungsvariablen nicht löschen, nur überschreiben.

ROOT_URL ist die Adresse, unter der Forgejo von aussen erreichbar ist, und damit die Grundlage jedes Links, den Forgejo erzeugt. SSH_PORT ist laut Konfigurationsreferenz der Port, der in der Klon-Adresse erscheint. Ohne diese Zeile zeigt Forgejo Adressen mit Port 22 an, die bei euch ins Leere laufen. SSH_LISTEN_PORT gilt für den eingebauten SSH-Server; das Standard-Image benutzt stattdessen OpenSSH im Container auf Port 22. Die Zeile ist eine Absicherung dafür, dass niemand später die beiden Ports verwechselt.

Die Portzeile 127.0.0.1:3000:3000 sorgt dafür, dass die Weboberfläche nur auf dem Server selbst erreichbar ist. Von aussen führt der Weg ausschliesslich über Caddy. Die Zeile 222:22 leitet Port 222 des Servers auf den SSH-Dienst im Container weiter.

Wann ihr doch PostgreSQL nehmt

Plant ihr eine Instanz für einen Verein oder ein Team mit regem Betrieb, ergänzt ihr einen Datenbankdienst. Die Docker-Seite von Forgejo zeigt dafür diese Erweiterung, die in environment des Forgejo-Dienstes und als zweiter Dienst dazukommt:

      - FORGEJO__database__DB_TYPE=postgres
      - FORGEJO__database__HOST=db:5432
      - FORGEJO__database__NAME=forgejo
      - FORGEJO__database__USER=forgejo
      - FORGEJO__database__PASSWD=ein-langes-zufallspasswort

  db:
    image: postgres:14
    restart: always
    environment:
      - POSTGRES_USER=forgejo
      - POSTGRES_PASSWORD=ein-langes-zufallspasswort
      - POSTGRES_DB=forgejo
    networks:
      - forgejo
    volumes:
      - ./postgres:/var/lib/postgresql/data

Beim Forgejo-Dienst kommt zusätzlich depends_on: [db] hinzu. Das Passwort muss an beiden Stellen identisch sein. Die Dokumentation verwendet in ihrem Beispiel forgejo als Passwort; übernehmt das nicht.

Erster Start und das Administratorkonto

Legt das Datenverzeichnis an, übergebt es der ID aus der Compose-Datei und startet den Container:

mkdir -p /opt/forgejo/forgejo
sudo chown -R 1000:1000 /opt/forgejo/forgejo
docker compose up -d
docker compose logs -f server

Wenn die Logs zur Ruhe kommen, beendet ihr sie mit Strg+C. Der Container läuft weiter.

Jetzt kommt der Schritt, bei dem die Reihenfolge zählt. Laut Installationsanleitung erhält der erste registrierte Benutzer Administratorrechte. Solange Forgejo nur an 127.0.0.1 lauscht und Caddy noch nicht konfiguriert ist, kann das niemand ausser euch sein. Öffnet von eurem Rechner aus einen SSH-Tunnel zum Server:

ssh -L 3000:127.0.0.1:3000 benutzer@euer-server

Ruft dann im Browser http://localhost:3000 auf. Forgejo zeigt beim ersten Aufruf eine Seite mit der Grundkonfiguration. Prüft dort, dass Datenbanktyp SQLite3, Server-Domain, SSH-Port 222 und die Basis-URL https://git.example.ch/ stimmen, und schliesst die Installation ab. Registriert danach sofort euer eigenes Konto. Es wird das Administratorkonto.

Anschliessend sperrt ihr die offene Registrierung, bevor die Instanz von aussen erreichbar wird. Ergänzt in der Compose-Datei unter environment:

      - FORGEJO__service__DISABLE_REGISTRATION=true
      - FORGEJO__service__DEFAULT_KEEP_EMAIL_PRIVATE=true

Die zweite Zeile blendet die E-Mail-Adressen neuer Konten standardmässig aus. Wollt ihr, dass ohne Anmeldung überhaupt nichts sichtbar ist, auch keine öffentlichen Repositories, kommt FORGEJO__service__REQUIRE_SIGNIN_VIEW=true dazu. Übernehmt die Änderung mit:

docker compose up -d

Compose erkennt die geänderte Umgebung und erstellt den Container neu. Weitere Konten legt ihr ab jetzt als Administrator in der Verwaltungsoberfläche an. Schaltet für euer eigenes Konto gleich die Zwei-Faktor-Authentifizierung ein: Forgejo unterstützt laut Codeberg-Dokumentation TOTP und zusätzlich Hardwareschlüssel über WebAuthn, eingerichtet in den Benutzereinstellungen unter Sicherheit. Den dabei angezeigten Wiederherstellungscode legt ihr in euren Passwortmanager.

HTTPS über Caddy

Mit Caddy ist der Reverse Proxy für Forgejo eine Sache von drei Zeilen. Ergänzt in /etc/caddy/Caddyfile den Block, den auch die Forgejo-Dokumentation zum Reverse Proxy zeigt:

git.example.ch {
	reverse_proxy 127.0.0.1:3000
}

Prüfen und neu laden wie gewohnt:

sudo caddy fmt --overwrite /etc/caddy/Caddyfile
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

Caddy holt das Zertifikat selbst und setzt die Kopfzeilen X-Forwarded-For und X-Forwarded-Proto ohne weiteres Zutun. Eine Obergrenze für die Uploadgrösse setzt Caddy nicht; wer stattdessen nginx benutzt, braucht die in der Forgejo-Dokumentation genannte Zeile client_max_body_size 512M;, sonst scheitern grosse Pushes über HTTPS und Anhänge.

Ein Detail betrifft alle, die später auf Forgejo 17 oder die nächste LTS wechseln. Mit Forgejo 16 hat das Projekt die Voreinstellung für vertrauenswürdige Proxys in Container-Installationen verschärft. Die Release-Notiz nennt als Folge, dass Forgejo eine Anmeldung über Kopfzeilen des Reverse Proxy nicht mehr akzeptiert, wenn diese Funktion eingeschaltet ist, und verlangt eine ausdrückliche Liste mit dem Adressbereich des Container-Netzes. In der Konfiguration heisst der Schlüssel REVERSE_PROXY_TRUSTED_PROXIES im Abschnitt [security]. Wer diese Anmeldung nicht nutzt, wie in dieser Anleitung, ist davon nicht betroffen.

Sitzt der Proxy, ist die Weboberfläche unter https://git.example.ch erreichbar. Das war der unspektakuläre Teil. Wer bis hierhin gekommen ist, hat einen Git-Server, der sich im Browser nicht von einem gemieteten unterscheidet, nur dass ihn niemand mit einer KI-Funktion beglücken wird, um die ihr nicht gebeten habt.

Git über SSH auf Port 222

Damit Git über SSH funktioniert, braucht Forgejo euren öffentlichen Schlüssel. Wer noch keinen hat, findet die Grundlagen in Sicher per SSH einloggen. Hinterlegt den Inhalt eurer ~/.ssh/id_ed25519.pub in Forgejo unter Einstellungen, SSH-/GPG-Schlüssel.

Testet dann die Verbindung mit dem Befehl aus der Forgejo-Dokumentation:

ssh -F /dev/null git@git.example.ch -p 222

Der Parameter -F /dev/null sorgt dafür, dass eure lokale SSH-Konfiguration beim Test keine Rolle spielt. Forgejo antwortet mit einer kurzen Meldung, die euren Benutzernamen nennt, und schliesst die Verbindung wieder. Eine Shell gibt es an dieser Stelle nicht, und das ist richtig so.

Damit ihr nicht bei jedem Befehl den Port angeben müsst, ergänzt ihr auf eurem Rechner die Datei ~/.ssh/config:

Host git.example.ch
    Port 222
    User git
    IdentityFile ~/.ssh/id_ed25519

Ab jetzt funktionieren Klon-Adressen in der Form, die Forgejo selbst anzeigt:

git clone ssh://git@git.example.ch:222/mario/dotfiles.git

Dank des Eintrags in ~/.ssh/config klappt auch die kürzere Schreibweise git@git.example.ch:mario/dotfiles.git.

Wer über HTTPS statt SSH arbeitet und die Zwei-Faktor-Authentifizierung eingeschaltet hat, meldet sich bei Git nicht mit dem Passwort an, sondern mit einem Zugriffstoken, das ihr in den Einstellungen unter Anwendungen erzeugt.

Von GitHub umziehen: Migration und Spiegel

Forgejo kann bestehende Repositories von GitHub, GitLab und anderen Forges übernehmen. Der Weg führt über das Plus-Menü oben rechts und den Eintrag "Neue Migration". Dort wählt ihr GitHub als Quelle und gebt die Adresse des Repositories an.

Für mehr als den nackten Git-Verlauf braucht Forgejo ein persönliches Zugriffstoken von GitHub. Laut Codeberg-Dokumentation zur Migration lassen sich damit auch Metadaten wie Issues, Labels, Wiki, Releases und Meilensteine mitnehmen. Gebt dem Token nur Leserechte und widerruft es nach dem Umzug wieder. Für private Repositories ist es ohnehin nötig, weil Forgejo sonst gar keinen Zugriff hat.

Nicht jeder will GitHub sofort verlassen. Für den Übergang bietet Forgejo zwei Arten von Spiegeln:

• Ein Pull-Spiegel holt regelmässig den Stand eines fremden Repositories in eure Instanz. Er lässt sich nur beim Anlegen eines neuen Repositories einrichten, über dieselbe Migrationsmaske mit dem Häkchen für den Spiegel.
• Ein Push-Spiegel schiebt jeden Stand eures Forgejo-Repositories zu GitHub. Damit wird Forgejo zur führenden Quelle und GitHub zur Kopie. GitHub verlangt dafür ein Token mit dem Recht public_repo, optional zusätzlich workflow.

Beim Push-Spiegel ist die Warnung der Dokumentation ernst zu nehmen: Er schiebt mit Force Push und überschreibt alles, was am Ziel abweichend liegt. Wer auf GitHub noch direkt arbeitet, verliert dort Commits. Die Regel lautet deshalb: Es gibt genau eine Stelle, an der gearbeitet wird, und die andere ist Kopie.

Issues und Labels werden bei einem Pull-Spiegel übrigens nicht mitgespiegelt, wie ein Fehlerbericht im Forgejo-Projekt festhält: Beim Häkchen für den Spiegel sind die Optionen für Issues, Pull Requests und Releases gesperrt, das Projekt führt das als nicht umgesetzte Funktion. Gespiegelt wird der Git-Inhalt. Wer die Diskussionen mitnehmen will, macht eine echte Migration.

Sichern und zurückspielen

Forgejo bringt mit forgejo dump einen eigenen Sicherungsbefehl mit, der alles in ein Archiv packt. Die Upgrade-Anleitung von Forgejo warnt allerdings selbst, dass das Zurückspielen der Datenbank aus diesem Archiv "serious long standing open bugs" hat. Als verlässlichsten Weg empfiehlt sie eine zeitgleiche Momentaufnahme des gesamten Speichers, den Forgejo benutzt.

Mit SQLite und einem einzigen Datenverzeichnis ist genau das einfach: Container anhalten, Verzeichnis archivieren, Container starten.

cd /opt/forgejo
docker compose stop
sudo tar -czf /srv/backup/forgejo-$(date +%F).tar.gz forgejo compose.yml
docker compose start

Die Unterbrechung dauert wenige Sekunden. Weil compose.yml mit im Archiv liegt, enthält die Sicherung auch die komplette Konfiguration. Wer PostgreSQL benutzt, nimmt das Verzeichnis postgres in den tar-Befehl mit auf und erstellt vorher, bei noch laufendem Stack, zusätzlich einen Datenbankauszug, der unabhängig von der PostgreSQL-Version lesbar bleibt:

docker compose exec -T db pg_dump -U forgejo forgejo > /srv/backup/forgejo-db-$(date +%F).sql

Das Zurückspielen ist die Umkehrung: Archiv an denselben Ort entpacken, Eigentümer mit chown -R 1000:1000 prüfen, docker compose up -d. Probiert das einmal auf einer zweiten Maschine aus, bevor ihr es braucht. Warum eine Sicherung, die nie zurückgespielt wurde, wenig wert ist, und wo die zweite Kopie hingehört, steht in Was ist ein gutes Backup: die 3-2-1-Regel erklärt. Den nächtlichen Lauf automatisiert ihr am besten mit einem systemd-Timer statt Cronjob, der euch benachrichtigt, wenn etwas schiefgeht.

Aktualisieren ohne Überraschungen

Innerhalb einer Hauptversion ist ein Update zwei Befehle:

cd /opt/forgejo
docker compose pull
docker compose up -d

Der Tag 15 zieht dabei automatisch die neueste 15.x-Fassung. Mehr Handarbeit verlangt der Wechsel der Hauptversion, bei der LTS-Reihe also im Frühjahr 2027 von 15 auf 19. Die Upgrade-Anleitung nennt dafür diese Reihenfolge:

• Release-Notizen der neuen Version lesen, insbesondere die Abschnitte zu Änderungen mit Bruch.
• Warteschlangen leeren, weil ihr Inhalt laut Dokumentation nicht garantiert rückwärtskompatibel ist.
• Vollständige Sicherung wie oben.
• Tag in compose.yml ändern, dann docker compose pull und docker compose up -d.
• Mit forgejo doctor prüfen, dass keine Probleme gemeldet werden, und die Weboberfläche von Hand durchsehen.

Die beiden Forgejo-Befehle laufen im Container, und zwar nicht als root. Forgejo verweigert das mit der Meldung, es sei "not supposed to be run as root". Die Lösung aus dem Fehlerbericht im Forgejo-Dokumentationsprojekt ist, den Befehl mit der Benutzer-ID aus der Compose-Datei auszuführen:

docker exec -u 1000 forgejo forgejo manager flush-queues
docker exec -u 1000 forgejo forgejo doctor check --all --log-file /tmp/doctor.log

Laut Anleitung dürft ihr Hauptversionen grundsätzlich überspringen. Treten dabei Fehler auf, empfiehlt sie, die Zwischenversionen einzeln zu durchlaufen und jeweils zu prüfen.

Wenn etwas nicht klappt

Der Container startet nicht oder meldet fehlende Schreibrechte. Fast immer gehört das Datenverzeichnis dem falschen Benutzer. Prüft mit ls -ln /opt/forgejo, ob forgejo der ID aus USER_UID gehört, und korrigiert mit sudo chown -R 1000:1000 /opt/forgejo/forgejo.

Die Klon-Adresse zeigt Port 22 statt 222. Die Zeile FORGEJO__server__SSH_PORT=222 fehlt oder wurde nach einer Änderung nicht übernommen. Nach jeder Änderung an der Umgebung gehört ein docker compose up -d dazu, ein blosser Neustart des Containers reicht nicht.

SSH fragt nach einem Passwort für den Benutzer git. Der Schlüssel ist in Forgejo nicht hinterlegt, oder SSH bietet einen anderen Schlüssel an. Mit ssh -v -p 222 git@git.example.ch seht ihr, welcher Schlüssel angeboten wird. Landet die Verbindung dagegen beim SSH-Dienst des Servers statt bei Forgejo, fehlt der Port: Ohne -p 222 oder den Eintrag in ~/.ssh/config klopft Git an Port 22.

Ein Forgejo-Befehl im Container meldet, er dürfe nicht als root laufen. Ihr habt docker exec ohne -u 1000 aufgerufen.

Links in E-Mails oder in der Oberfläche zeigen auf localhost:3000. ROOT_URL fehlt oder ist falsch. Die Dokumentation zum Reverse Proxy weist ausdrücklich darauf hin, dass sonst erzeugte Links kaputtgehen.

Grosse Pushes über HTTPS brechen ab. Ein vorgeschalteter nginx begrenzt die Grösse. Caddy tut das in der Grundeinstellung nicht; liegt zusätzlich ein anderer Proxy oder ein CDN davor, prüft dessen Grenze.

Nach einem Hauptversions-Update fehlen Funktionen oder die Oberfläche wirft Fehler. Zurück auf die Sicherung, alten Tag eintragen, und die Release-Notizen lesen, bevor ihr es erneut versucht. Genau deshalb steht die Sicherung in der Reihenfolge vor dem Update und nicht danach.

Fazit: Forgejo ist der kleinste Schritt weg von GitHub

Ein eigener Git-Server klingt nach Infrastrukturprojekt und ist am Ende ein Container, eine Compose-Datei und drei Zeilen Caddyfile. Forgejo nimmt euch dabei die Arbeit ab, die eine Forge ausmacht, und lässt euch die Entscheidung, wo eure Repositories liegen. Mit der LTS-Reihe hält sich auch der Pflegeaufwand in Grenzen: ein Handgriff pro Jahr für die Hauptversion, dazwischen docker compose pull.

Die Gegenrechnung gehört dazu. Auf GitHub findet euch die Welt, auf eurem Server findet euch zunächst niemand. Für öffentliche Projekte, die von Beiträgen Fremder leben, ist ein Push-Spiegel deshalb oft der ehrlichere Weg als der harte Schnitt. Für alles Private gilt dagegen: Was nie auf einem fremden Server lag, kann dort auch niemand auswerten, herausgeben oder für das Training eines Modells verwenden. Dass Forgejo seit Version 9 unter einer Copyleft-Lizenz steht und von einem gemeinnützigen Verein getragen wird, macht es ausserdem deutlich unwahrscheinlicher, dass euch in drei Jahren dieselbe Geschichte mit einer anderen Firma noch einmal passiert.

Quellen und weiterführende Links

• Forgejo: Installation with Docker
• Forgejo: Installation
• Forgejo: Release Schedule
• Forgejo: Releases
• Forgejo v16.0 is available (16.07.2026)
• Forgejo: Recommended Settings
• Forgejo: Configuration Cheat Sheet
• Forgejo: Reverse Proxy
• Forgejo: Upgrade Guide
• Forgejo: Repository Mirrors (v15.0)
• Forgejo Actions: Overview
• Forgejo: Comparison with Gitea
• Forgejo is now copyleft, just like Git (22.08.2024)
• Forgejo Docs Issue #722: Forgejo doctor can not be run as root in a container
• Forgejo Issue #4962: Pull mirroring does not mirror labels, issues
• Codeberg Documentation: Migrating repositories
• Codeberg Documentation: Setting up two-factor authentication
• Docker Docs: Install the Docker Compose plugin
• Microsoft: Microsoft to acquire GitHub for $7.5 billion (04.06.2018)