Gitea: leichtgewichtiger Self-host-Git-Server mit Gitea Actions

Was ist Gitea?

Gitea ist ein in Go geschriebener Git-Hosting-Server, der GitHub funktional weitgehend nachbildet, aber komplett self-host läuft. Das Projekt wurde 2016 als Fork von Gogs gestartet (nachdem Gogs in der Maintainer-Aktivität nachgelassen hatte) und ist mittlerweile (Mai 2026) in Version 1.22 – ein etablierter Spieler mit über 45.000 GitHub-Sternen und einer aktiven Community.

Lizenz: MIT – vollständig frei, ohne Klauseln. Seit 2022 gibt es Gitea Ltd. als kommerzielle Entität, die Gitea Cloud anbietet – der Open-Source-Kern bleibt aber MIT und voll self-hostbar. Das hat Ende 2022 zu einem Lizenz-Konflikt geführt, aus dem Forgejo als Codeberg-Fork entstand. Beide Projekte sind funktional Mai 2026 nahezu identisch, mit leicht unterschiedlichen Release-Zyklen.

Architektur: ein einziges Go-Binary, plus eine Datenbank (SQLite, MySQL oder PostgreSQL). Das Binary ist ca. 130 MB, RAM-Footprint im Leerlauf ca. 100 MB. Damit läuft Gitea problemlos auf einem 1-vCPU-Server mit 1 GB RAM. Im Vergleich zu GitLab Omnibus (4 GB RAM Mindestens, Postgres + Redis + nginx + Sidekiq) ist Gitea drastisch ressourcen-genügsamer.

Funktionsumfang: Repositories, Issues, Pull-Requests, Code-Review, Wiki, Releases, Container-Registry (OCI-konform), Paket-Registry (npm, pypi, maven, NuGet, Helm, Gem, Cargo, Conan, Debian, RPM), SSH/HTTPS-Zugriff, Webhooks, OAuth2-Provider, LDAP-Integration. Seit 2023: Gitea Actions – GitHub-Actions-kompatible YAML-Pipelines.

Mai 2026 Status: Gitea 1.22 stabilisiert die Actions-Engine, verbessert die Performance bei grossen Repositories und bringt erweiterte Sicherheits-Features (TLS-Pinning, GPG-Signaturen, Action-Token-Scopes). Standard-Wahl für KMU-Self-host in 2026.

Warum es zählt

Gitea löst für Schweizer KMU zwei harte Probleme: Datenort und Lock-in.

Datenort: Quellcode ist Geschäftsgeheimnis. Wer Mandanten-Software, internes Tooling oder proprietäre Algorithmen entwickelt, sollte den Code nicht auf einen US-Server legen. GitHub gehört Microsoft, die Server stehen in den USA, der CLOUD Act gibt US-Behörden Zugriffsrechte. Für Schweizer Treuhand-Mandanten unter Berufsgeheimnis (StGB 321) ist das problematisch – Gitea self-host auf Hetzner Falkenstein löst das definitiv.

Lock-in: GitHub-Workflows lassen sich nicht trivial über Tools wie Issue-Tracker portieren. Eine spätere Migration ist mühsam. Gitea ist Git-Repository-Standard und ein Migrations-Tool zu/von GitHub eingebaut – Migration in beide Richtungen in unter einer Stunde für Standard-KMU-Repos.

KMU-Tauglichkeit: Gitea-Setup ist eine docker-compose-Datei und 10 Minuten. Verglichen mit GitLab Omnibus (1-2 Tage Setup, Lernkurve hoch, Monitoring nötig) ist Gitea für 1-15-Personen-Teams die deutlich rationalere Wahl. Funktional sind die Unterschiede klein – Issues, PRs, Reviews, CI/CD funktionieren in Gitea genauso wie in GitLab.

Lizenz-Kosten: Null. MIT-Lizenz ohne Einschränkungen. GitHub Team kostet USD 4 pro User pro Monat – bei 5 Entwicklern USD 240/Jahr. GitLab Premium USD 29 pro User/Monat – bei 5 Entwicklern USD 1740/Jahr. Gitea: null pro User, nur Hardware-Kosten (Hetzner CX22 CHF 6/Monat = CHF 72/Jahr).

