Warum meinen eigenen Runner statt GitHub-gehosteter betreiben?

Drei echte Gründe: deine eigenen Abhängigkeiten und Toolchain eingebacken (kein Neuinstallieren bei jedem Lauf), Zugriff auf private Ressourcen wie eine interne Registry oder Datenbank, und Kontrolle über die Maschine — ihre Größe, ihre Caches, ihr Netzwerk. Wenn GitHub-gehostete Minuten und eine saubere Umgebung dir passen, bleib dabei. Hoste selbst, wenn du speziell einen dieser drei brauchst.

Ist es sicher, einen selbst gehosteten Runner zu nutzen?

Auf einem privaten Repo ja. Auf einem öffentlichen Repo nein — niemals. Ein Workflow führt beliebigen Code von demjenigen aus, der ihn auslöst, und auf einem öffentlichen Repo kann der Pull Request eines Fremden dessen Code auf deinem Runner ausführen. GitHubs eigene Docs sagen dasselbe. Halte selbst gehostete Runner auf privaten Repos, oder akzeptiere, dass du deine Maschine dem Internet übergibst.

Wie viel CPU und RAM braucht ein Runner?

Hängt völlig von deinem Build ab. Ein typischer Compile-und-Test-Job ist mit 2 Kernen und 4–8 GB bequem — Small oder Medium hier. Schwere Builds (große native Kompilierungen, große Docker-Images, speicherhungrige Test-Suites) wollen mehr, und du solltest auf deinen tatsächlichen Job dimensionieren, nicht auf eine Vermutung. Beobachte einen echten Lauf und du weißt es.

Kann ein Runner mehrere Repos handhaben?

Ein Runner kann bei einer Organisation registriert und von mehreren Repos aufgegriffen werden, standardmäßig ein Job zur Zeit. Für mehr Parallelität betreibe mehr Runner — jeder ist sein eigener systemd-Dienst. Halte sie nur alle auf privaten Repos.

Muss ich euch einen Ausweis geben?

Nein. E-Mail zur Registrierung, USDC oder USDT zum Bezahlen. Keine Dokumente, root in etwa einer Minute.

Einen selbst gehosteten GitHub-Actions-Runner auf einem VPS betreiben

GitHub-gehostete Runner sind ein guter Standard. Du hörst auf, sie zu brauchen, in dem Moment, in dem ein Build etwas will, das sie nicht haben — deine private Paket-Registry, eine bestimmte Toolchain-Version, die du müde bist, bei jedem Lauf neu zu installieren, eine Datenbank in deinem eigenen Netzwerk oder einfach mehr Kontrolle über die Maschine. Dann verdient ein selbst gehosteter Runner auf einem VPS seinen Unterhalt.

Dieser Leitfaden bringt einen richtig zum Laufen: installiert, registriert, unter systemd lebendig und — der Teil, den Leute falsch machen — sicher. Beginnen wir mit dem Letzten, denn das ist der Teil, der beißt.

Die eine Sicherheitsregel

Ein GitHub-Actions-Workflow führt beliebigen Code aus — was auch immer in der Workflow-Datei ist, und was auch immer dieser Code hereinzieht. Auf deinem eigenen Repo ist das dein Code, und es ist in Ordnung. Auf einem öffentlichen Repo kann ein Pull Request von einem Fremden dessen Code auf deinem Runner ausführen. Das ist kein Bug; so funktioniert CI. GitHubs eigene Dokumentation sagt klar: nutze keine selbst gehosteten Runner mit öffentlichen Repositories.

Die Regel ist also einfach und nicht verhandelbar: selbst gehostete Runner sind für private Repos. Wenn dein Repo öffentlich ist, nutze GitHub-gehostete Runner und mach weiter. Alles Folgende setzt ein privates Repo voraus.

Was ein Runner von der Maschine braucht

Es hängt vom Build ab, und du solltest auf deinen dimensionieren statt auf eine Zahl von einer Seite:

Ein typischer Compile-und-Test-Job — 2 Kerne und 4–8 GB sind bequem. Small (8 $, 4 vCPU / 4 GB) oder Medium (12 $, 6 vCPU / 6 GB) deckt die meisten davon.
Schwerere Builds — große native Kompilierungen, große Docker-Image-Builds, speicherhungrige Test-Suites — wollen mehr Spielraum. Beobachte einen echten Lauf (htop, während er baut) und dimensioniere auf das, was du tatsächlich siehst, nicht auf Hoffnung.

