💡 Hinweis: Dieses Tutorial setzt voraus, dass du einen normalen Benutzer mit sudo-Rechten verwendest — wie im Tutorial Debian 13 Server absichern beschrieben.

1. Einleitung — Was ist Gitea? Warum Self-Hosted Git?

Gitea ist eine leichtgewichtige, selbst gehostete Git-Plattform, geschrieben in Go. Sie bietet eine GitHub-ähnliche Oberfläche mit Issues, Pull Requests, Code-Review, Wikis und seit Version 1.19 sogar integrierte CI/CD-Pipelines (Gitea Actions). Im Vergleich zu GitLab ist Gitea deutlich ressourcenschonender — ein Server mit 1 GB RAM reicht für kleine Teams völlig aus.

Warum Self-Hosted?

  • Volle Kontrolle: Dein Code bleibt auf deinem Server. Keine Abhängigkeit von GitHub, GitLab oder Bitbucket.
  • Datenschutz: Besonders relevant für europäische Unternehmen und DSGVO-Compliance.
  • Keine Limitierungen: Keine Beschränkungen bei privaten Repos, Nutzern oder CI-Minuten.
  • Kostenlos & Open Source: Gitea steht unter der MIT-Lizenz.
  • Leichtgewichtig: Im Gegensatz zu GitLab (das gerne 4+ GB RAM frisst) läuft Gitea mit minimalen Ressourcen.

In diesem Tutorial richten wir Gitea mit Docker Compose auf Debian 13 (Trixie) ein — inklusive Datenbank, Reverse Proxy mit SSL, SSH-Zugang, CI/CD und Backup-Strategie.

2. Voraussetzungen

Bevor wir starten, solltest du folgendes vorbereitet haben:

  • Debian 13 (Trixie) — frisch installiert oder bestehendes System
  • Docker & Docker Compose — Falls noch nicht installiert, folge Tutorial #4: Docker auf Debian 13 installieren
  • Nginx als Reverse Proxy — Grundlagen findest du in Tutorial #6: Nginx Reverse Proxy mit SSL
  • Eine Domain (z.B. git.example.com) mit DNS-A-Record auf deinen Server
  • Root-Zugang oder ein User mit sudo-Rechten
  • Certbot für Let’s Encrypt SSL-Zertifikate
# Schnellcheck: Ist Docker bereit?
docker --version
docker compose version

3. Gitea mit Docker Compose installieren

3.1 Projektverzeichnis anlegen

sudo mkdir -p /opt/gitea
cd /opt/gitea

3.2 Docker Compose Datei erstellen

Erstelle die Datei docker-compose.yml:

sudo nano /opt/gitea/docker-compose.yml

Inhalt (mit PostgreSQL als Datenbank — empfohlen für Produktivbetrieb):

services:
  gitea:
    image: gitea/gitea:latest
    container_name: gitea
    restart: unless-stopped
    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=DeinSicheresPasswort
    volumes:
      - ./data:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3000:3000"
      - "2222:22"
    depends_on:
      db:
        condition: service_healthy
    networks:
      - gitea-net

  db:
    image: postgres:16-alpine
    container_name: gitea-db
    restart: unless-stopped
    environment:
      - POSTGRES_USER=gitea
      - POSTGRES_PASSWORD=DeinSicheresPasswort
      - POSTGRES_DB=gitea
    volumes:
      - ./db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "gitea"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - gitea-net

networks:
  gitea-net:
    driver: bridge

💡 Hinweis: Ersetze DeinSicheresPasswort durch ein starkes Passwort. Nutze z.B. openssl rand -base64 32 um eines zu generieren.

3.3 Container starten

cd /opt/gitea
sudo docker compose up -d

Prüfe, ob alles läuft:

sudo docker compose ps

Du solltest zwei Container sehen — gitea und gitea-db — beide im Status Up.

4. Datenbank einrichten — SQLite vs MariaDB vs PostgreSQL

Gitea unterstützt mehrere Datenbanken. Hier ein Vergleich:

