So wechseln Sie den Runner-Anbieter für GitHub Actions: Labels, Caches, Secrets, Abrechnung und Fallback

Dieser Leitfaden ist anbieterneutral. Er erklärt, was sich beim Wechsel des Runner-Anbieters für GitHub Actions verschiebt, was am häufigsten bricht und wie Sie zurückwechseln. Wir entwickeln CRACI, einen der Anbieter; CRACI erscheint dort, wo ein dokumentierter Fakt zutrifft, und in einem eigenen Abschnitt am Ende. Um zuerst einen Anbieter zu wählen, lesen Sie Runner-Anbieter für GitHub Actions im Vergleich und Alternativen zu GitHub-gehosteten Runnern.

Was sich beim Wechsel ändert und was bleibt

GitHub Actions besteht aus zwei Hälften. GitHub ist die Control Plane: Es speichert das Repository und die Workflow-Dateien, löst die Trigger aus, speichert Secrets, weist Jobs zu, zeigt Logs und Checks, bewahrt Artefakte auf und stellt OIDC-Tokens aus. Der CI-Runner ist der Ort, an dem ein Job läuft: eine Maschine mit Image, CPU, Festplatte, einem Netzwerkpfad ins Internet und meist einem lokalen Cache. GitHub weist einen Job einem Runner zu, liefert beim Start die Secrets des Jobs, und der Runner streamt die Logs zurück.

Ein Runner-Anbieter ersetzt nur die zweite Hälfte.

Element	Bleibt bei GitHub	Wechselt zum Anbieter
Repository, Workflow-Dateien, Trigger	Ja	Nein
Secret-Speicher	Ja	Secrets werden beim Jobstart an die Maschine des Anbieters geliefert
Jobzuweisung, Logs, Checks-Oberfläche	Ja	Der Runner streamt die Logs zurück
Artefakte aus actions/upload-artifact	Ja	Nein
Aussteller des OIDC-Tokens	Ja	Nein, aber das Token weist den Runner als selbst gehostet aus
Maschine, Image, CPU, Arbeitsspeicher, Festplatte	Nein	Ja
Ausgehender Netzwerkpfad und IP-Adressen	Nein	Ja
Cache-Speicher	Hängt vom Anbieter ab	Hängt vom Anbieter ab
Minutengenaue Abrechnung der verschobenen Jobs	Nein	Ja

Ein Drittanbieter-Runner registriert sich bei GitHub als selbst gehosteter Runner. Deshalb gelten für ihn GitHubs Regeln für selbst gehostete Runner: wie Labels Jobs zuordnen, wie Runner-Gruppen den Zugriff begrenzen, wie das OIDC-Token ihn beschreibt und wie GitHub ihn abrechnet.

Die runs-on-Änderung und Labels

GitHub sucht einen Runner, der zu den runs-on-Labels und Gruppen des Jobs passt. Ist kein passender Runner online, bleibt der Job in der Warteschlange, bis einer online kommt; nimmt ein zugewiesener Runner den Job nicht innerhalb von 60 Sekunden an, wird er neu eingereiht; und ein Job, der länger als 24 Stunden wartet, schlägt fehl (GitHubs Referenz zu selbst gehosteten Runnern). Ein Tippfehler im Label oder eine App des Anbieters, die nicht auf dem Repository installiert ist, zeigt sich als Job, der nie startet.

Anbieter kodieren die Maschine auf eine von zwei Arten:

• Im Label. Ubicloud nutzt Labels wie ubicloud-standard-2, Blacksmith blacksmith-2vcpu-ubuntu-2404 und Avrea avrea-ubuntu-latest-2-vcpu, mit arm im Label für ARM-Maschinen. Eine andere Größe bedeutet ein anderes Label.
• In einem Setup-Schritt. CRACI nutzt ein Label, runs-on: craci, und der Schritt cracicorp/setup@v1 wählt die Größe (1 bis 32 Compute Units zu je 1 vCPU und 3 GB, Standard 2), das Image, die Netzwerkrichtlinie oder eine Runner-Vorlage der Organisation über ihren Slug. Kann CRACI eine Eingabe nicht parsen, läuft die Standardumgebung und eine Warnung landet im Job-Log; ein unbekanntes Image oder eine unbekannte Vorlage wird abgelehnt.

Machen Sie den Wechsel zu einer Variable

