GitHub Actions Runner selbst hosten

Ein Standard-Linux-Runner von GitHub liefert 4 CPU-Kerne, 16 GB RAM und 14 GB Speicher – auf einem öffentlichen Repository. Schicken Sie denselben Workflow an ein privates Repository, schrumpft das still auf 2 Kerne und 8 GB, weil Minuten auf privaten Repos abgerechnet werden und GitHub die Box entsprechend dimensioniert. Meine Proxmox-Box gibt einem Runner ohne Zögern 8 Kerne und 32 GB, und sie leert ihren Docker-Layer-Cache nie zwischen den Jobs, weil es immer derselbe Container ist.

Diese Lücke – plus ein monatliches Minuten-Kontingent, das private Repos tatsächlich aufbrauchen können – ist der Grund, warum so viele Selbsthoster irgendwann einen Workflow auf die eigene Hardware zeigen lassen. Das ist eine wirklich einfache Sache einzurichten. Es ist aber auch die eine CI-Entscheidung, bei der ein übersprungenes Kleingedrucktes einem fremden Pull Request eine Shell auf Ihrer Maschine verschaffen kann.

TL;DR

Ein selbst gehosteter Runner ist nur ein kleiner Agent, den Sie auf Ihrer eigenen Maschine installieren und der GitHub nach Jobs pollt – Setup ist config.sh + svc.sh install, etwa 10 Minuten.
GitHub-gehostete Runner auf privaten Repos laufen mit der halben CPU und RAM-Ausstattung des Public-Repo-Standards (2 Kerne/8 GB statt 4 Kerne/16 GB), und private Repos haben ein begrenztes Freikontingent an Minuten.
Eine Homelab-Box bietet typischerweise mehr Kerne, mehr RAM und persistente Build-Caches, die GitHub-gehostete Runner bei jedem Lauf zurücksetzen.
GitHub rät ausdrücklich von selbst gehosteten Runnern auf öffentlichen Repositories ab – jeder, der einen Fork-Pull-Request öffnet, kann potenziell Code auf Ihrem Runner ausführen.
Die Lösung ist nicht "nicht selbst hosten", sondern zu wissen, welche Einstellungen (Freigabepflicht, ephemere Runner, nur privat) es für Ihre Situation sicher machen.

KEY-STAT: 2.000 Minuten/Monat — GitHub Actions' kostenloses CI/CD-Minutenkontingent auf privaten Repos, bevor Kosten pro Minute anfallen (Free-Plan, Stand 2026)

Warum einen Workflow auf die eigene Hardware zeigen lassen

Die Gründe, warum Menschen von GitHub-gehosteten Runnern wegziehen, sind nicht exotisch – es sind dieselben drei, vier Punkte, die bei den meisten Self-Hosting-Entscheidungen auftauchen.

Minuten kosten Geld auf privaten Repos. Öffentliche Repos bekommen unbegrenzte GitHub-gehostete Minuten, private nicht. Der Free-Plan enthält aktuell 2.000 CI/CD-Minuten im Monat, und jedes Betriebssystem multipliziert unterschiedlich gegen dieses Kontingent – Linux verbraucht es mit Faktor 1x, Windows mit 2x, macOS mit etwa 10x. Ein Team, das einen Matrix-Build über alle drei Systeme laufen lässt, kann das Freikontingent schnell aufbrauchen, und Linux-Überschreitungen kosten derzeit wenige Zehntel-Cent pro Minute, was sich bei einem vielbeschäftigten Repo summiert.

Persistente Caches. GitHub-gehostete Runner sind per Design ephemer – eine frische VM startet pro Job und wird danach zerstört. Das ist großartig für Isolation und schlecht für alles mit einem langsamen ersten Build: Docker-Layer, node_modules, Rusts target/, Gos Modul-Cache. Ein Homelab-Runner hält diesen Cache zwischen den Läufen warm, sodass ein Rebuild, der nur eine Datei betraf, den Großteil dessen überspringen kann, was GitHub jedes Mal von Grund auf neu machen würde.

Hardware-Zugriff. Manchmal braucht der Job tatsächlich etwas, das GitHubs geteilte Flotte standardmäßig nicht bietet – eine GPU für einen Trainings- oder Transcoding-Schritt, ARM-Hardware zum Testen gegen echtes Silizium statt Emulation, oder einen bestimmten Beschleuniger. Self-Hosting ist der direkte Weg, das in die CI zu bekommen.

