Was Gitea Actions sind
Gitea Actions ist die eingebaute CI/CD-Engine von Gitea. Du beschreibst deine Pipeline in einer YAML-Datei im Repository, und bei jedem Push oder Pull Request läuft sie automatisch los — kompiliert Code, führt Tests aus, baut Container-Images oder deployt auf einen Server. Das Besondere: Gitea Actions ist weitgehend GitHub-Actions-kompatibel. Die meisten Workflows von GitHub und ein großer Teil der Marketplace-Actions laufen mit minimalen Anpassungen direkt durch. Wer also bereits GitHub-Workflows kennt, findet sich sofort zurecht.
Der Unterschied zu GitHub: Alles läuft auf deiner eigenen Instanz, deine Quelltexte und Secrets verlassen deinen Server nicht. Du brauchst nur zwei Bausteine — eine Gitea-Instanz mit aktivierten Actions und mindestens einen Runner, der die Jobs tatsächlich ausführt.
Actions aktivieren
In neueren Gitea-Versionen sind Actions standardmäßig aktiv. Falls nicht, trägst du in der app.ini unter dem Abschnitt [actions] die Zeile ENABLED = true ein und startest Gitea neu. Anschließend kannst du Actions pro Repository unter Einstellungen → Actions ein- oder ausschalten. Ohne registrierten Runner passiert allerdings noch nichts — Workflows werden zwar erkannt, bleiben aber in der Warteschlange hängen.
Einen Runner registrieren
Der Runner ist ein eigenes Programm namens act_runner, das Jobs von Gitea abholt und ausführt. Du installierst ihn am besten auf einem separaten Server oder in einem Container, damit Builds die Gitea-Instanz nicht ausbremsen. Lade die passende Binary herunter und mache sie ausführbar:
- Registrierungs-Token holst du in Gitea unter Einstellungen → Actions → Runner → Registrierungstoken erstellen (auf Repo-, Organisations- oder Instanz-Ebene).
- Danach registrierst du den Runner mit
./act_runner register --no-interactive --instance https://deine-gitea-url --token DEIN_TOKEN. - Gestartet wird er mit
./act_runner daemon. Sobald er läuft, taucht er in Gitea als idle auf und nimmt Jobs an.
Praktisch ist der Betrieb mit Docker, weil der Runner jeden Job in einem sauberen Container ausführt. Achte darauf, dass auf dem Runner-Host Docker verfügbar ist — sonst können containerbasierte Jobs nicht starten. Bei der Registrierung vergibst du außerdem Labels wie ubuntu-latest, über die deine Workflows den passenden Runner auswählen.
Den ersten Workflow anlegen
Workflows liegen im Repository im Ordner .gitea/workflows/ als YAML-Dateien. Der Name der Datei ist frei wählbar, etwa ci.yaml. Gitea liest beim Push automatisch alle Dateien aus diesem Verzeichnis ein. Eine minimale Pipeline, die bei jedem Push auf den main-Branch läuft, sieht so aus:
name: CI
on:
push:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: echo "Build startet"
Der Schlüssel runs-on verweist auf ein Runner-Label. actions/checkout@v4 klont dein Repository in den Job, danach kannst du beliebige Shell-Befehle über run ausführen.
Eine realistischere Beispiel-Pipeline
Für ein Node.js-Projekt, das Abhängigkeiten installiert und Tests fahren soll, erweiterst du die steps entsprechend:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npm ci
- run: npm test
Schlägt ein Schritt fehl (Exit-Code ungleich 0), bricht der Job ab und Gitea markiert den Lauf rot. Den Verlauf jedes Durchgangs siehst du im Repository im Reiter Actions mit vollständigem Log pro Schritt — ideal zum Debuggen, wenn ein Test bricht.
Secrets sicher hinterlegen
Zugangsdaten wie API-Tokens, SSH-Schlüssel oder Registry-Passwörter gehören niemals in die YAML-Datei. Stattdessen legst du sie in Gitea unter Einstellungen → Actions → Secrets ab — auf Repo- oder Organisationsebene. Im Workflow greifst du dann über den Kontext ${{ secrets.NAME }} darauf zu:
- run: ./deploy.sh
env:
DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}
Die Werte werden verschlüsselt gespeichert und im Log automatisch maskiert. Ein zusätzliches GITHUB_TOKEN beziehungsweise GITEA_TOKEN steht in jedem Job automatisch bereit, etwa um Releases zu erstellen oder das eigene Repository zu pushen. Vergib hier nur die nötigsten Rechte und nutze für externe Server eigene, klar benannte Deploy-Schlüssel statt deiner persönlichen Zugangsdaten.
Mit Nytrix umsetzen
Wenn du keine eigene Gitea-Instanz aufsetzen und pflegen willst, bekommst du sie bei Nytrix fertig als Gitea-Produkt — aktuell in der Alpha-Phase für 3,99 EUR im Monat. Repositories, Issues, Pull Requests und Gitea Actions sind direkt dabei, ebenso der SSH-Zugriff über Port 2222 für Git-Operationen und Deploy-Keys. Reicht der Platz nicht, erweiterst du den Speicher in 10-GB-Schritten für je 1,85 EUR.
Wie bei allen Nytrix-Tarifen gilt: Prepaid per Guthaben, keine Mindestlaufzeit und keine Vertragsbindung — du lädst auf, buchst und kannst jederzeit wieder kündigen. Der Login läuft über Enjyn Auth (SSO) mit 2FA, und der DDoS-Schutz ist inklusive. Bezahlt wird über das Enjyn-PayNow-System per PayPal, Kreditkarte, Sofortüberweisung/GiroPay, Banküberweisung oder Bitcoin.
Den passenden Build-Runner kannst du auf einem eigenen vServer mit vollem Root-Zugriff betreiben — dank aktiviertem Docker-Nesting läuft act_runner dort sauber containerisiert. Build-Artefakte oder Backups deiner Repos sicherst du bei Bedarf auf den FTP Storage. Weitere Anleitungen rund um Self-Hosting findest du in unserem Blog.