DatenbankVorteileNachteileEmpfehlung
SQLiteKein extra Container, einfachstes SetupNicht für mehrere gleichzeitige Zugriffe geeignetEinzelnutzer, kleine Projekte
PostgreSQLRobust, performant, beste Gitea-UnterstützungBraucht extra Container✅ Empfohlen für Produktion
MariaDB/MySQLWeit verbreitet, viele kennen esGelegentlich Charset-ProblemeWenn bereits vorhanden

Alternative: SQLite (minimales Setup)

Wenn du SQLite bevorzugst, vereinfache die docker-compose.yml:

services:
  gitea:
    image: gitea/gitea:latest
    container_name: gitea
    restart: unless-stopped
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__database__DB_TYPE=sqlite3
    volumes:
      - ./data:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3000:3000"
      - "2222:22"

Alternative: MariaDB

Ersetze den db-Service durch:

db:
    image: mariadb:11
    container_name: gitea-db
    restart: unless-stopped
    environment:
      - MYSQL_ROOT_PASSWORD=RootPasswort
      - MYSQL_DATABASE=gitea
      - MYSQL_USER=gitea
      - MYSQL_PASSWORD=DeinSicheresPasswort
    volumes:
      - ./db-data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - gitea-net

Und ändere die Gitea-Umgebungsvariablen entsprechend:

- GITEA__database__DB_TYPE=mysql
      - GITEA__database__HOST=db:3306

5. Erste Konfiguration (app.ini)

Nach dem ersten Start erzeugt Gitea automatisch die Konfigurationsdatei unter /opt/gitea/data/gitea/conf/app.ini. Du kannst sie anpassen:

sudo nano /opt/gitea/data/gitea/conf/app.ini

Wichtige Einstellungen:

[server]
DOMAIN           = git.example.com
SSH_DOMAIN       = git.example.com
ROOT_URL         = https://git.example.com/
HTTP_PORT        = 3000
SSH_PORT         = 2222
START_SSH_SERVER = true
LFS_START_SERVER = true

[service]
DISABLE_REGISTRATION       = false
REQUIRE_SIGNIN_VIEW        = false
REGISTER_EMAIL_CONFIRM     = false
ENABLE_NOTIFY_MAIL         = false
DEFAULT_KEEP_EMAIL_PRIVATE = true

[mailer]
ENABLED = false

[session]
PROVIDER = file

[log]
MODE      = console
LEVEL     = info
ROOT_PATH = /data/gitea/log

[security]
INSTALL_LOCK   = true
SECRET_KEY     = <wird automatisch generiert>
INTERNAL_TOKEN = <wird automatisch generiert>

[repository]
DEFAULT_BRANCH = main
DEFAULT_PRIVATE = last

[actions]
ENABLED = true

⚠️ Wichtig: Nach Änderungen an der app.ini muss Gitea neu gestartet werden: sudo docker compose restart gitea

Umgebungsvariablen vs app.ini

Gitea erlaubt Konfiguration über beide Wege. Umgebungsvariablen im Format GITEA__SECTION__KEY überschreiben die app.ini-Werte. Für Docker-Setups sind Umgebungsvariablen oft praktischer, da sie die Compose-Datei als „Single Source of Truth“ machen.

6. Nginx Reverse Proxy + SSL einrichten

6.1 Nginx-Konfiguration erstellen

sudo nano /etc/nginx/sites-available/gitea

Inhalt:

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

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

    ssl_certificate     /etc/letsencrypt/live/git.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/git.example.com/privkey.pem;
    include             /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam         /etc/letsencrypt/ssl-dhparams.pem;

    client_max_body_size 100M;

    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;

        # WebSocket-Support (für Live-Updates)
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

6.2 Aktivieren & SSL-Zertifikat holen

# Seite aktivieren
sudo ln -s /etc/nginx/sites-available/gitea /etc/nginx/sites-enabled/

# Nginx-Syntax prüfen
sudo nginx -t

# Zuerst SSL-Zertifikat holen (dafür brauchen wir kurz die HTTP-Weiterleitung)
# Temporär die HTTPS-Sektion auskommentieren und nur Port 80 aktiv lassen
sudo certbot --nginx -d git.example.com