Legen Sie das Label in einer Repository- oder Organisationsvariable ab, statt es fest zu codieren. Der Wechsel hin und zurück ist dann eine Einstellungsänderung, kein Pull Request in jedem Repository.

jobs:
  build:
    # Falls back to GitHub-hosted when the variable is not set
    runs-on: ${{ vars.LINUX_RUNNER || 'ubuntu-latest' }}
    steps:
      - uses: actions/checkout@v7
      - run: make build

  deploy:
    needs: build
    # Stays on GitHub-hosted until you decide to move it
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh

Die Wahl erfolgt pro Job, sodass Build- und Test-Jobs umziehen können, während ein Deploy-Job bleibt. Variablen lassen sich auf Organisationsebene setzen und pro Repository überschreiben, sodass eine Einstellung eine Gruppe von Repositories verschieben und ein einzelnes Repository sich davon ausnehmen kann.

Wiederverwendbare Workflows

Wird dieselbe Pipeline in viele Repositories kopiert, verschieben Sie sie in einen wiederverwendbaren Workflow, der den Runner aus einem Input oder einer Variable liest. Eine Änderung von runs-on dort ändert jedes Repository, das ihn aufruft. Rulesets können verlangen, dass ein Workflow in den Repositories einer Organisation läuft, damit die gemeinsame Version in Gebrauch bleibt.

Runner-Images: Kompatibilität und Pinning

GitHubs gehostetes Image bringt ein großes vorinstalliertes Toolset und einen gehosteten Tool-Cache mit. Anbieter bieten entweder ein zu GitHub kompatibles Image oder ein schlankeres. Jobs hängen oft von Dingen ab, die sie nie deklarieren:

• vorinstallierte Sprachversionen und Kommandozeilen-Tools;
• sudo ohne Passwort und systemd für Dienste, die mit systemctl gestartet werden;
• einen laufenden Docker-Daemon mit Buildx und Compose;
• den gehosteten Tool-Cache, den setup-*-Actions lesen, bevor sie herunterladen;
• freien Festplattenplatz für große Builds.

Entscheidungsregel: Beginnen Sie mit dem GitHub-kompatiblen Image des Anbieters. Verschieben Sie einen Job erst auf ein schlankes Image, wenn er grün ist, und ergänzen Sie explizite setup-*-Schritte für alles, was er implizit genutzt hat.

Pinning: ubuntu-latest wechselt nach GitHubs Zeitplan auf ein neues Release, und ubuntu-24.04 pinnt das Betriebssystem-Release, nicht die Paketversionen darauf. Pinnen Sie, was zählt, im Job selbst: Setup-Actions mit expliziten Versionen und Container-Images per Digest. Fragen Sie jeden Anbieter, was Sie pinnen können. Die Runner-Anwendung selbst muss sich laufend aktualisieren, um mit GitHub zu kommunizieren.

Bei CRACI sind die Images CRACI Slim auf x86-64 und ARM64 (Ubuntu 24.04, ohne systemd) und ein vollständiges, zu GitHub Actions kompatibles Ubuntu-24.04-Image, wählbar als ubuntu-24.04 oder ubuntu-latest, das GitHubs Ubuntu-24.04-Runner-Image folgt und den gehosteten Tool-Cache enthält. Jedes Image enthält Docker Engine, Buildx und Compose v2.

Caches: was übernommen wird und was kalt startet

Die ersten Läufe bei einem neuen Anbieter sind oft langsamer, und der übliche Grund ist ein kalter Cache, keine langsame Maschine. Wie actions/cache funktioniert, bestimmt, was Sie sehen (README von actions/cache):

• Ein Eintrag wird über seinen Key und eine Version gefunden, einen Hash der gecachten Pfade und des Kompressionstools.
• Einträge gelten pro Branch; die Einträge des Standard-Branches stehen anderen Branches zur Verfügung.
• Standardmäßig kann ein Repository bis zu 10 GB an Caches halten, bevor die ältesten Einträge verdrängt werden. Repository-Administratoren sowie Organisations- oder Enterprise-Owner können das Limit anheben; Nutzung über 10 GB wird dem Konto in Rechnung gestellt (GitHub zu Dependency Caching).
• Ein unter Windows gespeicherter Cache wird auf einem anderen Betriebssystem nicht wiederhergestellt und umgekehrt, sofern enableCrossOsArchive nicht gesetzt ist; ein anderes Kompressionstool ergibt ebenfalls eine andere Version.