Festplatte zählt auch: Build-Caches, Docker-Layer und geklonte Repos summieren sich. Behalte es im Auge und prune.

1. Die Maschine vorbereiten

Erstelle einen Nicht-root-Benutzer für den Runner — GitHubs Installer weigert sich ohnehin, als root zu laufen, und du willst es so:

sudo adduser --disabled-password --gecos "" runner
sudo usermod -aG sudo runner   # nur wenn deine Builds wirklich sudo brauchen

Installiere, was auch immer deine Builds brauchen — eine Sprach-Toolchain, Docker, Build-Tools. Zum Beispiel, wenn deine Jobs Container bauen:

sudo apt update && sudo apt install -y docker.io
sudo usermod -aG docker runner

2. Den Runner herunterladen und registrieren

Geh in deinem Repo (oder deiner Org) auf GitHub zu Settings → Actions → Runners → New self-hosted runner. GitHub gibt dir die genauen Download-Befehle und ein Registrierungs-Token (es ist kurzlebig — hol es frisch). Als der runner-Benutzer:

sudo -iu runner
mkdir actions-runner && cd actions-runner
# nutze die genaue URL, die GitHub dir für dein OS/deine Arch zeigt:
curl -o actions-runner-linux-x64.tar.gz -L "URL_FROM_GITHUB"
tar xzf actions-runner-linux-x64.tar.gz
./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO --token YOUR_TOKEN

config.sh fragt nach einem Runner-Namen, Labels und einem Arbeitsordner — die Standardwerte sind zum Start in Ordnung. Labels sind, wie dein Workflow diesen Runner ansteuert (runs-on: self-hosted).

3. Als systemd-Dienst betreiben

Der Runner liefert einen Helfer, der einen systemd-Dienst für dich installiert — nutze ihn, damit der Runner Neustarts übersteht und bei einem Fehler neu startet. Weiterhin als Installation des runner-Benutzers, aber die Dienst-Befehle brauchen root:

sudo ./svc.sh install runner
sudo ./svc.sh start
sudo ./svc.sh status

Das registriert actions.runner.* als systemd-Unit, die als der runner-Benutzer läuft und beim Booten startet. Logs gehen an journald:

sudo journalctl -u 'actions.runner.*' -f

Zurück auf GitHubs Runners-Seite zeigt dein Runner jetzt Idle — grüner Punkt. Richte einen Workflow auf ihn:

jobs:
  build:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4
      - run: make test

Push, und der Job läuft auf deiner Maschine.

4. Halte ihn sauber

Ein selbst gehosteter Runner nutzt sein Dateisystem zwischen Jobs wieder — das ist der Geschwindigkeitsgewinn (warme Caches) und die Fußfalle (übrig gebliebener Zustand). Zwei Gewohnheiten halten ihn gesund:

Prune regelmäßig. Besonders Docker — docker system prune per Cron, sonst füllt sich die Festplatte still mit toten Layern.
Speichere keine Secrets auf der Maschine. Nutze GitHub-Actions-Secrets, pro Lauf injiziert, keine Dateien, die im Home des Runners liegen. Wenn der Runner kompromittiert wird, geht alles auf der Festplatte mit.

Wenn du eine wirklich saubere Umgebung pro Job brauchst, führe jeden Job innerhalb eines Container-Schritts aus — der Runner bleibt, das Chaos des Jobs nicht.

Wann selbst hosten, ehrlich

Hoste selbst, wenn du deine eigene Toolchain eingebacken brauchst, Zugriff auf private Netzwerk-Ressourcen oder Kontrolle über die Maschine. Bleib bei GitHub-gehosteten Runnern, wenn eine saubere Wegwerf-Umgebung und ihre Minuten dir passen — das ist wirklich einfacher, und einfacher ist etwas wert. Und niemals, auf einem öffentlichen Repo, selbst hosten. Das ist keine Vorliebe.

Wenn ein Privat-Repo-Runner das ist, was du brauchst: wähle einen Plan — Small (8 $) für leichtere Builds, Medium (12 $), wenn sie schwerer werden — zahle in USDC oder USDT (kein KYC, keine Dokumente), und du hast root in etwa 60 Sekunden. Dann arbeite dich diese Seite hinunter und du hast ein paar Minuten später einen Runner, der Jobs aufgreift.