DevOps 12 Min Lesezeit

Gitea – Selfhosted Git-Server auf VPS installieren & betreiben 2026

Was ist Gitea und warum ist es 2026 die ideale Wahl für Selbsthosting?

Gitea ist ein leichtgewichtiger, in Go geschriebener Git-Server, der sich durch seine einfache Installation, geringe Ressourcenanforderungen und umfangreiche Funktionalität auszeichnet. Im Jahr 2026 hat sich Gitea als eine der führenden Alternativen zu kommerziellen Plattformen wie GitHub, GitLab und Bitbucket etabliert, insbesondere für Entwickler und Unternehmen, die Wert auf Datenhoheit, Datenschutz und volle Kontrolle über ihre Repositories legen. Die Software wird aktiv von einer weltweiten Community gepflegt und bietet eine moderne Weboberfläche, die funktional kaum Wünsche offen lässt.

Im Vergleich zu GitLab benötigt Gitea nur einen Bruchteil der Systemressourcen. Während GitLab auf einem VPS mit 4 GB RAM bereits an seine Grenzen stößt, läuft Gitea problemlos auf einem Server mit lediglich 1 GB Arbeitsspeicher. Diese Effizienz macht Gitea besonders attraktiv für kleinere Teams, Hobby-Entwickler und Unternehmen, die eine kostengünstige Selfhosting-Lösung suchen. Die Installation erfolgt in der Regel innerhalb weniger Minuten und erfordert keine tiefgreifenden Linux-Kenntnisse.

Ein weiterer entscheidender Vorteil von Gitea ist die vollständige Unterstützung von Open-Source-Standards. Neben klassischem Git via SSH und HTTPS bietet Gitea eine REST-API, Webhooks, Actions (kompatibel mit GitHub Actions), Package-Registries sowie integrierte Wikis und Issue-Tracker. Damit deckt Gitea nahezu alle Funktionen ab, die auch von kommerziellen Plattformen geboten werden, ohne dass dabei Lizenzkosten anfallen. Die Datenhoheit bleibt vollständig beim Betreiber des Servers.

Für deutsche Anwender ist besonders relevant, dass Gitea DSGVO-konform betrieben werden kann, da alle Daten auf eigenen Servern innerhalb Deutschlands oder der EU gespeichert werden. Dies ist ein wesentlicher Vorteil gegenüber US-amerikanischen Diensten, die oft komplexe Datenverarbeitungsvereinbarungen erfordern. Gitea unterstützt zudem LDAP, OAuth und SAML, sodass eine Integration in bestehende Unternehmensstrukturen problemlos möglich ist.

Systemvoraussetzungen für Gitea auf einem VPS im Jahr 2026

Die Systemvoraussetzungen für Gitea sind erfreulich moderat und ermöglichen den Betrieb auch auf kleinen VPS-Instanzen. Für eine produktive Nutzung mit bis zu 100 aktiven Nutzern und mehreren hundert Repositories empfiehlt sich eine Konfiguration mit mindestens 2 CPU-Kernen, 2 GB RAM und 20 GB SSD-Speicher. Diese Ressourcen sind bei nahezu allen aktuellen VPS-Anbietern bereits in den Einstiegstarifen enthalten und machen Gitea zu einer äußerst wirtschaftlichen Lösung.

Als Betriebssystem eignen sich alle gängigen Linux-Distributionen wie Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, Debian 12 (Bookworm) oder Rocky Linux 9. Gitea selbst ist als statisch kompiliertes Binary verfügbar und benötigt keine zusätzlichen Laufzeitumgebungen. Für die Datenhaltung wird standardmäßig SQLite verwendet, das sich für kleine bis mittelgroße Installationen bestens bewährt. Alternativ können MySQL, MariaDB oder PostgreSQL als Datenbanksystem zum Einsatz kommen.

Die folgende Tabelle gibt einen Überblick über die empfohlenen Systemvoraussetzungen je nach Einsatzgröße:

EinsatzgrößeCPU-KerneRAMSpeicherDatenbankNutzer
Klein (privat)11 GB10 GB SSDSQLite1-5
Mittel (Team)22 GB20 GB SSDSQLite/MySQL5-50
Groß (Unternehmen)44 GB50 GB SSDPostgreSQL50-200
Enterprise8+8 GB+100 GB+ SSDPostgreSQL Cluster200+