# Nginx neu laden
sudo systemctl reload nginx

✅ Tipp: Certbot konfiguriert in der Regel automatisch die SSL-Einstellungen in der Nginx-Config. Prüfe nach dem Certbot-Lauf, ob die Pfade korrekt gesetzt wurden.

6.3 Firewall-Regeln

# Falls UFW aktiv ist:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 2222/tcp   # Für SSH-Git-Zugang

7. Erster Login & Admin-Account

Öffne im Browser https://git.example.com. Beim ersten Aufruf erscheint der Installations-Wizard — sofern INSTALL_LOCK nicht bereits auf true steht.

Über den Wizard

  1. Datenbankeinstellungen: Sollten bereits korrekt ausgefüllt sein (aus den Umgebungsvariablen)
  2. Allgemeine Einstellungen: Seitentitel, Domain und ROOT_URL prüfen
  3. Administrator-Konto: Lege hier deinen Admin-User an

Admin per Kommandozeile anlegen

Alternativ (oder wenn der Wizard übersprungen wurde):

sudo docker exec -it gitea gitea admin user create \
  --username admin \
  --password DeinAdminPasswort \
  --email admin@example.com \
  --admin

⚠️ Sicherheitshinweis: Ändere das Admin-Passwort sofort nach dem ersten Login. Nutze ein Passwort mit mindestens 16 Zeichen.

8. Repositories anlegen & nutzen

8.1 Neues Repository erstellen

  1. Klicke oben rechts auf + → Neues Repository
  2. Wähle einen Namen, optional eine Beschreibung
  3. Entscheide: Öffentlich oder Privat
  4. Optional: README, .gitignore und Lizenz hinzufügen
  5. Klicke auf Repository erstellen

8.2 Lokal klonen und arbeiten

# Über HTTPS
git clone https://git.example.com/username/mein-projekt.git

# Über SSH (siehe Abschnitt 9)
git clone ssh://git@git.example.com:2222/username/mein-projekt.git

# Arbeiten
cd mein-projekt
echo "# Mein Projekt" > README.md
git add .
git commit -m "Initial commit"
git push origin main

8.3 Bestehendes Repository hinzufügen

cd bestehendes-projekt
git remote add origin https://git.example.com/username/mein-projekt.git
git push -u origin main

8.4 Nützliche Repository-Features

  • Issues: Bug-Tracking und Feature-Requests
  • Pull Requests: Code-Review-Workflow
  • Wiki: Projektdokumentation direkt im Repo
  • Releases: Versionierte Veröffentlichungen mit Binaries
  • Labels & Milestones: Projektmanagement

9. SSH-Zugang für Git einrichten

9.1 SSH-Schlüssel generieren (auf deinem lokalen Rechner)

# Ed25519 (empfohlen)
ssh-keygen -t ed25519 -C "deine@email.com"

# Oder RSA (4096 Bit)
ssh-keygen -t rsa -b 4096 -C "deine@email.com"

9.2 Öffentlichen Schlüssel in Gitea hinterlegen

  1. Kopiere deinen Public Key: cat ~/.ssh/id_ed25519.pub
  2. In Gitea: Einstellungen → SSH/GPG-Schlüssel → SSH-Schlüssel hinzufügen
  3. Füge den Schlüssel ein und speichere

9.3 SSH-Config anpassen

Da Gitea auf Port 2222 lauscht, ergänze deine ~/.ssh/config:

Host git.example.com
    HostName git.example.com
    Port 2222
    User git
    IdentityFile ~/.ssh/id_ed25519

Damit kannst du elegant klonen ohne Port-Angabe:

git clone git@git.example.com:username/mein-projekt.git

9.4 Verbindung testen

ssh -T git@git.example.com -p 2222

Erwartete Ausgabe: Hi username! You've successfully authenticated...

💡 Tipp: Falls du den SSH-Port 22 auf dem Host direkt an Gitea durchreichen willst (statt 2222), gibt es einen SSH-Passthrough-Ansatz. Das ist komplexer einzurichten, aber eleganter für Nutzer. Siehe die Gitea-Dokumentation.

