Wie betreibe ich einen selbstgehosteten GitHub-Actions-Runner auf einem VPS?

Richte einen Linux-VPS ein (Small — 4 vCPU / 4 GB — ist die sinnvolle Voreinstellung), installiere das Runner-Paket aus Settings → Actions → Runners deines Repos, registriere es mit dem Token, den GitHub ausgibt, und starte es als Dienst. Die vollständigen Schritte zum Kopieren stehen unten; root gibt es in etwa einer Minute.

Kann ich den Runner in Docker betreiben?

Ja. Betreibe das offizielle Runner-Image (oder dein eigenes) in einem Container, oder nutze es, um jedem Job eine isolierte, wegwerfbare Umgebung zu geben. Eine dedizierte IP ist nicht nötig — der Runner baut nur ausgehende Verbindungen zu GitHub auf, ein NAT-Plan reicht also.

Wie halte ich den Runner als Dienst am Laufen?

Der Runner bringt ein svc.sh-Hilfsskript mit, das eine systemd-Unit installiert: ./svc.sh install && ./svc.sh start. Danach übersteht er Neustarts und startet bei Fehlern neu. Die genauen Befehle stehen in der Anleitung unten.

Ist ein selbstgehosteter Runner günstiger als GitHub-gehostete Minuten?

Für aufwändiges oder häufiges CI ja. GitHub-gehostete Runner rechnen über dem Freikontingent pro Minute ab; ein VPS für $8/Monat läuft für eine Pauschale mit unbegrenzten Minuten und bleibt „warm“ (kein Kaltstart, zwischengespeicherte Abhängigkeiten). Ein aktives Repo bezahlt die Maschine meist selbst.

Fragt ihr nach Ausweis oder Kreditkarte?

Nein. Registrierung per E-Mail, Zahlung in USDC oder USDT. Keine Dokumente, keine Karte, niemals KYC.

VPS für selbstgehostete GitHub-Actions-Runner

Betreibe deinen eigenen selbstgehosteten GitHub-Actions-Runner auf einem VPS — schnelleres CI, keine Abrechnung pro Minute, volle Kontrolle über die Build-Umgebung. Zahlung in Krypto, ohne KYC. Ab $8/Monat.

GitHub-gehostete Runner sind bequem, bis die Rechnung oder die Wartezeit anfängt wehzutun. Über dem Freikontingent zahlst du pro Minute, jeder Job startet „kalt“ und lädt Abhängigkeiten jedes Mal neu herunter. Ein selbstgehosteter Runner auf deinem eigenen VPS dreht alle drei Punkte um: feste Monatskosten, eine „warme“ Maschine mit deinen Caches bereits auf der Platte und eine Build-Umgebung, die du vollständig kontrollierst — bestimmte Tool-Versionen, mehr RAM, ein Docker-Layer-Cache, der wirklich bestehen bleibt.

Ein Runner muss GitHub nur ausgehend erreichen, also läuft er auf unseren günstigsten Plänen, zahlt in Krypto und braucht kein KYC.

Was ein Runner braucht

CPU und RAM für deine Builds. Small ($8/Monat — 4 vCPU, 4 GB RAM, 35 GB NVMe) ist die bequeme Voreinstellung für die meisten CI: Node/Go/Rust-Builds, Testsuiten, Docker-Image-Builds. Aufwändige Kompilierung oder parallele Jobs? Wechsle zu Medium oder einem Pro-Plan.
NVMe-Platte für Caches. Der ganze Sinn des Selbsthostens ist Persistenz — Abhängigkeits-Caches, Docker-Layer und Build-Artefakte bleiben zwischen den Läufen auf der Platte. NVMe hält das Wiederherstellen schnell.
Keine dedizierte IP nötig. Der Runner wählt sich per HTTPS zu GitHub; eingehender Zugriff ist nicht nötig. Ein NAT-Plan (ab $3/Monat) genügt. Nimm eine dedizierte IP nur, wenn du zusätzlich etwas hostest, das Traffic ausliefert.

Einen Runner einrichten (Ubuntu 24.04)

Erstelle den Runner in deinem Repo (oder deiner Organisation): Settings → Actions → Runners → New self-hosted runner → Linux. GitHub zeigt einen Download-Befehl und ein einmaliges Registrierungs-Token. Auf dem VPS:

# als Nicht-root-Benutzer (der Runner verweigert den Betrieb als root)
adduser --disabled-password --gecos "" runner
su - runner

mkdir actions-runner && cd actions-runner
curl -o actions-runner-linux-x64.tar.gz -L \
  https://github.com/actions/runner/releases/latest/download/actions-runner-linux-x64.tar.gz
tar xzf actions-runner-linux-x64.tar.gz

# mit URL + Token aus der GitHub-Oberfläche registrieren
./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO --token YOUR_TOKEN

Als Dienst am Laufen halten

Führe ./run.sh nicht im Terminal aus — installiere den Runner als systemd-Dienst, damit er Neustarts übersteht:

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

Der Runner erscheint nun als Idle in der GitHub-Oberfläche und übernimmt jeden Job, der auf ihn zielt.

Aus einem Workflow verwenden

Richte einen Job über runs-on auf deinen Runner:

jobs:
  build:
    runs-on: self-hosted        # oder ein eigenes Label, das du bei der Registrierung setzt
    steps:
      - uses: actions/checkout@v4
      - run: make build && make test

Docker-basierte Jobs

Installiere Docker einmal, und deine Workflows können Images bauen oder Service-Container betreiben, wobei der Layer-Cache zwischen den Läufen bestehen bleibt:

sudo apt update && sudo apt install -y docker.io
sudo usermod -aG docker runner   # dem Runner Docker ohne sudo erlauben

Für eine wegwerfbare Isolation pro Job betreibe den Runner selbst in einem Container und erstelle ihn bei jedem Lauf neu — ein gängiges Muster für nicht vertrauenswürdige oder Matrix-Builds.

Warum EQVPS für CI

Feste Kosten, unbegrenzte Minuten. Keine Abrechnung pro Minute — eine ausgelastete Pipeline kostet so viel wie eine leerlaufende.
„Warme“ Caches. Abhängigkeiten und Docker-Layer bleiben zwischen den Läufen auf NVMe; Builds werden schneller, nicht langsamer.
Root in ~60 Sekunden, saubere Images. Ubuntu, Debian und mehr via cloud-init; installiere genau die Toolchain, die du brauchst.
Ohne KYC, Zahlung in Krypto. E-Mail zum Anmelden, USDC/USDT zum Zahlen. Starte für Release-Spitzen zusätzliche Runner und kündige sie danach — ungenutzte bezahlte Zeit wird deinem Guthaben gutgeschrieben.

Vollständige Schritt-für-Schritt-Anleitung →