Netzwerkzugriff auf interne Ressourcen. Ein Runner im eigenen Homelab-Netzwerk erreicht Dinge, an die ein cloud-gehosteter Runner ohne zusätzliche Klempnerarbeit nie herankommt – eine interne Registry, eine lokale Datenbank für Integrationstests oder eine Proxmox-API für Deploy-Skripte, ohne irgendetwas dem öffentlichen Internet zu öffnen.

Nichts davon braucht exotische Hardware. Wer noch überlegt, worauf ein Runner überhaupt laufen soll, für den gelten dieselben Abwägungen wie in unserem Guide zum besten Mini-PC für einen Heimserver direkt – ein Runner ist einfach ein weiterer leichtgewichtiger, dauerhaft laufender Dienst.

Einen selbst gehosteten Runner registrieren (die echten Schritte)

Das ist GitHubs tatsächlicher dokumentierter Prozess, keine Paraphrase. Gehen Sie in Ihrem Repository (oder Ihrer Organisation) zu Settings → Actions → Runners → New self-hosted runner, wählen Sie Ihr Betriebssystem, und GitHub gibt Ihnen einen Download-Link sowie ein kurzlebiges Registrierungstoken, das speziell für diesen Seitenaufruf generiert wurde – es läuft nach etwa einer Stunde ab, kopieren Sie also das echte angezeigte Token, statt einen alten Befehl aus einem Tutorial wiederzuverwenden.

mkdir actions-runner && cd actions-runner

curl -o actions-runner-linux-x64.tar.gz -L \
  https://github.com/actions/runner/releases/download/vX.Y.Z/actions-runner-linux-x64-X.Y.Z.tar.gz
tar xzf ./actions-runner-linux-x64.tar.gz

./config.sh --url https://github.com/OWNER/REPO --token YOUR_REGISTRATION_TOKEN

./run.sh

Die genaue Version und Download-URL, die GitHub Ihnen gibt, unterscheidet sich – kopieren Sie immer die auf der New-Runner-Seite Ihres Repos angezeigte, statt eine Versionsnummer fest zu verdrahten. config.sh funktioniert für die Registrierung auf Organisationsebene genauso, nur mit einer Org-URL statt einer Repo-URL. ./run.sh im Vordergrund auszuführen reicht, um die Verbindung zu bestätigen, bevor Sie es in einen Dienst verwandeln.

Eine erfolgreiche Registrierung endet mit √ Connected to GitHub und Listening for Jobs. An diesem Punkt erscheint der Runner unter Settings → Actions → Runners als idle, und jeder Workflow mit runs-on: self-hosted (oder einem passenden Custom-Label) wird zu ihm geroutet.

Als Dienst laufen lassen mit svc.sh

./run.sh in einem Terminal auszuführen funktioniert zum Testen, stirbt aber in dem Moment, in dem Sie die Sitzung schließen. Für alles Ernsthafte installieren Sie es als Dienst, damit es Neustarts übersteht:

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

Standardmäßig ist der Runner nicht ephemer – derselbe Container oder dieselbe VM bearbeitet Job nach Job, hält Caches warm, behält aber auch jeden übrig gebliebenen Zustand (und jede übrig gebliebene Kompromittierung) für den nächsten Lauf bei. GitHub unterstützt außerdem ein --ephemeral-Flag für config.sh, das den Runner nach einem einzigen Job wieder abbaut und so den Cache-Vorteil gegen eine saubere Ausgangslage bei jedem Mal eintauscht. Auf einem privaten Repo mit vertrauenswürdigen Mitarbeitenden ist persistent meist in Ordnung. Bei allem Öffentlichen ist ephemer die sicherere Standardeinstellung – mehr dazu weiter unten.

GitHub-gehostet vs. Homelab-Box: die echten Zahlen

Hier der Vergleich so, wie GitHubs eigene Dokumentation und Preisseiten ihn angeben, neben dem, was eine bescheidene Homelab-Box typischerweise bietet:

	GitHub-gehostet (Public Repo)	GitHub-gehostet (Private Repo)	Typischer Homelab-Runner