Für die Netzwerkanbindung empfiehlt sich ein VPS-Standort in Deutschland, um kurze Latenzzeiten und DSGVO-Konformität zu gewährleisten. Anbieter wie Hetzner, Netcup oder IONOS bieten entsprechende Standorte in Frankfurt, Nürnberg oder München an. Eine statische IPv4-Adresse ist Pflicht, damit Gitea über eine feste URL erreichbar ist und SSL-Zertifikate korrekt ausgestellt werden können.

Zusätzlich sollte der VPS über ausreichend Swap-Speicher verfügen, um Lastspitzen abzufangen. Als Faustregel gilt: Swap = 1,5 × RAM. Bei 2 GB RAM empfiehlt sich also ein Swap von 3 GB. Dies verhindert Out-of-Memory-Fehler bei gleichzeitigen Git-Operationen wie Klonen, Push oder Pull mehrerer großer Repositories.

Vorbereitung des VPS: SSH-Zugang, Updates und Firewall einrichten

Bevor mit der eigentlichen Installation von Gitea begonnen wird, muss der VPS grundlegend vorbereitet werden. Zunächst erfolgt die Anmeldung per SSH mit dem vom Provider zugewiesenen Root-Passwort oder besser mit einem SSH-Schlüsselpaar. Der Befehl ssh root@IHRE-IP stellt die Verbindung her. Nach dem ersten Login sollte umgehend das Passwort geändert und ein neuer Benutzer mit sudo-Rechten angelegt werden, um die Sicherheit zu erhöhen.

Ein regelmäßig aktualisiertes System ist die Grundlage für jede sichere Server-Installation. Unter Ubuntu oder Debian werden verfügbare Updates mit folgenden Befehlen eingespielt:

apt update && apt upgrade -y
apt install -y curl wget git nano ufw fail2ban

Die anschließende Konfiguration der Firewall ist ein kritischer Sicherheitsschritt. UFW (Uncomplicated Firewall) bietet eine einfache Möglichkeit, nur die wirklich benötigten Ports freizugeben. Für Gitea werden typischerweise die Ports 22 (SSH), 80 (HTTP) und 443 (HTTPS) benötigt. SSH sollte idealerweise auf einen nicht-standardisierten Port verlegt werden, um automatisierte Angriffe zu erschweren.

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verbose

Fail2Ban ergänzt die Firewall um eine zusätzliche Schutzschicht, indem es nach mehreren fehlgeschlagenen Login-Versuchen automatisch die entsprechenden IP-Adressen sperrt. Standardmäßig überwacht Fail2Ban den SSH-Dienst, kann aber bei Bedarf auch auf den Gitea-Webdienst ausgedehnt werden. Die Konfiguration erfolgt über die Datei /etc/fail2ban/jail.local, in der die gewünschten Schwellenwerte und Sperrzeiten definiert werden.

Abschließend sollte die Zeitzone des Servers korrekt gesetzt werden, da Gitea alle Zeitstempel in der lokalen Zeitzone des Servers anzeigt. Für deutsche Installationen empfiehlt sich Europe/Berlin. Mit timedatectl set-timezone Europe/Berlin wird die Einstellung dauerhaft übernommen. Diese Vorbereitungen schaffen eine solide Grundlage für die nun folgende Gitea-Installation.

Gitea Installation: Schritt-für-Schritt-Anleitung

Die Installation von Gitea erfolgt am einfachsten über das offizielle Binary, das auf der Gitea-Website oder via GitHub Releases heruntergeladen werden kann. Für 64-Bit-Linux-Systeme lautet der Befehl wie folgt:

wget -O gitea https://dl.gitea.com/gitea/1.22/gitea-1.22-linux-amd64
chmod +x gitea
sudo mv gitea /usr/local/bin/gitea

Anschließend wird ein dedizierter Systembenutzer für Gitea angelegt, unter dem der Dienst ausgeführt wird. Dies ist eine wichtige Sicherheitsmaßnahme, da der Gitea-Prozess so nicht mit Root-Rechten läuft und im Falle einer Sicherheitslücke der Schaden begrenzt bleibt.

sudo adduser --system --shell /bin/bash --group --disabled-password --home /var/lib/gitea gitea
sudo mkdir -p /var/lib/gitea/{custom,data,log}
sudo chown -R gitea:gitea /var/lib/gitea
sudo mkdir -p /etc/gitea
sudo chown gitea:gitea /etc/gitea