10. CI/CD mit Gitea Actions

Seit Version 1.19 bietet Gitea eine eingebaute CI/CD-Lösung, die kompatibel mit GitHub Actions Workflow-Syntax ist.

10.1 Actions aktivieren

In der app.ini (sollte bereits gesetzt sein):

[actions]
ENABLED = true

10.2 Gitea Actions Runner installieren

Der Runner führt die eigentlichen Jobs aus. Am einfachsten per Docker:

# Runner-Token generieren (in Gitea: Site Administration → Runners → Create new Runner)
# Oder per CLI:
sudo docker exec -it gitea gitea actions generate-runner-token

Ergänze die docker-compose.yml um den Runner-Service:

runner:
    image: gitea/act_runner:latest
    container_name: gitea-runner
    restart: unless-stopped
    environment:
      - GITEA_INSTANCE_URL=http://gitea:3000
      - GITEA_RUNNER_REGISTRATION_TOKEN=DeinRunnerToken
      - GITEA_RUNNER_NAME=default-runner
    volumes:
      - ./runner-data:/data
      - /var/run/docker.sock:/var/run/docker.sock
    depends_on:
      - gitea
    networks:
      - gitea-net

⚠️ Sicherheitshinweis: Der Runner braucht Zugriff auf den Docker Socket (/var/run/docker.sock). Das ist ein Sicherheitsrisiko, da Container mit Socket-Zugriff Root-Rechte auf dem Host erlangen können. Für Produktivumgebungen empfiehlt sich ein dedizierter Runner-Host oder rootless Docker.

10.3 Ersten Workflow erstellen

Erstelle in deinem Repository die Datei .gitea/workflows/ci.yml:

name: CI Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Run Tests
        run: |
          echo "Hello from Gitea Actions!"
          echo "Branch: ${{ github.ref }}"
          # Hier deine Tests einfügen

Nach dem Push siehst du den Workflow unter dem Tab Actions im Repository.

10.4 Praxisbeispiel: Docker-Image bauen

name: Build Docker Image

on:
  push:
    tags: ['v*']

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Login to Registry
        uses: docker/login-action@v3
        with:
          registry: git.example.com
          username: ${{ secrets.REGISTRY_USER }}
          password: ${{ secrets.REGISTRY_PASS }}

      - name: Build and Push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: git.example.com/${{ github.repository }}:${{ github.ref_name }}

11. Benutzer & Organisationen verwalten

11.1 Benutzer verwalten

Als Admin findest du die Benutzerverwaltung unter Site Administration → Benutzerkonten.

# Benutzer per CLI anlegen
sudo docker exec -it gitea gitea admin user create \
  --username neuer-user \
  --password SicheresPasswort \
  --email user@example.com

# Benutzer auflisten
sudo docker exec -it gitea gitea admin user list

11.2 Registrierung steuern

In der app.ini:

[service]
# Registrierung komplett deaktivieren
DISABLE_REGISTRATION = true

# Oder: Nur mit E-Mail-Bestätigung
DISABLE_REGISTRATION = false
REGISTER_EMAIL_CONFIRM = true

# Oder: Nur bestimmte Domains erlauben
ALLOWED_DOMAINS = example.com,firma.de

11.3 Organisationen nutzen

Organisationen sind ideal für Teams:

  1. Klicke auf + → Neue Organisation
  2. Vergib einen Namen und optional eine Beschreibung
  3. Erstelle Teams mit unterschiedlichen Berechtigungen:
    • Owners: Vollzugriff
    • Developers: Lesen & Schreiben auf Repos
    • Readers: Nur Lesezugriff
    • Lade Mitglieder in die jeweiligen Teams ein

12. Backups & Migration von GitHub/GitLab

12.1 Backup erstellen

# Gitea-eigenes Backup (erstellt ein ZIP-Archiv)
sudo docker exec -it gitea gitea dump -c /data/gitea/conf/app.ini

# Das Archiv liegt im Container unter /data/
# Kopiere es heraus:
sudo docker cp gitea:/data/gitea-dump-*.zip /opt/gitea/backups/