Anbieter stellen den Cache auf eine von zwei Arten bereit:

Modell	Erste Läufe	Abwägung
Der Runner nutzt den Cache-Dienst von GitHub, wie GitHub-gehostete Runner	Vorhandene Einträge werden wiederhergestellt	Cache-Verkehr läuft über das Internet zwischen Anbieter und GitHub
Der Anbieter stellt die Cache-API aus Speicher neben seinen Runnern bereit	Meist leer, bis die ersten Läufe ihn füllen, es sei denn, der Anbieter importiert GitHubs Einträge oder greift auf sie zurück	Schnellere Wiederherstellung; dort geschriebene Einträge sind für GitHub-gehostete Runner meist nicht sichtbar

Der zweite Punkt zählt für gemischte Flotten und für den Rückweg: Wechseln Sie einen Job zurück, startet er möglicherweise auch auf GitHub kalt. Fragen Sie, welches Modell der Anbieter nutzt und wo die Einträge liegen.

Einen kalten Cache von einem langsamen Runner unterscheiden. Nehmen Sie einen Node-Build, der ein großes node_modules-Verzeichnis cacht. Beim ersten Lauf bei einem neuen Anbieter meldet actions/cache einen Miss, der Installationsschritt lädt alles herunter und der Post-Schritt speichert den Cache. Ab dem nächsten Lauf auf demselben Branch meldet der Schritt einen Treffer und der Installationsschritt schrumpft. Vergleichen Sie Läufe erst, wenn der Cache warm ist: Lesen Sie den Output cache-hit und messen Sie den Restore-Schritt und den Installationsschritt getrennt vom eigentlichen Build. Unter So funktioniert der GitHub-Actions-Cache finden Sie Keys, Scopes und Cache Poisoning.

Bei CRACI funktioniert actions/cache wie bisher, und der Build-Datensatz vermerkt pro Paket, ob es aus einem CI-Cache wiederhergestellt statt abgerufen wurde.

Docker Layer Caching

Mechanismus	Wo die Layer liegen	Was Sie wissen sollten
BuildKit type=gha	Der GitHub-Actions-Cache	Dieselben Scope- und Größenregeln wie oben; es braucht einen Builder, der es unterstützt
BuildKit type=registry	Ein separates Image in Ihrer Registry	Funktioniert auf jedem Runner und übersteht einen Anbieterwechsel; Sie zahlen Registry-Speicher und -Transfer
Lokaler Layer-Cache oder persistente Festplatte des Anbieters	Neben den Runnern des Anbieters	Meist am schnellsten; bleibt zurück, wenn Sie den Anbieter verlassen

Ein Registry-Cache ist die portable Option (Docker-Cache-Backends):

- uses: docker/build-push-action@v7
  with:
    push: true
    tags: ghcr.io/acme/app:latest
    cache-from: type=registry,ref=ghcr.io/acme/app:buildcache
    cache-to: type=registry,ref=ghcr.io/acme/app:buildcache,mode=max

Zwei Jobs, die gleichzeitig starten, stellen denselben Cache wieder her und bauen beide die fehlenden Layer. Das passiert in jedem CI, werten Sie es also nicht als Problem des Anbieters.

CRACI bietet Container Layer Caching mit einem lokalen Layer-Cache, einem Remote-Layer-Cache und einem Bind-Mount-Cache.

Secrets, OIDC und Cloud-Zugangsdaten

GitHub speichert Ihre Secrets und liefert sie an den Runner, der den Job ausführt. Einen Job zu einem Anbieter zu verschieben heißt, diesem Anbieter die Secrets dieses Jobs anzuvertrauen. Fragen Sie:

• Erhält jeder Job eine eigene virtuelle Maschine oder einen Container auf einem geteilten Host?
• Wird die Maschine nach dem Job zerstört, und wird etwas aufbewahrt?
• Welche Logs bewahrt der Anbieter auf? GitHub maskiert registrierte Secrets in Job-Logs und sagt, dass die automatische Schwärzung transformierter Werte nicht garantiert ist; fragen Sie auch nach den eigenen Systemlogs des Anbieters.

OIDC funktioniert weiter, mit einem Haken. GitHub stellt das OIDC-Token aus, nicht der Runner, sodass permissions: id-token: write auf jedem Runner funktioniert. Der Claim runner_environment des Tokens ist jedoch github-hosted oder self-hosted (GitHubs OIDC-Referenz), und auf einem Drittanbieter-Runner ist er self-hosted. Eine Cloud-Vertrauensrichtlinie, die github-hosted verlangt, lehnt den Job ab. Zum Beispiel ein Workload Identity Pool in Google Cloud mit dieser Attributbedingung:

# Before: only GitHub-hosted runners in the acme organization
assertion.repository_owner == 'acme' && assertion.runner_environment == 'github-hosted'

# After: drop the runner check, and narrow by repository and branch instead
assertion.repository == 'acme/app' && assertion.ref == 'refs/heads/main'

Wer die Runner-Prüfung entfernt, erweitert den Kreis derer, die Zugangsdaten erhalten können; verschärfen Sie daher gleichzeitig eine andere Bedingung. Durchsuchen Sie vor dem Wechsel jede Cloud-Vertrauensrichtlinie und jede Workload-Identity-Konfiguration nach runner_environment.

Images pushen: GITHUB_TOKEN mit packages: write pusht von jedem Runner in die GitHub Container Registry, und Registry-Logins mit gespeicherten Secrets funktionieren unverändert.

Bei CRACI liest die GitHub App Ihren Code und Ihre Actions-Läufe und verwaltet die Runner, die sie für Ihre Organisation registriert. Jeder Job läuft in einer eigenen isolierten virtuellen Maschine, und CRACI speichert Ihren Quellcode nicht.

Netzwerkidentität: IP-Allowlists und Egress

Der neue Runner verbindet sich von neuen IP-Adressen aus. Listen Sie alles auf, was nach Quelladresse filtert:

• Allowlists von Datenbanken und Artefakt-Repositories;
• SaaS-APIs mit IP-Beschränkungen;
• SFTP-Server von Partnern und interne Dienste hinter einer Firewall.

Die Optionen sind statische oder stabile Egress-IP-Adressen des Anbieters oder ein Proxy, den Sie kontrollieren. Das ist auch der Moment, um zu entscheiden, was Jobs überhaupt erreichen dürfen: Eine Egress-Richtlinie auf dem Runner hindert eine kompromittierte Abhängigkeit daran, Secrets an einen Host zu senden, den der Build nie gebraucht hat. Siehe Egress-Richtlinie für GitHub Actions.

CRACI bietet einen stabilen Egress-IP-Bereich und eine Egress-Richtlinie, Default Deny oder Allow, die vor dem Jobstart validiert wird und im Fehlerfall blockiert. Ohne network-Input erlaubt die Standardvorlage andere ausgehende Verbindungen; die Egress-Kontrolle ist also etwas, das Sie konfigurieren.

Gemischte Flotten: Linux verschieben, macOS und iOS behalten

Der Runner wird pro Job gewählt, sodass ein Workflow seine Linux-Jobs bei einem Anbieter und seine macOS-Jobs auf GitHub-gehosteten Runnern ausführen kann. Mit actions/upload-artifact hochgeladene Artefakte speichert GitHub, sodass ein Job auf einem Runner Dateien an einen Job auf einem anderen übergeben kann.

jobs:
  backend:
    runs-on: ${{ vars.LINUX_RUNNER || 'ubuntu-latest' }}
    steps:
      - uses: actions/checkout@v7
      - run: ./gradlew test

  android:
    runs-on: ${{ vars.LINUX_RUNNER || 'ubuntu-latest' }}
    steps:
      - uses: actions/checkout@v7
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v7
        with:
          name: android
          path: app/build/outputs/apk/release/

  ios:
    # Signing and the iOS build stay on GitHub-hosted macOS
    runs-on: macos-latest
    needs: backend
    steps:
      - uses: actions/checkout@v7
      - run: xcodebuild -scheme App -configuration Release archive

Die Jobs, die bei GitHub bleiben, verbrauchen weiterhin das enthaltene Kontingent Ihres Plans und werden darüber hinaus von GitHub abgerechnet. CRACI betreibt heute Linux auf x86-64 und ARM64, Windows und macOS stehen auf der Roadmap; eine gemischte Flotte mit CRACI heißt also CRACI für Linux und GitHub-gehostete Runner für den Rest.

Fallback, wenn ein Anbieter ausfällt

GitHub hat keinen eingebauten Fallback zwischen Runner-Labels. Ist kein Runner für das Label online, wartet der Job, und nach 24 Stunden schlägt er fehl. Planen Sie dafür:

• Der Variablen-Schalter von oben: Setzen Sie ihn zurück auf ubuntu-latest, und neue Läufe gehen an GitHub-gehostete Runner.
• Eine manuelle Übersteuerung für dringende Läufe: ein workflow_dispatch-Input, gelesen als runs-on: ${{ inputs.runner || vars.LINUX_RUNNER || 'ubuntu-latest' }}.
• timeout-minutes für Jobs, damit ein hängender Job kein Deployment stundenlang blockiert.
• Überwachung der Wartezeit, damit Sie merken, wenn Jobs länger als üblich warten.

Fragen Sie jeden Anbieter, ob er einen automatischen Fallback bietet und was ihn auslöst. Planen Sie auch für die andere Richtung: GitHub reiht jeden Job ein und weist ihn zu, daher stoppt ein Ausfall von GitHub Actions auch die Jobs bei jedem Runner-Anbieter.

Abrechnung: Berechnet GitHub weiterhin?

GitHub berechnet für selbst gehostete Runner nichts pro Minute, und Drittanbieter-Runner registrieren sich als selbst gehostet, sodass die verschobenen Minuten nicht mehr auf der GitHub-Rechnung erscheinen (Abrechnung von GitHub Actions). GitHub berechnet weiterhin:

• Seats Ihres Plans;
• Artefakt- und Cache-Speicher, den es über das enthaltene Kontingent hinaus vorhält;
• Jobs, die auf GitHub-gehosteten Runnern bleiben, über das enthaltene Kontingent Ihres Plans hinaus, das nicht erstattet wird.

Während des Pilotbetriebs zahlen Sie zwei Rechnungen. Anbieter zählen Build-Minuten unterschiedlich: GitHub rundet jeden Job auf die volle Minute auf, manche Anbieter messen sekundengenau. Um Ihre Nutzung vorher und nachher abzuschätzen, nutzen Sie den Kostenrechner für GitHub Actions. CRACI berechnet nur Build-Minuten: $0.002 pro vCPU-Minute ($0.004 für einen Standard-Runner mit 2 vCPU), sekundengenau abgerechnet, ohne Monatsgebühr.

Sicherheitsisolation: Was Sie jeden Anbieter fragen sollten

Frage	Warum sie zählt
Eine virtuelle Maschine pro Job oder Container auf einem geteilten Host?	Auf einem geteilten Host kann ein kompromittierter Job seine Nachbarn erreichen
Wird die Maschine nach dem Job zerstört?	Eine persistente Maschine trägt Dateien, Zugangsdaten und Prozesse in den nächsten Job
Wo steht die Hardware, und wer betreibt sie?	Datenstandort, Rechtsraum und die Verträge Ihrer Kunden
Was speichert der Anbieter, und wie lange?	Logs, Caches und Netzwerkdaten können sensibles Material enthalten
Welche Zertifizierungen hat er?	Ihre Lieferantenprüfung wird danach fragen
Können Sie den Egress kontrollieren?	Verhindert, dass Secrets über ein bösartiges Paket abfließen
Was kann seine GitHub App lesen und ändern?	Die Berechtigungen der App gelten für jedes Repository, auf dem Sie sie installieren

Laut GitHub sollten selbst gehostete Runner fast nie für öffentliche Repositories verwendet werden, weil jeder einen Pull Request öffnen und die Umgebung kompromittieren kann, und Just-in-Time-Runner führen höchstens einen Job aus, bevor sie entfernt werden (GitHubs Referenz zur sicheren Nutzung). Eine frische virtuelle Maschine pro Job beantwortet den Großteil dieser Bedenken.

CRACIs Antworten: Jeder Job läuft in einer eigenen isolierten virtuellen Maschine auf europäischer Bare-Metal-Infrastruktur. Das Informationssicherheits-Managementsystem der CRACI Corporation Oy für die Entwicklung und den Betrieb der CRACI-Plattform ist von Into Certification nach ISO/IEC 27001 zertifiziert, Details finden Sie im Trust Center. CRACI speichert Build-Metadaten, Paketdaten, Netzwerk-Traces, SBOMs, Provenance, Caches und Audit-Datensätze, aber niemals Ihren Quellcode. Siehe worauf CRACI zugreifen kann und Sicherheit.

Testen Sie zuerst ein Repository