Gitea Actions als Game-Changer: seit 2023 ist Gitea kein "Git-Only-Server" mehr, sondern komplette CI/CD-Plattform. Workflows werden in .gitea/workflows/*.yml geschrieben – Syntax fast 1:1 kompatibel mit GitHub Actions. Damit lassen sich GitHub-Workflows direkt übernehmen, mit minimalen Anpassungen.

Compliance-Vorteil: Für regulierte Sektoren (Treuhand, Anwalt, Versicherung) ist die Audit-Spur einfacher zu führen. Gitea-Logs, Postgres-Audit-Logs, plus Gitea-eigene Aktivitäts-Logs sind alle on-premise – kein Drittanbieter-Zugriff, klare Linie für DPIA-Dokumentation.

Wie es funktioniert

Gitea läuft als einzelnes Go-Binary. Konfiguration in einer INI-Datei (app.ini), Daten in einem Verzeichnis (data/) plus Datenbank.

docker-compose.yml-Beispiel:

```yaml services: gitea: image: gitea/gitea:1.22 environment: USER_UID: 1000 USER_GID: 1000 GITEA__database__DB_TYPE: postgres GITEA__database__HOST: db:5432 GITEA__database__NAME: gitea GITEA__database__USER: gitea GITEA__database__PASSWD: ${DB_PASSWORD} volumes: - gitea-data:/data ports: - "3000:3000" - "22:22" depends_on: [db] restart: unless-stopped db: image: postgres:16 environment: POSTGRES_USER: gitea POSTGRES_PASSWORD: ${DB_PASSWORD} POSTGRES_DB: gitea volumes: - db-data:/var/lib/postgresql/data restart: unless-stopped volumes: gitea-data: db-data: ```

Nach dem ersten Start: Browser auf http://server:3000, Installations-Wizard durchklicken, Admin-Account anlegen, fertig. Hinter nginx-Reverse-Proxy mit Lets-Encrypt-Zertifikat läuft das produktiv auf git.firma.ch.

Gitea Actions Setup: ein zusätzlicher Runner-Container, der Actions ausführt.

```yaml runner: image: gitea/act_runner:latest environment: GITEA_INSTANCE_URL: https://git.firma.ch GITEA_RUNNER_REGISTRATION_TOKEN: ${RUNNER_TOKEN} volumes: - /var/run/docker.sock:/var/run/docker.sock - runner-data:/data ```

Danach werden alle .gitea/workflows/*.yml-Dateien bei Push ausgeführt – Build, Test, Deploy, Container-Push.

Container-Registry: integriert. Ein Docker-Image kann direkt nach git.firma.ch/owner/image:tag gepushed werden, ohne separaten Registry-Service. Authentifizierung via Gitea-User oder Token.

Backup: einfache Strategie. Postgres-Dump plus rsync des data/-Verzeichnisses (enthält LFS-Objekte, Avatare, Issue-Anhänge). Restore: data-Verzeichnis zurückkopieren, Postgres-Dump einspielen, fertig. Backup-Cron daily, Aufbewahrung 30 Tage, klassisch.

LDAP/OAuth: Gitea kann sich an LDAP/AD anbinden (für Firmen mit zentraler Identity) oder als OAuth2-Provider für andere Apps dienen. Damit ist Single-Sign-On in einer KMU-Toolchain praktisch ohne zusätzlichen Komponente möglich.

Setup in 5 Schritten

1. 01docker-compose mit gitea:1.22 plus postgres:16 anlegen, Volumes persistieren, Port 3000 und 22 freischalten.
2. 02Installations-Wizard durchklicken: Datenbank Postgres, SQLite nur für Tests, Admin-Account mit starkem Passwort, SSH-Keys für Push-Zugriff.
3. 03nginx-Reverse-Proxy auf git.firma.ch mit Lets-Encrypt-Zertifikat, HSTS-Header, Rate-Limit auf /login Endpoint.
4. 04Gitea Actions Runner deployen: act_runner-Container mit Registrierungs-Token, Docker-Socket-Mount, erste .gitea/workflows/test.yml schreiben.
5. 05Backup-Cron einrichten: pg_dump + rsync data/ auf zweite Disk oder Hetzner-Storage-Box, täglich, Retention 30 Tage.

Wann Gitea einsetzen

Gitea ist die richtige Wahl, wenn (a) das Team 1 bis 20 Entwickler hat, (b) Code in der Schweiz/EU bleiben soll, (c) Setup-Zeit unter einem halben Tag erwartet wird, (d) das Budget kein GitLab Premium oder GitHub Enterprise zulässt.

Konkrete KMU-Fälle: Ein Treuhand-Büro mit einem internen Tooling-Team (2-3 Personen) – Gitea als Code-Heimat plus Gitea Actions für Build/Deploy von Bexio-Integrationen. Eine Anwaltskanzlei mit selbst-entwickelter Mandanten-Plattform – Gitea hostet Code, Actions deployen automatisch nach jedem Push. Eine SaaS-Boutique mit 5-10 Entwicklern – Gitea als zentraler Hub für Issues, Reviews, Releases, Container-Registry.

Gitea passt zudem gut zu Compliance-getriebenen Mandaten: Treuhand-Software, die Mandanten-Daten verarbeitet, sollte unter Berufsgeheimnis-Schutz versioniert werden. Gitea self-host löst das, ohne dass Sie die Welt von kommerziellen Anbietern erklären müssen.

Wann NICHT

Gitea ist die falsche Wahl, wenn (a) das Projekt Open Source ist und Community-Discoverability braucht – GitHub ist dann strategisch besser, (b) das Team über 25 Entwickler hat und enterprise-Features wie sehr granulare Permissions oder Audit-Logs auf Compliance-Niveau nötig sind – GitLab Premium passt besser, (c) sehr grosse Monorepos (5+ GB) gehostet werden – Gitea funktioniert, aber GitLab oder GitHub Enterprise sind dafür optimierter.

Fallen: Gitea ohne Backup-Strategie betreiben – bei einem Disk-Crash sind alle Repos und Issues weg. Backup-Cron daily ist Pflicht. Gitea Actions ohne Resource-Limits laufen lassen – ein fehlerhaft konfigurierter Build kann den Host füllen. Gitea-Datenbank auf SQLite belassen bei wachsendem Team – ab ca. 10 Usern auf Postgres migrieren.

Nicht empfohlen: Gitea als Notlosung neben GitHub betreiben – beide Repos parallel zu synchronisieren ist Konfigurations-Schmerz. Entscheidung treffen: entweder GitHub oder Gitea, nicht beides. Gitea ohne Reverse-Proxy mit TLS direkt ins Internet exponieren – Brute-Force-Attacken auf SSH-Port 22 sind täglich.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Gitea – Documentation · 2026-05
2. Gitea – GitHub repository · 2026-04
3. Gitea Actions – Workflow syntax · 2026-03
4. Forgejo – Codeberg fork comparison · 2026-04