Selbst gehostete GitHub-Actions-Runner vs. verwaltete CRACI-Runner

Was ist ein selbst gehosteter GitHub-Actions-Runner?

Ein selbst gehosteter Runner ist eine Maschine, die Sie bereitstellen und verwalten und die GitHub-Actions-Jobs anstelle einer GitHub-gehosteten VM ausführt. Das kann ein physischer Server, eine virtuelle Maschine oder ein Container sein, on-premises oder in Ihrem Cloud-Konto, und laut GitHub sind Sie für die Maschine und ihre gesamte Software verantwortlich.

• Registrierung: Ein Runner ist jeweils bei einem Repository, einer Organisation oder einem Enterprise registriert. Registrieren Sie ihn auf Organisationsebene und nutzen Sie Runner-Gruppen, um Runner über Repositories hinweg zu teilen.
• Plattformen: Die Runner-Anwendung unterstützt gängige Linux-Distributionen, Windows 10, 11 und Windows Server sowie macOS ab 11, auf x64 und ARM64.
• Netzwerk: Der Runner verbindet sich über ausgehendes HTTPS auf Port 443 mit GitHub.
• Updates: Die Runner-Anwendung muss innerhalb von 30 Tagen nach einem neuen Release aktualisiert werden. Sie aktualisiert sich selbst, sofern Sie das nicht abschalten.
• Limits: Ein Job kann bis zu 5 Tage laufen, gegenüber 6 Stunden auf GitHub-gehosteten Runnern, und ein Job, der länger als 24 Stunden in der Warteschlange steht, schlägt fehl.
• Skalierung: Actions Runner Controller (ARC), ein Kubernetes-Operator, skaliert Runner Scale Sets mit der Zahl der laufenden Workflows. Mit --ephemeral registrierte Runner übernehmen einen einzigen Job.

Warum Teams selbst hosten

Teams hosten selbst, um die Kosten pro Minute zu senken, um interne Systeme oder bestimmte Hardware zu erreichen und um Kapazität zu nutzen, die sie ohnehin bezahlen. GitHubs größere Runner können außerdem keine enthaltenen Minuten nutzen, große Maschinen werden auf gehosteten Runnern also teuer.

GitHub berechnet heute nichts pro Minute für selbst gehostete Runner. Es hatte eine Cloud-Plattformgebühr von $0.002 pro Minute für selbst gehostete Runner ab dem 1. März 2026 angekündigt und sie dann verschoben, „to take time to re-evaluate our approach.“ Mit Stand September 2026 beschreibt GitHubs Abrechnungsdokumentation die selbst gehostete Nutzung als kostenlos. Was GitHub nicht bezahlt, ist alles rund um den Runner.

Die drei Teile der Self-Hosting-Kosten

Die Kosten bestehen aus Infrastruktur, Engineering-Zeit und Sicherheitshärtung. Nur der erste Teil erscheint auf einer Rechnung.

Infrastruktur

Sie bezahlen die Hosts, ob sie Jobs ausführen oder im Leerlauf sind, und dimensionieren daher für Ihre Spitzenstunde. Dazu kommen Speicher für Caches und Images, Netzwerkverkehr und das, was Sie zum Überwachen und automatischen Skalieren der Flotte einsetzen.

Engineering-Zeit

GitHubs Dokumentation ist bei der Zuständigkeit deutlich: Bei selbst gehosteten Runnern gilt „you are responsible for updating the operating system and all other software.“ In der Praxis heißt das auch Runner-Upgrades, Image-Drift zwischen Hosts, Festplatten aufräumen, Autoscaling-Skripte und jemand in Rufbereitschaft, wenn die Warteschlange stehen bleibt.

Sicherheitshärtung

GitHubs Sicherheitsleitfaden für selbst gehostete Runner enthält zwei Warnungen, die sich im Wortlaut zu lesen lohnen:

Self-hosted runners should almost never be used for public repositories on GitHub, because any user can open pull requests against the repository and compromise the environment. GitHub Docs, Secure use reference

Self-hosted runners for GitHub do not have guarantees around running in ephemeral clean virtual machines, and can be persistently compromised by untrusted code in a workflow. GitHub Docs, Secure use reference

GitHub empfiehlt Just-in-Time-Runner, die höchstens einen Job ausführen, bevor sie entfernt werden. Das gut umzusetzen bedeutet ephemere Maschinen, Isolation zwischen Jobs, Kontrollen für ausgehenden Netzwerkverkehr und einen sorgfältigen Umgang mit Secrets. All das ist Arbeit, die Sie entwerfen, bauen und am Laufen halten.

Best Practices für selbst gehostete Runner in großem Maßstab

GitHubs Sicherheitsleitfaden und die von AWS veröffentlichten Praktiken für Runner in großem Maßstab laufen auf dieselbe Liste hinaus. Jeder Punkt ist ein eigenes Projekt:

• Ephemere Runner: ein Job pro Maschine, damit nichts zwischen Jobs übrig bleibt.
• Runner-Gruppen: Runner nach Repository und Umgebung trennen, idealerweise in separaten Konten.
• Kurzlebige Zugangsdaten: OpenID Connect zu Ihrer Cloud statt langlebiger Zugriffsschlüssel.
• Egress-Kontrolle: begrenzen, was ein Job erreichen kann, nicht nur, was er ausführt.
• Startzeit: Warm Pools und eigene Images, weil ephemere Maschinen langsamer starten.
• Kosten: Spot-Instanzen mit Fallback für lang laufende Jobs.
• Monitoring: Metriken zu wartenden, laufenden und abgeschlossenen Jobs, mit Warnungen.

Bei CRACI gehören der erste und der vierte Punkt zum Runner: Jeder Job läuft in einer isolierten virtuellen Maschine unter einer Egress-Richtlinie, die vor dem Start des Jobs validiert wird und im Zweifel blockiert (fail closed).

Ein Kostenmodell zum Ausfüllen

Beispiel A

Illustrative Eingaben, keine Benchmarks. 60.000 Build-Minuten pro Monat auf Runnern mit 2 vCPU, $350 pro Monat für Runner-Hosts und 8 Stunden Wartung pro Monat zu $85 pro Stunde.

• Selbst gehostet: $350 + (8 × $85) = $350 + $680 = $1,030 pro Monat
• CRACI: 60.000 × $0.004 = $240 pro Monat

Beispiel B

Illustrative Eingaben, keine Benchmarks. Dieselben 60.000 Minuten, aber die Hosts kosten $115 pro Monat, und die Wartung dauert 2 Stunden zu $85 pro Stunde.

• Selbst gehostet: $115 + (2 × $85) = $115 + $170 = $285 pro Monat
• CRACI: $240 pro Monat

In Beispiel B liegen beide allein bei der Rechenleistung nah beieinander. Das ist ein reales Ergebnis für Teams mit günstigen Hosts und einem stabilen Setup. Um Ihre eigene Gewinnschwelle zu finden, ziehen Sie Ihre Host-Kosten vom CRACI-Betrag ab und teilen durch Ihre Stundenkosten. Mit den Hosts aus Beispiel B sind das ($240 minus $115) ÷ $85, also etwa 1,5 Stunden Wartung pro Monat.

Zwei Dinge zeigt die Formel nicht. Erstens enthält der CRACI-Betrag mehr als Rechenleistung (siehe nächster Abschnitt). Zweitens sind die Stunden die Eingabe, die die meisten Teams unterschätzen. Zählen Sie Image-Updates, Sicherheitspatches, Skalierung, das Aufräumen von Festplatten und die Zeit für fehlgeschlagene Jobs mit, nicht nur die Ersteinrichtung.

Was selbst gehostete Runner Ihnen nicht geben

Ein selbst gehosteter Runner führt Ihren Job aus, zeichnet aber nicht auf, was der Job getan hat. Auf CRACI-Runnern erzeugt jeder Build während der Ausführung Nachweise:

• Eine SBOM aus dem Build in CycloneDX oder SPDX, von einem paketbewussten Proxy, der beobachtet, was der Job lädt, einschließlich aus CI-Caches wiederhergestellter Pakete. Die Vollständigkeit wird pro Job und pro Cache angegeben.
• Netzwerk-Egress-Richtlinie, Default Deny oder Allow, mit 24 integrierten Presets für Softwarequellen und typisierten benutzerdefinierten Quellen. Richtlinien werden vor dem Start des Jobs validiert und blockieren im Zweifel (fail closed). Verstöße lösen Warnungen aus.
• Ein Netzwerk-Trace pro Job, verfügbar über die API.
• Provenienzdaten, verfügbar über die API.
• Schwachstellenverfolgung über Builds und Repositories hinweg, wobei überwachte SBOMs kontinuierlich neu bewertet werden.

Teile davon können Sie auf selbst gehosteten Runnern mit eigenem Proxy, SBOM-Tooling und Netzwerk-Logging bauen. Dann gehört die Zeit für Aufbau und Pflege in das Kostenmodell oben.

Was CRACI nicht bietet

CRACI bietet heute keine vom Kunden gehosteten oder On-Premise-Runner an; sie sind für Enterprise auf der Roadmap. Builds laufen auf den verwalteten Runnern von CRACI auf europäischer Infrastruktur. Wenn ein Job in Ihrem eigenen Netzwerk, auf Ihrer eigenen Hardware oder in einer Air-Gap-Umgebung laufen muss, behalten Sie für diesen Job einen selbst gehosteten Runner.

• CRACI-Runner laufen heute nur auf Linux; Windows und macOS sind auf der Roadmap. macOS- und Windows-Builds bleiben, wo sie sind.
• x86-64 und ARM64 laufen zum selben Tarif.
• Images: CRACI Slim, CRACI Slim ARM64 und ein GitHub-kompatibles Ubuntu-24.04-Image. Verschachtelte Virtualisierung ist auf x86-64 verfügbar und auf ARM64 in der Preview.
• GitHub Actions ist die unterstützte CI-Integration.