1. Wählen Sie ein Repository mit einem repräsentativen, häufig laufenden Linux-Workflow, nicht die Release-Pipeline.
2. Erfassen Sie eine Baseline auf GitHub-gehosteten Runnern: mittlere Dauer und Wartezeit der letzten 30 Läufe sowie abgerechnete Minuten.
3. Installieren Sie die GitHub App des Anbieters nur auf diesem Repository.
4. Stellen Sie einen Job über die Repository-Variable um, auf einem Branch.
5. Führen Sie ihn mindestens zehnmal aus und verwerfen Sie die ersten drei als Cache-Aufwärmphase.
6. Vergleichen Sie Dauer, Wartezeit, Cache-Trefferquote, Fehlschläge und Kosten; prüfen Sie Logs, OIDC und ausgehende Aufrufe.
7. Wechseln Sie zurück, indem Sie die Variable ändern, und bestätigen Sie, dass der Job wieder auf GitHub-gehosteten Runnern läuft.

Metrik	Baseline GitHub-gehostet	Anbieter	Schwelle zum Bestehen
Mittlere Jobdauer			Ihr Ziel, zum Beispiel 30 % kürzer
Mittlere Wartezeit			Nicht schlechter als die Baseline
Cache-Trefferquote nach dem Aufwärmen			Wie die Baseline
Fehlgeschlagene Läufe, die nicht am Code liegen			Keine
Kosten pro Lauf			Unter der Baseline
OIDC, Allowlists und ausgehende Aufrufe			Alles funktioniert

Messen Sie die Geschwindigkeit an Ihrem eigenen Workflow. Jeder Anbieter veröffentlicht eigene Zahlen, und die einzige Zahl, die in Ihrem Fall entscheidet, ist die aus Ihrer Pipeline.

Wo CRACI passt

CRACI ist ein GitHub-Actions-Runner. Es ersetzt den Runner, nicht GitHub Actions: Ein Job zieht mit runs-on: craci um, Größen und Images werden mit cracicorp/setup@v1 oder einer Runner-Vorlage der Organisation festgelegt, und Läufe erscheinen weiterhin in GitHub. CRACI führt Builds etwa doppelt so schnell aus wie GitHub-gehostete Runner, dank schnellerer Hardware, kürzerer Wartezeiten und Caching.

Der Grund, es anderen Anbietern vorzuziehen, ist das, was jeder Job hinterlässt: eine SBOM dessen, was der Build abgerufen hat, mit einem Vollständigkeitsstatus, erfasst unter einer Egress-Richtlinie, die im Fehlerfall blockiert. docs.craci.com bietet außerdem einen Prompt für Coding-Agents, der einen Migrationsplan pro Job für Ihre Workflows vorschlägt. Siehe CI/CD-Integration.

Wann CRACI nicht die Antwort ist

• Sie brauchen macOS- oder Windows-Runner: Sie stehen auf CRACIs Roadmap.
• Sie nutzen GitHub Enterprise Server, das CRACI nicht unterstützt.
• Ihr CI ist GitLab CI oder Jenkins: Beide stehen auf der Roadmap.
• Runner müssen in Ihrem eigenen Cloud-Konto laufen: Vom Kunden gehostete Runner stehen auf der Roadmap. RunsOn und die Bring-your-own-Cloud-Option von WarpBuild leisten das heute; siehe CRACI vs RunsOn und CRACI vs WarpBuild.
• Ihr Hauptziel ist CI-Observability und Debugging; siehe CRACI vs Avrea. Für den Betrieb eigener Runner siehe verwaltete vs. selbst gehostete Runner.

Runner-Anbieter wechseln: häufig gestellte Fragen

Was muss ich ändern, um einen anderen Runner-Anbieter für GitHub Actions zu nutzen?

Installieren Sie die GitHub App des Anbieters und ändern Sie das runs-on-Label des Jobs auf das Label des Anbieters. Workflows, Trigger, Secrets und die GitHub-Oberfläche bleiben gleich. Bevor Sie wichtige Jobs verschieben, prüfen Sie das Runner-Image, Caches, ausgehende IP-Adressen, Cloud-Vertrauensrichtlinien mit OIDC, Fallback und Abrechnung.

Werden meine GitHub-Actions-Caches zu einem neuen Runner-Anbieter übernommen?