12.2 Automatisiertes Backup per Cronjob

sudo nano /etc/cron.d/gitea-backup

Inhalt:

# Täglich um 3:00 Uhr Backup erstellen
0 3 * * * root docker exec gitea gitea dump -c /data/gitea/conf/app.ini && \
  docker cp gitea:/data/gitea-dump-$(date +\%s).zip /opt/gitea/backups/ && \
  find /opt/gitea/backups/ -name "gitea-dump-*.zip" -mtime +30 -delete

💡 Tipp: Sichere zusätzlich die Docker-Volumes direkt: sudo tar czf gitea-data-backup.tar.gz /opt/gitea/data /opt/gitea/db-data

12.3 Backup wiederherstellen

# Container stoppen
sudo docker compose down

# Daten wiederherstellen
sudo docker exec -it gitea gitea restore --file /data/gitea-dump-XXXXX.zip

# Oder manuell: Volume-Daten aus Tar-Backup zurückspielen
sudo tar xzf gitea-data-backup.tar.gz -C /

# Container starten
sudo docker compose up -d

12.4 Migration von GitHub

Gitea hat eine eingebaute Migrationsfunktion:

  1. Klicke auf + → Neue Migration
  2. Wähle GitHub als Quelle
  3. Gib die Repository-URL ein (z.B. https://github.com/user/repo)
  4. Optional: GitHub Personal Access Token für private Repos
  5. Wähle, was migriert werden soll:
    • ☑️ Issues
    • ☑️ Pull Requests
    • ☑️ Labels
    • ☑️ Milestones
    • ☑️ Releases
    • ☑️ Wiki
    • Klicke auf Repository migrieren

12.5 Migration von GitLab

Gleiches Prinzip — wähle GitLab als Quelle und gib einen GitLab Access Token ein. Gitea unterstützt auch Migration von Bitbucket, Gogs und anderen Gitea-Instanzen.

12.6 Bulk-Migration per API

# Alle GitHub-Repos eines Users migrieren (Beispiel-Script)
for repo in $(gh repo list --json name -q '.[].name'); do
  curl -X POST "https://git.example.com/api/v1/repos/migrate" \
    -H "Authorization: token DEIN_GITEA_TOKEN" \
    -H "Content-Type: application/json" \
    -d "{
      \"clone_addr\": \"https://github.com/username/$repo\",
      \"repo_name\": \"$repo\",
      \"service\": \"github\",
      \"auth_token\": \"DEIN_GITHUB_TOKEN\",
      \"mirror\": false,
      \"issues\": true,
      \"labels\": true,
      \"milestones\": true,
      \"releases\": true,
      \"wiki\": true
    }"
done

13. Updates & Wartung

13.1 Gitea aktualisieren

cd /opt/gitea

# Neuestes Image ziehen
sudo docker compose pull

# Container mit neuem Image neu starten
sudo docker compose up -d

# Logs prüfen (auf Migrations-Meldungen achten)
sudo docker compose logs -f gitea

⚠️ Vor jedem Update: Erstelle ein Backup! Datenbank-Migrationen können nicht rückgängig gemacht werden.

13.2 Pinned Versions verwenden

Für Produktion empfiehlt sich eine feste Version statt latest:

# Statt:
image: gitea/gitea:latest

# Besser:
image: gitea/gitea:1.22

13.3 Logs & Monitoring

# Live-Logs anzeigen
sudo docker compose logs -f gitea

# Festplattennutzung prüfen
du -sh /opt/gitea/data /opt/gitea/db-data

# Container-Ressourcen überwachen
docker stats gitea gitea-db

13.4 Datenbank-Wartung

# PostgreSQL: VACUUM (Speicher freigeben)
sudo docker exec -it gitea-db psql -U gitea -c "VACUUM ANALYZE;"

# Gitea: Interne Konsistenzprüfung
sudo docker exec -it gitea gitea doctor check

14. Zusammenfassung & Checkliste

Hier deine Checkliste für eine vollständige Gitea-Installation:

SchrittStatusBeschreibung
1☐Docker & Docker Compose installiert
2☐Projektverzeichnis /opt/gitea angelegt
3☐docker-compose.yml erstellt & angepasst
4☐Container gestartet & laufen
5☐app.ini konfiguriert (Domain, URL, SSH)
6☐Nginx Reverse Proxy eingerichtet
7☐SSL-Zertifikat via Let’s Encrypt
8☐Admin-Account erstellt
9☐SSH-Zugang konfiguriert & getestet
10☐Gitea Actions Runner eingerichtet
11☐Registrierungseinstellungen geprüft
12☐Backup-Cronjob eingerichtet
13☐Firewall-Regeln gesetzt (80, 443, 2222)

15. Troubleshooting

Problem: Gitea startet nicht

# Logs prüfen
sudo docker compose logs gitea

# Häufige Ursachen:
# - Datenbank nicht erreichbar → docker compose logs db
# - Port bereits belegt → lsof -i :3000
# - Berechtigungsfehler → chown -R 1000:1000 /opt/gitea/data

Problem: 502 Bad Gateway im Browser

  • Läuft der Gitea-Container? docker compose ps
  • Ist Port 3000 erreichbar? curl -I http://127.0.0.1:3000
  • Nginx-Logs prüfen: tail -f /var/log/nginx/error.log

Problem: SSH-Verbindung wird abgelehnt

  • Port 2222 in der Firewall offen? sudo ufw status
  • SSH-Server in Gitea aktiv? Prüfe START_SSH_SERVER = true in app.ini
  • Richtiger Port im SSH-Befehl? ssh -T git@git.example.com -p 2222
  • SSH-Key korrekt hinterlegt? Unter Einstellungen → SSH-Schlüssel prüfen

Problem: Actions Runner verbindet sich nicht

  • Token korrekt? Generiere ggf. ein neues: docker exec -it gitea gitea actions generate-runner-token
  • Netzwerk korrekt? Runner muss Gitea über den internen Docker-Hostnamen erreichen (http://gitea:3000)
  • Runner-Logs: docker compose logs runner

Problem: Push wird abgelehnt (413 / Request Entity Too Large)

  • client_max_body_size in Nginx erhöhen (z.B. auf 500M für große Repos)
  • Für sehr große Dateien: Git LFS verwenden

Problem: Datenbank-Verbindungsfehler nach Update

# PostgreSQL-Version prüfen
sudo docker exec gitea-db psql --version

# Gitea-Doctor laufen lassen
sudo docker exec -it gitea gitea doctor check --all

16. Nächste Schritte

Deine Gitea-Instanz läuft — und jetzt? Hier sind Ideen, wie du sie weiter ausbauen kannst:

  • Container Registry: Gitea hat eine eingebaute Container Registry. Aktiviere sie in der app.ini unter [packages] und nutze sie als private Docker Registry.
  • OAuth2 / LDAP: Integriere externe Authentifizierung (GitHub, GitLab, Keycloak, Active Directory) unter Site Administration → Authentifizierungsquellen.
  • Webhooks: Verbinde Gitea mit externen Services (Discord, Slack, Mattermost, eigene APIs) für Benachrichtigungen bei Push, PR oder Issues.
  • Gitea Pages: Statische Websites direkt aus Repositories hosten (experimentelles Feature).
  • Mirror-Repositories: Halte automatische Spiegel von GitHub-Repos, die bei jedem Push synchronisiert werden.
  • Monitoring: Integriere Prometheus-Metriken (unter /metrics) in dein Monitoring-Setup (Grafana, etc.).
  • E-Mail-Benachrichtigungen: Konfiguriere SMTP in der app.ini, damit Nutzer über Issues, PRs und Mentions benachrichtigt werden.

Gitea entwickelt sich rasant weiter. Halte die offiziellen Release Notes im Auge und update regelmäßig — natürlich immer erst nach einem Backup! 😉

Dieses Tutorial ist Teil der Debian 13 Server-Reihe auf univastro.net. Fragen oder Probleme? Schreib einen Kommentar!