Die Verzeichnisstruktur folgt dabei den Linux-Standards: /var/lib/gitea enthält alle Anwendungsdaten, Logs und benutzerdefinierten Konfigurationen, während /etc/gitea die Hauptkonfigurationsdatei app.ini beherbergt. Diese Trennung erleichtert spätere Backups und Updates erheblich.

Damit Gitea als Systemdienst automatisch beim Booten startet, wird eine systemd-Service-Datei erstellt. Diese wird unter /etc/systemd/system/gitea.service abgelegt und enthält folgende Konfiguration:

[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target
Wants=network.target

[Service]
RestartSec=2s
Type=simple
User=gitea
Group=gitea
WorkingDirectory=/var/lib/gitea
ExecStart=/usr/local/bin/gitea web --config /etc/gitea/app.ini
Restart=always
Environment=USER=gitea HOME=/var/lib/gitea

[Install]
WantedBy=multi-user.target

Nach dem Speichern der Datei wird der Dienst aktiviert und gestartet:

sudo systemctl daemon-reload
sudo systemctl enable gitea
sudo systemctl start gitea
sudo systemctl status gitea

Wenn der Dienst erfolgreich startet, ist Gitea zunächst unter http://IHRE-IP:3000 erreichbar. Der Standardport 3000 sollte in der Produktion durch einen Reverse-Proxy wie Nginx oder Caddy ersetzt werden, der gleichzeitig die SSL-Terminierung übernimmt.

Gitea Konfiguration: app.ini optimal einstellen

Die zentrale Konfigurationsdatei von Gitea ist app.ini, die sich unter /etc/gitea/app.ini befindet. Bei der Erstinstallation über das Webinterface wird diese Datei automatisch generiert. Für eine produktive Umgebung empfiehlt es sich jedoch, die wichtigsten Parameter manuell anzupassen, um Sicherheit und Performance zu optimieren.

Ein vollständiges Grundgerüst der app.ini könnte wie folgt aussehen:

APP_NAME = Mein Gitea Server
RUN_USER = gitea
RUN_MODE = prod
WORK_PATH = /var/lib/gitea

[server]
DOMAIN = git.example.de
SSH_DOMAIN = git.example.de
HTTP_PORT = 3000
ROOT_URL = https://git.example.de/
DISABLE_SSH = false
SSH_PORT = 22
LFS_JWT_SECRET = ZUFALLSSCHLUESSEL
OFFLINE_MODE = false

[database]
DB_TYPE = sqlite3
PATH = /var/lib/gitea/data/gitea.db

[security]
INSTALL_LOCK = true
SECRET_KEY = ZUFALLSSCHLUESSEL
INTERNAL_TOKEN = ZUFALLSSCHLUESSEL

[service]
DISABLE_REGISTRATION = false
ENABLE_NOTIFY_MAIL = true

Besonders wichtig sind die SECRET_KEY und der INTERNAL_TOKEN, die als kryptografische Zufallsschlüssel generiert werden müssen. Diese können mit dem Befehl gitea generate secret SECRET_KEY erzeugt werden. Beide Schlüssel sollten mindestens 50 Zeichen lang sein und niemals öffentlich zugänglich gemacht werden.

Im Abschnitt [server] werden die Netzwerkeinstellungen definiert. Hier ist darauf zu achten, dass DOMAIN, SSH_DOMAIN und ROOT_URL konsistent sind. Andernfalls können Klon-URLs falsch generiert werden, was zu Verwirrung bei den Nutzern führt. Für deutsche Installationen sollte zudem LANGUAGE = de-DE gesetzt werden, um die Benutzeroberfläche in deutscher Sprache anzuzeigen.

Im Block [service] lässt sich die Registrierung neuer Nutzer steuern. Für interne Unternehmensinstallationen empfiehlt sich DISABLE_REGISTRATION = true, sodass neue Konten nur durch Administratoren angelegt werden können. Für öffentliche Gitea-Instanzen kann die Registrierung aktiviert bleiben, optional mit E-Mail-Bestätigung über ENABLE_NOTIFY_MAIL = true.

Die app.ini sollte nach jeder Änderung neu geladen werden, was am einfachsten durch einen Neustart des Dienstes erfolgt:

sudo systemctl restart gitea
sudo journalctl -u gitea -n 50

SSL/TLS-Verschlüsselung mit Let's Encrypt einrichten

Eine unverschlüsselte Gitea-Instanz ist in der heutigen Zeit ein absolutes No-Go, da sämtliche Daten – inklusive Passwörter, Quellcode und persönlicher Informationen – im Klartext über das Internet übertragen würden. Die einfachste und kostengünstigste Methode, um SSL-Verschlüsselung zu implementieren, ist die Nutzung von Let's Encrypt, das kostenlose Zertifikate mit automatischer Verlängerung bereitstellt.

Zunächst wird Nginx als Reverse-Proxy installiert, der die SSL-Terminierung übernimmt. Nginx wird dabei vor dem Gitea-Server (Port 3000) geschaltet und leitet alle Anfragen transparent weiter. Die Installation erfolgt unter Ubuntu mit apt install -y nginx certbot python3-certbot-nginx.

Die Nginx-Konfiguration für Gitea wird unter /etc/nginx/sites-available/gitea abgelegt und über einen symbolischen Link in sites-enabled aktiviert:

server {
    listen 80;
    server_name git.example.de;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name git.example.de;

    client_max_body_size 512M;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Der Parameter client_max_body_size 512M ist besonders wichtig, da Gitea auch für größere Uploads konfiguriert sein sollte. Standardmäßig erlaubt Nginx nur 1 MB pro Request, was das Pushen größerer Repositories verhindern würde. Nach der Aktivierung der Konfiguration mit ln -s /etc/nginx/sites-available/gitea /etc/nginx/sites-enabled/ und einem Neustart von Nginx kann das Let's-Encrypt-Zertifikat angefordert werden.

sudo certbot --nginx -d git.example.de
sudo systemctl reload nginx

Certbot passt die Nginx-Konfiguration automatisch an und ergänzt die SSL-spezifischen Direktiven. Das Zertifikat ist zunächst 90 Tage gültig, wird aber durch einen systemd-Timer automatisch alle 60 Tage erneuert. Mit certbot renew --dry-run lässt sich der Erneuerungsprozess testen. Für maximale Sicherheit empfiehlt sich die Aktivierung des HSTS-Headers, der Browser zwingt, die Verbindung in Zukunft immer über HTTPS aufzubauen.

Nach Abschluss dieser Schritte ist Gitea über https://git.example.de erreichbar und alle Daten werden verschlüsselt übertragen. Die SSL-Konfiguration kann anschließend mit Online-Tools wie SSL Labs (ssllabs.com/ssltest) überprüft und bei Bedarf weiter optimiert werden.

Backup und Wiederherstellung von Gitea-Daten

Ein regelmäßiges Backup ist für jede produktive Gitea-Instanz unerlässlich. Gitea bietet ein eingebautes Backup-Tool, das mit dem Befehl gitea dump aufgerufen werden kann. Dieses erstellt ein vollständiges Archiv, das alle Repositories, Datenbankinhalte, Konfigurationen, Avatare und Anhänge enthält. Der Standardbefehl lautet:

sudo -u gitea /usr/local/bin/gitea dump -c /etc/gitea/app.ini

Das resultierende ZIP-Archiv enthält alle relevanten Daten und kann bei Bedarf auf einem anderen Server wiederhergestellt werden. Für automatisierte tägliche Backups empfiehlt sich die Einrichtung eines Cronjobs, der das Backup erstellt, komprimiert und auf einen externen Speicher kopiert. Ein entsprechendes Skript könnte wie folgt aussehen:

#!/bin/bash
BACKUP_DIR="/var/backups/gitea"
DATE=$(date +%Y-%m-%d)
sudo -u gitea /usr/local/bin/gitea dump -c /etc/gitea/app.ini -t /tmp/gitea-dump
mv /tmp/gitea-dump/*.zip $BACKUP_DIR/gitea-backup-$DATE.zip
find $BACKUP_DIR -name "gitea-backup-*.zip" -mtime +14 -delete

Die Aufbewahrungsdauer von 14 Tagen ist ein guter Kompromiss zwischen Speicherplatzverbrauch und Wiederherstellungsmöglichkeit. Für kritische Produktionsumgebungen empfiehlt sich zusätzlich die Speicherung der Backups auf einem externen Speicher wie Amazon S3, Hetzner Storage Box oder einem zweiten VPS an einem anderen Standort. Das 3-2-1-Backup-Prinzip (3 Kopien, 2 verschiedene Medien, 1 externe Lagerung) hat sich in der Praxis bewährt.

Die Wiederherstellung eines Backups erfolgt mit dem Befehl gitea restore. Vor der Wiederherstellung sollte unbedingt ein aktueller Stand der bestehenden Installation gesichert werden, da die Wiederherstellung die existierenden Daten überschreibt. Der Wiederherstellungsbefehl lautet:

sudo -u gitea /usr/local/bin/gitea restore -c /etc/gitea/app.ini /path/to/gitea-backup.zip

Nach der Wiederherstellung empfiehlt sich ein Neustart des Gitea-Dienstes und eine vollständige Funktionsprüfung. Insbesondere sollten die SSH-Verbindung, die Weboberfläche, das Klonen von Repositories und der Login mit einem bestehenden Benutzerkonto getestet werden. Ein regelmäßig getestetes Backup ist mehr wert als zehn ungetestete Backups, die im Ernstfall nicht funktionieren.

Gitea Actions: CI/CD-Pipelines direkt im Repository

Eine der bemerkenswertesten Funktionen von Gitea sind die integrierten Gitea Actions, die seit Version 1.19 verfügbar sind und vollständig mit der GitHub-Actions-Syntax kompatibel sind. Damit können Entwickler CI/CD-Pipelines direkt im Repository definieren, ohne auf externe Dienste wie Jenkins, GitLab CI oder Travis CI angewiesen zu sein. Dies spart nicht nur Lizenzkosten, sondern vereinfacht auch die gesamte Entwicklungspipeline erheblich.

Die Konfiguration einer Action erfolgt über YAML-Dateien im Verzeichnis .gitea/workflows/ eines Repositories. Eine typische Workflow-Definition für das Bauen und Testen einer Node.js-Anwendung könnte wie folgt aussehen:

name: Build and Test
on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test
      - name: Build application
        run: npm run build

Damit Gitea Actions ausgeführt werden können, ist ein zusätzlicher Service namens act_runner erforderlich, der die Workflows tatsächlich abarbeitet. Der Runner kann auf dem gleichen VPS wie Gitea oder auf einem separaten Server installiert werden. Für die meisten Anwendungsfälle ist die Installation auf dem gleichen Server ausreichend, wobei auf eine ausreichende Ressourcenverfügbarkeit geachtet werden sollte.

Die Registrierung des Runners erfolgt über die Gitea-Weboberfläche unter Site Administration > Actions > Runners. Nach der Generierung eines Registrierungstokens wird der Runner mit folgendem Befehl initialisiert:

wget -O act_runner https://dl.gitea.com/act_runner/0.2.10/act_runner-0.2.10-linux-amd64
chmod +x act_runner
./act_runner register --instance https://git.example.de --token REGISTRATIONSTOKEN --name mein-runner
./act_runner daemon

Für eine persistente Installation empfiehlt sich auch hier die Einrichtung als systemd-Dienst. Mit Gitea Actions lassen sich komplexe Pipelines realisieren, die das Bauen, Testen und Deployen von Anwendungen vollständig automatisieren. Die enge Integration in das Gitea-Ökosystem macht Actions zu einem mächtigen Werkzeug für DevOps-Teams.

Sicherheits-Härtung und Best Practices für Gitea

Die Sicherheit einer selbstgehosteten Gitea-Instanz sollte oberste Priorität haben, da der Server sensible Quellcodes und möglicherweise geschäftskritische Daten enthält. Neben den bereits erwähnten Maßnahmen wie Firewall, Fail2Ban und SSL gibt es weitere Best Practices, die unbedingt beachtet werden sollten.

Eine der wichtigsten Maßnahmen ist die Aktivierung der Zwei-Faktor-Authentifizierung (2FA). Gitea unterstützt sowohl TOTP-basierte Authenticator-Apps als auch Hardware-Sicherheitsschlüssel (WebAuthn/FIDO2). Administratoren sollten 2FA nicht nur für sich selbst aktivieren, sondern auch für alle Nutzer verpflichtend vorgeben. Diese Einstellung erfolgt unter Site Administration > Security.

Regelmäßige Updates sind ein weiterer kritischer Faktor für die Sicherheit. Gitea veröffentlicht im monatlichen Rhythmus neue Versionen, die Sicherheitslücken schließen und neue Funktionen einführen. Updates können einfach durch das Ersetzen des Binarys und einen Neustart des Dienstes durchgeführt werden:

wget -O gitea https://dl.gitea.com/gitea/1.22.1/gitea-1.22.1-linux-amd64
chmod +x gitea
sudo systemctl restart gitea

Die app.ini sollte mit restriktiven Dateiberechtigungen geschützt werden, da sie kryptografische Schlüssel enthält. Empfohlen werden die Berechtigungen 640 mit dem Besitzer root:gitea, sodass nur Root und der Gitea-Benutzer die Datei lesen können:

sudo chown root:gitea /etc/gitea/app.ini
sudo chmod 640 /etc/gitea/app.ini

Für Unternehmen empfiehlt sich zudem die Integration in ein zentrales Identity-Management über LDAP oder SAML. Damit können Mitarbeiter ihre bestehenden Firmenzugangsdaten verwenden, und das On- bzw. Offboarding wird erheblich vereinfacht. Gitea unterstützt eine Vielzahl von Identity-Providern, darunter Active Directory, FreeIPA, Keycloak und Auth0.

Abschließend sollte ein Monitoring-System eingerichtet werden, das die Verfügbarkeit und Performance der Gitea-Instanz überwacht. Tools wie Prometheus in Kombination mit Grafana oder schlanke Lösungen wie UptimeRobot können frühzeitig auf Probleme hinweisen und ermöglichen eine proaktive Wartung. Ein regelmäßiges Audit der Zugriffslogs unter Site Administration > Logs hilft zudem, verdächtige Aktivitäten frühzeitig zu erkennen.

Migration von GitHub, GitLab oder Bitbucket zu Gitea

Ein häufiger Anwendungsfall ist die Migration bestehender Repositories von kommerziellen Plattformen zu einer selbstgehosteten Gitea-Instanz. Gitea bietet hierfür eine eingebaute Migrationsfunktion, die nahezu alle relevanten Plattformen unterstützt. Die Migration kann bequem über die Weboberfläche unter + > Neue Migration gestartet werden, ohne dass Tools auf der Kommandozeile erforderlich sind.

Bei der Migration von GitHub können sowohl öffentliche als auch private Repositories übertragen werden. Voraussetzung ist ein persönlicher Zugriffstoken (Personal Access Token), der auf der Quellplattform generiert werden muss. Für die Übertragung von Issues, Pull Requests, Wikis, Labels und Milestones wird zusätzlich ein Token mit erweiterten Berechtigungen benötigt, was Gitea im Migrationsassistenten transparent kommuniziert.

Die folgende Tabelle zeigt die unterstützten Migrationsquellen und die jeweils übertragenen Daten:

QuelleRepositoryIssuesPull RequestsWikisReleasesLabels
GitHubJaJaJaJaJaJa
GitLabJaJaJaJaJaJa
GiteaJaJaJaJaJaJa
BitbucketJaJaJaJaNeinJa
OneDevJaJaJaJaJaJa

Für sehr große Migrationen mit Hunderten von Repositories empfiehlt sich die Nutzung der Kommandozeile bzw. der REST-API. Gitea stellt hierfür den Befehl gitea admin auth-ldap und verschiedene API-Endpunkte zur Verfügung, die sich auch in Skripte einbinden lassen. Ein typisches Migrationsskript könnte mit curl und der Gitea-API arbeiten, um eine Liste von Repositories automatisch zu übertragen.

Nach der technischen Migration sollten die Team-Mitglieder über die neue Plattform informiert und die lokalen Git-Konfigurationen angepasst werden. Mit dem Befehl git remote set-url origin https://git.example.de/USER/REPO.git lässt sich die Remote-URL in den lokalen Klons aktualisieren. Eine durchdachte Kommunikation und eine mögliche Übergangsphase, in der beide Plattformen parallel betrieben werden, erleichtern den Umstieg erheblich.

Gitea Performance-Tuning für große Installationen

Während Gitea in der Standardkonfiguration für die meisten Anwendungsfälle ausreichend performant ist, können bei sehr großen Installationen mit Tausenden von Repositories und Hunderten von Nutzern einige Optimierungen vorgenommen werden. Diese betreffen vor allem die Datenbank, das Caching und die Konfiguration der Worker-Prozesse.

Der Wechsel von SQLite zu PostgreSQL ist eine der wichtigsten Optimierungsmaßnahmen. PostgreSQL bietet eine deutlich bessere Performance bei vielen gleichzeitigen Schreibzugriffen und ermöglicht fortschrittliche Funktionen wie Replikation und Partitionierung. Für eine Migration von SQLite zu PostgreSQL kann das eingebaute Backup-Tool in Kombination mit einer neuen Datenbankinstanz verwendet werden.

Die Optimierung der PostgreSQL-Konfiguration hat erheblichen Einfluss auf die Performance. Wichtige Parameter sind shared_buffers, work_mem und effective_cache_size. Für einen Server mit 4 GB RAM empfehlen sich folgende Werte:

shared_buffers = 1GB
work_mem = 64MB
effective_cache_size = 3GB
maintenance_work_mem = 256MB

Im Abschnitt [performance] der app.ini können weitere Parameter angepasst werden. MAX_CONCURRENT_REQUESTS steuert die maximale Anzahl gleichzeitiger HTTP-Requests, während WORKERS die Anzahl der Worker-Prozesse definiert. Als Faustregel gilt: WORKERS = Anzahl CPU-Kerne. Bei 4 CPU-Kernen wäre also WORKERS = 4 optimal.

Das Caching kann durch die Nutzung von Redis erheblich beschleunigt werden. Redis speichert Session-Daten und Caches im Arbeitsspeicher und reduziert damit die Datenbanklast deutlich. Die Konfiguration in der app.ini erfolgt über den Abschnitt [cache]:

[cache]
ENABLED = true
ADAPTER = redis
HOST = 127.0.0.1:6379

Schließlich sollte regelmäßig die Performance überwacht werden, um Engpässe frühzeitig zu erkennen. Tools wie htop, iotop und pg_stat_activity liefern wertvolle Einblicke in die Ressourcennutzung. Bei anhaltender hoher Last empfiehlt sich eine Skalierung auf mehrere Server, wobei die Gitea-Datenbank auf einem dedizierten Server ausgelagert werden kann.

Fazit: Gitea als zukunftssichere Git-Hosting-Lösung 2026

Gitea hat sich im Jahr 2026 als eine der besten Lösungen für selbstgehostetes Git-Management etabliert. Die Kombination aus geringem Ressourcenverbrauch, umfangreicher Funktionalität, aktiver Community und vollständiger Open-Source-Lizenz macht Gitea zur idealen Wahl für Entwickler, Teams und Unternehmen jeder Größe. Die Plattform bietet alle Funktionen, die von kommerziellen Alternativen bekannt sind, ohne dabei Kompromisse bei der Datenhoheit oder dem Datenschutz einzugehen.

Die Installation auf einem VPS ist unkompliziert und in weniger als einer Stunde abgeschlossen. Mit den hier beschriebenen Schritten – von der Vorbereitung des Servers über die Installation und SSL-Konfiguration bis hin zu Backup-Strategien und Performance-Tuning – steht einer produktiven Nutzung nichts im Wege. Die Gitea-Community ist aktiv und hilfsbereit, und die Dokumentation auf docs.gitea.com ist vorbildlich strukturiert.

Wer auf der Suche nach einer zukunftssicheren, kostengünstigen und DSGVO-konformen Alternative zu GitHub oder GitLab ist, sollte Gitea definitiv eine Chance geben. Mit Gitea Actions steht zudem eine moderne CI/CD-Plattform zur Verfügung, die keine Wünsche offen lässt. Die Zukunft der Softwareentwicklung ist dezentral, und Gitea ist ein wichtiger Baustein auf diesem Weg.

Bei hostazar.com bieten wir maßgeschneiderte VPS-Lösungen an, die optimal für den Betrieb von Gitea geeignet sind. Unsere Server stehen in deutschen Rechenzentren, garantieren DSGVO-Konformität und bieten eine ausgezeichnete Performance. Kontaktieren Sie uns gerne für eine individuelle Beratung zu Ihrer Gitea-Installation.

Docker Compose auf dem VPS: Webserver, Datenbank & Reverse Proxy richtig betreiben
DevOps 02. June 2026 10 Min

Docker Compose auf dem VPS: Webserver, Datenbank & Reverse Proxy richtig betreiben

Praxisnaher Guide für Docker Compose auf dem VPS: Webserver, Datenbank, Reverse Proxy, TLS, Backups, Updates und Sicherheit richtig planen und betreiben.

Weiterlesen →

📖 Ähnliche Artikel