Das hängt davon ab, woher der Anbieter den Cache bereitstellt. Nutzen seine Runner den Cache-Dienst von GitHub, werden vorhandene Einträge wiederhergestellt. Stellt er die Cache-API aus Speicher neben seinen Runnern bereit, beginnt der Cache meist leer und füllt sich in den ersten Läufen. Fragen Sie den Anbieter, welches Modell er nutzt und ob Einträge, die auf seinen Runnern geschrieben werden, für GitHub-gehostete Runner sichtbar sind.

Funktioniert Docker Layer Caching auf Runnern von Drittanbietern?

Ja, mit einem von drei Mechanismen: dem BuildKit-Backend type=gha, das den Actions-Cache nutzt; einem Registry-Cache mit type=registry, der auf jedem Runner funktioniert; oder einem Layer-Cache bzw. einer persistenten Festplatte, die der Anbieter neben seinen Runnern vorhält.

Kann ich macOS- und iOS-Builds auf GitHub lassen, während Linux-Jobs umziehen?

Ja. Der Runner wird pro Job gewählt, sodass Linux-Jobs bei einem Anbieter laufen können, während macOS-Jobs im selben Workflow auf GitHub-gehosteten Runnern bleiben. Verbinden Sie sie mit needs: und übergeben Sie Dateien mit actions/upload-artifact und actions/download-artifact, die GitHub speichert.

Was passiert mit einem Job, wenn der Runner des Drittanbieters ausfällt? Gibt es einen Fallback?

GitHub hat keinen eingebauten Fallback zwischen Runner-Labels. Ein Job, zu dessen Label kein Runner online ist, bleibt in der Warteschlange und schlägt nach 24 Stunden fehl. Legen Sie das Label in einer Repository- oder Organisationsvariable ab, damit der Wechsel zurück eine einzige Änderung ist, setzen Sie timeout-minutes und fragen Sie jeden Anbieter, ob er einen eigenen Fallback bietet.

Funktionieren Secrets und OIDC auf Runnern von Drittanbietern weiterhin?

Ja. GitHub speichert die Secrets und liefert sie beim Jobstart an den Runner, und GitHub stellt das OIDC-Token aus, sodass id-token: write auf jedem Runner funktioniert. Der Haken: Der Claim runner_environment des Tokens ist auf einem Drittanbieter-Runner self-hosted, sodass eine Cloud-Vertrauensrichtlinie, die github-hosted verlangt, den Job ablehnt.

Berechnet mir GitHub weiterhin Minuten, wenn ich einen anderen Runner-Anbieter nutze?

Nicht für die Jobs, die Sie verschieben. Runner von Drittanbietern registrieren sich bei GitHub als selbst gehostete Runner, und für selbst gehostete Runner fallen laut GitHub keine Minutengebühren an. GitHub berechnet weiterhin Seats, Speicher über das enthaltene Kontingent hinaus und Jobs, die auf GitHub-gehosteten Runnern bleiben. Der Anbieter rechnet seine eigenen Minuten ab.

Wie pinne ich das Runner-Image, damit es sich nicht unbemerkt ändert?

ubuntu-latest wechselt nach GitHubs Zeitplan, und ubuntu-24.04 pinnt das Betriebssystem-Release, aber nicht die Paketversionen darauf. Pinnen Sie, was zählt, im Job selbst: Setup-Actions mit expliziten Versionen und Container-Images per Digest. Fragen Sie jeden Anbieter, was Sie pinnen können; die Runner-Anwendung selbst muss sich aktualisieren, um mit GitHub kompatibel zu bleiben.

Wie sind Jobs auf einem Drittanbieter-Runner voneinander isoliert?

Das unterscheidet sich je nach Anbieter. Fragen Sie, ob jeder Job eine eigene virtuelle Maschine oder einen Container auf einem geteilten Host erhält, ob die Maschine nach dem Job zerstört wird und was der Anbieter danach aufbewahrt. Eine frische virtuelle Maschine pro Job ist das stärkste der gängigen Modelle, weil von einem Job nichts für den nächsten übrig bleibt.

Wie teste ich einen Runner-Anbieter zuerst an einem Repository?

Installieren Sie die GitHub App des Anbieters auf einem Repository, stellen Sie einen häufig laufenden Linux-Job über eine Repository-Variable auf einem Branch um, führen Sie ihn mindestens zehnmal aus und vergleichen Sie Dauer, Wartezeit, Cache-Treffer, Fehlschläge und Kosten mit einer Baseline auf GitHub-gehosteten Runnern. Zurück geht es, indem Sie die Variable ändern.