Git im Eigenbetrieb: Gitea und Forgejo

Der Agent schreibt Code — aber wo lebt der? GitHub und GitLab sind mächtig, aber sie sind SaaS. Gitea und Forgejo sind die quelloffenen Alternativen, die auf einem eigenen Server laufen und alles mitbringen, was ein Team braucht.

Gitea vs. Forgejo: Der kleine Unterschied

Gitea ist der etablierte Self-Hosted-Git-Dienst — eine einzelne Binary, ein Docker-Container, eine PostgreSQL-Datenbank. Forgejo ist ein Gitea-Fork, 2022 aus Governance-Bedenken entstanden, seit dem Hard-Fork 2024 unter strikter Copyleft-Lizenz und mit eigenem Profil: Der Fokus liegt auf Community-Steuerung und Föderation (ActivityPub-basierte Vernetzung von Instanzen).

Beide können:

Git-Repositories mit Web-UI, Branches, Tags
Pull Requests mit Code-Review
Issues mit Labels, Meilensteinen, Boards
Actions/CI-Runner (Gitea Actions sind GitHub-Actions-kompatibel)
Package Registry (Docker, NPM, Maven)

In der Praxis spielt der Unterschied für KMU heute kaum eine Rolle. Beide laufen stabil, beide haben eine Weboberfläche, die an GitHub erinnert. Wer Wert auf eine reine Community-Governance legt, nimmt Forgejo; wer den grösseren kommerziellen Rückhalt sucht, Gitea.

Setup: Ein Container

docker run -d --name gitea \
  -p 3000:3000 -p 2222:22 \
  -v gitea-data:/data \
  gitea/gitea:latest

Einrichtung: Admin-Account anlegen, Domain setzen, läuft. Der Reverse Proxy (Caddy) macht HTTPS davor, Keycloak übernimmt das SSO. Das /data-Volume gehört in die Backup-Kette — es enthält Repos, DB und Konfiguration.

Warum on-prem?

Der Quellcode ist das intellektuelle Eigentum des Unternehmens — inklusive Konfigurationen, Skripte, Prompts, MCP-Server-Code. Das auf GitHub oder GitLab zu hosten ist bequem, aber:

NIS2: Code-Repositories fallen unter die zu schützenden Assets
Datenhoheit: Vertrauliche Konfigurationen, Secrets, Kundenprojekte
Ausfallsicherheit: Der eigene Git-Server läuft im eigenen Cluster, nicht in der AWS-us-east-1 während eines Ausfalls

CI/CD mit Gitea Actions

Gitea Actions sind GitHub-Actions-kompatibel. Ein Runner (ein Container) lauscht auf Jobs, führt sie aus, meldet zurück. Build, Test, Deploy — alles im eigenen Netz.

Für das Blog-Deployment: Push nach Gitea, Action baut das Next.js-Image, deployt auf den senn-next-Container. Keine externe CI, kein fremder Runner, der Zugriff auf interne Server hat.

Fazit

Gitea oder Forgejo sind die kürzeste Strecke zwischen "kein Git-Server" und "vollwertiges Code-Management im eigenen Haus". Ein Nachmittag Setup, dann jahrelang Ruhe — und jeder Agent, der Code schreibt, checkt ihn dorthin ein.

FAQ

Lohnt sich der Aufwand eines eigenen Git-Servers gegenüber GitHub?+

Für Unternehmen mit eigenem Code, internen Konfigurationen und Kundenprojekten ja. Der Quellcode inklusive Secrets, Prompts und MCP-Server-Code fällt unter die NIS2-geschützten Assets, und ein eigener Git-Server im eigenen Cluster entfällt nicht bei einem Cloud-Ausfall. Gitea oder Forgejo sind in einem Nachmittag als einzelner Docker-Container eingerichtet und bringen Pull Requests, Issues und CI mit — kein laufender SaaS-Vertrag, der die Hoheit über den Code abgibt.

Für wen ist Forgejo statt Gitea die richtige Wahl?+

Für Teams, die auf reine Community-Governance und Föderation über ActivityPub Wert legen. Forgejo ist ein Gitea-Fork aus Governance-Bedenken, seit 2024 unter strikter Copyleft-Lizenz mit Fokus auf unabhängige Steuerung und Vernetzung von Instanzen. In der Praxis spielt der Unterschied für KMU heute kaum eine Rolle — beide laufen stabil und haben eine GitHub-ähnliche Oberfläche. Wer grösseren kommerziellen Rückhalt sucht, bleibt bei Gitea.

Kann man CI/CD wirklich vollständig intern betreiben?+

Ja. Gitea Actions sind GitHub-Actions-kompatibel: Ein Runner-Container lauscht auf Jobs, führt Build, Test und Deploy aus und meldet zurück — alles im eigenen Netz ohne externen Runner mit Zugriff auf interne Server. Für das Deployment pushen Sie nach Gitea, eine Action baut das Image und deployt. Das schafft eine geschlossene Pipeline ohne Abhängigkeit von fremder CI-Infrastruktur.