Ein gemischtes Setup ist üblich. Einen Job zu verschieben ist eine Änderung an seiner runs-on-Zeile, Sie können also die meisten Jobs verschieben und einige auf selbst gehosteten Runnern belassen. Nur Jobs auf CRACI-Runnern erhalten Build-SBOMs und Netzwerkrichtlinien.

Wie Sie entscheiden

Entscheiden Sie anhand Ihrer eigenen Zahlen: der Runner-Kosten und Stunden des letzten Monats, der Nachweise, nach denen Sie gefragt werden, und eines echten Workflows, der auf jeder Option läuft.

1. Addieren Sie die Host-Rechnung des letzten Monats und die Stunden, die Ihr Team für Runner aufgewendet hat, einschließlich Vorfällen.
2. Zählen Sie Ihre Build-Minuten.
3. Setzen Sie beides in die Formeln oben ein.
4. Listen Sie die Nachweise auf, nach denen Sie gefragt werden (SBOMs, Provenienz, Netzwerkkontrollen), und was es bräuchte, um sie auf Ihren aktuellen Runnern zu erzeugen.
5. Buchen Sie eine Demo und führen Sie zum Vergleich einen echten Workflow auf CRACI aus.

Mehr dazu, wie die Runner funktionieren: CI/CD-Integration, Sicherheit bei CRACI und die Dokumentation.

Selbst gehostete GitHub-Actions-Runner: FAQ

Kurze Antworten zu Kosten, Einrichtung, Sicherheit und Limits.

Was ist ein selbst gehosteter GitHub-Actions-Runner?

Ein selbst gehosteter Runner ist eine Maschine, die Sie bereitstellen und verwalten und die GitHub-Actions-Jobs ausführt. Sie kann physisch, virtuell oder ein Container sein, on-premises oder in einem Cloud-Konto. Sie installieren darauf die GitHub-Runner-Anwendung, registrieren sie bei einem Repository, einer Organisation oder einem Enterprise und sprechen sie mit runs-on: self-hosted oder eigenen Labels an.

Sind selbst gehostete GitHub-Actions-Runner kostenlos?

GitHub berechnet mit Stand September 2026 nichts pro Minute für selbst gehostete Runner. Es hatte eine Plattformgebühr von $0.002 pro Minute ab dem 1. März 2026 angekündigt und sie dann verschoben, um seinen Ansatz neu zu bewerten. Sie bezahlen weiterhin die Maschinen, ihren Speicher und ihr Netzwerk sowie die Zeit, um sie gepatcht und sicher zu halten.

Kann ein selbst gehosteter Runner mehrere Repositories bedienen?

Ein Runner ist jeweils bei einem Repository, einer Organisation oder einem Enterprise registriert. Um ihn über Repositories hinweg zu teilen, registrieren Sie ihn auf Organisationsebene und steuern den Zugriff mit Runner-Gruppen, oder Sie betreiben mehrere Runner-Instanzen auf derselben Maschine, jede separat registriert.

Auf welchen Betriebssystemen läuft ein selbst gehosteter Runner?

GitHub unterstützt die Runner-Anwendung auf gängigen Linux-Distributionen wie Ubuntu ab 20.04, Debian ab 10 und RHEL ab 8, auf Windows 10, 11 und Windows Server 2016 bis 2022 sowie auf macOS ab 11. Sie läuft auf x64 und ARM64, unter Linux auch auf ARM32.

Wie lange kann ein Job auf einem selbst gehosteten Runner laufen?

Bis zu 5 Tage, gegenüber 6 Stunden auf GitHub-gehosteten Runnern. Ein Job, der länger als 24 Stunden in der Warteschlange steht, schlägt fehl.

Sind selbst gehostete Runner für öffentliche Repositories sicher?

Laut GitHub sollten selbst gehostete Runner fast nie für öffentliche Repositories verwendet werden, weil jeder einen Pull Request öffnen und Code auf der Maschine ausführen kann. GitHub empfiehlt ephemere Just-in-Time-Runner, die höchstens einen Job ausführen, dazu Isolation, Egress-Kontrolle und einen sorgfältigen Umgang mit Secrets.

Was macht der Actions Runner Controller?

Actions Runner Controller (ARC) ist ein Kubernetes-Operator, der selbst gehostete Runner für GitHub Actions orchestriert und skaliert. Runner Scale Sets wachsen und schrumpfen mit der Zahl der laufenden Workflows. Den Cluster, die Images und das Netzwerk darum betreiben Sie weiterhin selbst.

Können CRACI-Runner in meinem eigenen Netzwerk laufen?

Heute nicht. CRACI bietet verwaltete Runner auf europäischer Infrastruktur, vom Kunden gehostete Runner sind für Enterprise auf der Roadmap. Jobs, die in Ihrem Netzwerk laufen müssen, können auf selbst gehosteten Runnern bleiben, während andere Jobs zu CRACI wechseln.