CPU	4 Kerne	2 Kerne	4–16+ Kerne, was Sie zuteilen
RAM	16 GB	8 GB	8–64+ GB, was Sie zuteilen
Speicher	14 GB SSD	14 GB SSD	Was Ihr Storage-Pool frei hat
Build-Cache	Bei jedem Job zurückgesetzt	Bei jedem Job zurückgesetzt	Bleibt zwischen Jobs erhalten
Kosten	Kostenlos, unbegrenzt	2.000 Min/Monat frei (Free-Plan), dann abgerechnet	0 € Grenzkosten – Hardware, die Sie schon besitzen
GPU/ARM-Zugriff	Nicht auf Standard-Runnern	Nicht auf Standard-Runnern	Was auch immer Sie durchreichen
Isolation	Frische VM pro Job	Frische VM pro Job	Hängt komplett von Ihrer Konfiguration ab

Lesen Sie die letzte Zeile genau – sie ist der gesamte Trade-off in einer Zeile. GitHubs Isolation ist automatisch und nicht verhandelbar; die Isolation eines Homelab-Runners ist eine Entscheidung, die Sie selbst treffen müssen, jedes Mal.

Der Sicherheits-Trade-off, den Sie nicht überspringen können

Warning

GitHubs eigene Sicherheitsdokumentation sagt klar, dass selbst gehostete Runner auf öffentlichen Repositories fast nie verwendet werden sollten, weil jeder einen Pull Request von einem Fork öffnen und dadurch potenziell beliebigen Code auf diesem Runner ausführen kann. Das ist kein theoretischer Randfall – es ist das Standardverhalten, sofern Sie es nicht explizit einschränken, und der mit Abstand häufigste Grund, warum Menschen sich mit selbst gehosteter CI verbrennen.

Warum ein Fork-PR spezifisch gefährlich ist

Ein durch einen Pull Request ausgelöster Workflow führt den Code in diesem Pull Request aus – inklusive dessen CI-Konfiguration. Auf einem GitHub-gehosteten Runner ist das eingedämmt: eine Wegwerf-VM mit eingeschränkten Standardrechten, zerstört in der Sekunde, in der der Job endet. Auf einem selbst gehosteten Runner läuft derselbe nicht vertrauenswürdige Code auf Hardware, die Ihnen gehört, mit Netzwerkzugriff auf alles andere, was auf dieser Maschine oder in diesem Netzwerk lebt, und – je nach Berechtigungen des Workflows – potenziellem Zugriff auf das GITHUB_TOKEN und alle Repository-Secrets, die für diesen Trigger verfügbar sind. Ist der Runner nicht ephemer, kann ein bösartiger Job etwas für den nächsten Job hinterlassen, statt nur während des eigenen Laufs Schaden anzurichten.

Genau deshalb ist unser Beitrag zu Docker vs. virtuelle Maschinen auch hier relevant – ein Runner in einem leicht isolierten Container ist ein ganz anderer Explosionsradius als einer in einer VM, die Sie ohne Bedenken wegwerfen würden.

Es sicher machen, wenn Sie auf einem öffentlichen Repo bleiben

Tip

Wenn Sie einen selbst gehosteten Runner auf einem Repo brauchen, das öffentlich bleiben muss, erledigen drei Einstellungen den Großteil der Arbeit: Freigabe für alle externen Mitarbeitenden verlangen, bevor deren Workflow läuft (Settings → Actions → General), --ephemeral-Runner verwenden, damit kein Job den Zustand des letzten erbt, und den Runner auf eine dedizierte, entbehrliche Umgebung statt Ihre tägliche Arbeitsmaschine beschränken. Keine davon macht es "GitHub-gehostet-sicher", aber zusammen schließen sie die Tür, durch die Fork-PRs standardmäßig gehen.

Die ehrliche, einfachste Lösung für die meisten Homelab-Anwendungsfälle ist enger als jede dieser Einstellungen: selbst gehostete Runner nur auf privaten Repos betreiben. Diese eine Entscheidung entfernt den Fork-PR-Angriffspfad vollständig, da nur Personen, denen Sie bereits Schreibzugriff gewährt haben, überhaupt PRs gegen ein privates Repo öffnen können. Wer aus Kosten- oder Geschwindigkeitsgründen bei eigenen persönlichen oder Team-Projekten selbst hostet, gehört fast immer genau dahin.

Wo der Runner in einem Proxmox-Homelab sitzt

In der Praxis ist ein GitHub-Actions-Runner ein leichtgewichtiger, meist untätiger Dienst – er konkurriert mit nichts Anspruchsvollem um Ressourcen. Ihn in einen Docker-Container oder LXC-Container auf einer bestehenden Proxmox-Box zu packen, neben allem anderen, was dort schon läuft, reicht für die meisten persönlichen CI-Workloads – es gibt selten einen Grund, dafür eigene Hardware zu reservieren. Wer noch entscheidet, wo neue Container wie dieser relativ zu VMs leben sollten, für den beantwortet genau das unser Guide zu Proxmox vs. Docker, und wer das zugrunde liegende Homelab erst noch aufbaut, findet in unserem Einsteiger-Homelab-Guide den Startpunkt.

Note

Behandeln Sie den Host eines selbst gehosteten Runners wie jeden anderen Dienst mit Netzwerkzugriff und durchfließenden Secrets – patchen Sie ihn, halten Sie ihn nicht direkt am offenen Internet, und verwenden Sie dieselbe Box nicht für irgendetwas, dessen Kompromittierung Sie hassen würden.

Halten Sie den Job des Runners eng begrenzt, halten Sie ihn von öffentlichen Repos fern, sofern Sie ihn nicht bewusst abgesichert haben, und er ist eine der wartungsärmsten Ergänzungen, die Sie einem Homelab hinzufügen können – ein echter Geschwindigkeits- und Kostengewinn für das Risiko, das er tatsächlich eingeht.

FAQ

Ist es sicher, einen selbst gehosteten GitHub Actions Runner auf einem öffentlichen Repository zu nutzen?

Nicht standardmäßig. GitHubs eigene Dokumentation rät davon ab, weil jeder Fork-Pull-Request potenziell Code auf dem Runner ausführen kann. Es ist nur mit zusätzlichen Kontrollen einigermaßen sicher – Freigabepflicht für externe Mitarbeitende, ephemere Runner und ein entbehrlicher, isolierter Host.

Wie richte ich einen selbst gehosteten GitHub Actions Runner ein?

Gehen Sie im Repo unter Settings → Actions → Runners auf "New self-hosted runner", laden Sie das von GitHub verlinkte Paket herunter, führen Sie ./config.sh --url <repo-url> --token <token> mit dem auf dieser Seite angezeigten Token aus, und starten Sie dann entweder ./run.sh direkt oder installieren Sie es als Hintergrunddienst mit sudo ./svc.sh install && sudo ./svc.sh start.

Wie viele kostenlose GitHub-Actions-Minuten bekomme ich auf einem privaten Repo?

Im Free-Plan bekommen private Repos aktuell 2.000 CI/CD-Minuten im Monat, bevor Kosten pro Minute anfallen, wobei Windows- und macOS-Jobs das Kontingent schneller aufbrauchen als Linux-Jobs. Öffentliche Repos bekommen unabhängig vom Plan unbegrenzte GitHub-gehostete Minuten.

Welche Hardware-Specs nutzen GitHub-gehostete Runner tatsächlich?

Die Standard-Linux- und Windows-Runner laufen mit 4 CPU-Kernen, 16 GB RAM und 14 GB SSD-Speicher auf öffentlichen Repos – Private-Repo-Runner auf demselben Betriebssystem fallen auf 2 Kerne und 8 GB. Eine Homelab-Maschine erreicht oder übertrifft diese Zahlen typischerweise und setzt ihren Cache nicht zwischen Jobs zurück.

Kann ein selbst gehosteter Runner als ephemere Einweg-Instanz laufen?

Ja. Das Flag --ephemeral an config.sh konfiguriert den Runner so, dass er genau einen Job annimmt und sich danach abmeldet, sodass nichts zwischen den Läufen bestehen bleibt. Das opfert den Vorteil des persistenten Caches, der viele Menschen überhaupt erst zum Self-Hosting zieht, schließt aber den Hauptweg, über den ein kompromittierter Job den nächsten beeinflussen kann – ein vernünftiger Trade-off für alles mit Öffentlichkeitsbezug.