Van GitHub Actions-runneraanbieder wisselen: labels, caches, secrets, facturering en fallback

Deze gids is leveranciersneutraal. Hij legt uit wat er verhuist als u van GitHub Actions-runneraanbieder wisselt, wat het vaakst stukgaat en hoe u terugdraait. Wij bouwen CRACI, een van de aanbieders; het komt aan bod waar een gedocumenteerd feit van toepassing is, en in een eigen sectie aan het eind. Om eerst een aanbieder te kiezen, zie aanbieders van GitHub Actions-runners vergeleken en alternatieven voor door GitHub gehoste runners.

Wat verandert en wat blijft als u wisselt

GitHub Actions bestaat uit twee helften. GitHub is het control plane: het slaat de repository en de workflowbestanden op, activeert de triggers, slaat secrets op, wijst jobs toe, toont logs en checks, bewaart artefacten en geeft OIDC-tokens uit. De CI-runner is waar een job wordt uitgevoerd: een machine met een image, CPU, schijf, een netwerkpad naar internet en meestal een lokale cache. GitHub wijst een job toe aan een runner, levert de secrets van de job bij de start, en de runner streamt de logs terug.

Een runneraanbieder vervangt alleen de tweede helft.

Onderdeel	Blijft bij GitHub	Gaat naar de aanbieder
Repository, workflowbestanden, triggers	Ja	Nee
Opslag van secrets	Ja	Secrets worden bij de start van de job aan de machine van de aanbieder geleverd
Toewijzing van jobs, logs, checks-interface	Ja	De runner streamt logs terug
Artefacten uit actions/upload-artifact	Ja	Nee
Uitgever van OIDC-tokens	Ja	Nee, maar het token zegt dat de runner self-hosted is
Machine, image, CPU, geheugen, schijf	Nee	Ja
Uitgaand netwerkpad en IP-adressen	Nee	Ja
Cacheopslag	Hangt af van de aanbieder	Hangt af van de aanbieder
Facturering per minuut voor de verplaatste jobs	Nee	Ja

Een runner van derden registreert zich bij GitHub als self-hosted runner. Daarom gelden de regels van GitHub voor self-hosted runners ook voor hem: hoe labels jobs routeren, hoe runnergroepen de toegang beperken, hoe het OIDC-token hem beschrijft en hoe GitHub hem factureert.

De wijziging in runs-on en labels

GitHub zoekt een runner die past bij de labels en groepen in runs-on van de job. Is er geen passende runner online, dan blijft de job in de wachtrij tot er een online komt; pakt een toegewezen runner de job niet binnen 60 seconden op, dan gaat hij opnieuw in de wachtrij; en een job die langer dan 24 uur in de wachtrij staat, mislukt (referentie van GitHub voor self-hosted runners). Een typfout in een label, of een app van de aanbieder die niet op de repository is geïnstalleerd, ziet u als een job die nooit start.

Aanbieders leggen de machine op een van twee manieren vast:

• In het label. Ubicloud gebruikt labels zoals ubicloud-standard-2, Blacksmith blacksmith-2vcpu-ubuntu-2404 en Avrea avrea-ubuntu-latest-2-vcpu, met arm in het label voor ARM-machines. Een andere grootte betekent een ander label.
• In een setupstap. CRACI gebruikt één label, runs-on: craci, en de stap cracicorp/setup@v1 kiest de grootte (1 tot 32 rekeneenheden van 1 vCPU en 3 GB, standaard 2), het image, het netwerkbeleid of een runnertemplate van de organisatie via de slug. Kan CRACI een invoer niet parsen, dan draait het de standaardomgeving en schrijft het een waarschuwing in de joblog; een onbekend image of template wordt geweigerd.

Maak de omschakeling één variabele

Zet het label in een repository- of organisatievariabele in plaats van het hard te coderen. Heen of terug schakelen is dan een wijziging in de instellingen, geen pull request in elke 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

De keuze geldt per job, dus build- en testjobs kunnen verhuizen terwijl een deployjob blijft. Variabelen kunt u op organisatieniveau instellen en per repository overschrijven, zodat één instelling een groep repositories verplaatst en één repository zich kan afmelden.

Herbruikbare workflows

Wordt dezelfde pipeline naar veel repositories gekopieerd, zet hem dan in een herbruikbare workflow die de runner uit een input of een variabele leest. Een wijziging in runs-on daar verandert elke repository die hem aanroept. Met rulesets kunt u vereisen dat een workflow draait op de repositories van een organisatie, zodat de gedeelde versie in gebruik blijft.

Runnerimages: compatibiliteit en pinnen

Het gehoste image van GitHub bevat een grote vooraf geïnstalleerde gereedschapsset en een gehoste tool cache. Aanbieders bieden een image dat compatibel is met dat van GitHub, of een slanker image. Jobs zijn vaak afhankelijk van dingen die ze nooit declareren:

• vooraf geïnstalleerde taalversies en commandoregeltools;
• sudo zonder wachtwoord, en systemd voor services die met systemctl worden gestart;
• een draaiende Docker-daemon, met Buildx en Compose;
• de gehoste tool cache die setup-*-actions lezen voordat ze downloaden;
• vrije schijfruimte voor grote builds.

Beslisregel: begin op het GitHub-compatibele image van de aanbieder. Verplaats een job pas naar een slank image als hij groen is, en voeg expliciete setup-*-stappen toe voor alles wat hij impliciet gebruikte.

Pinnen: ubuntu-latest gaat volgens het schema van GitHub naar een nieuwe release, en ubuntu-24.04 pint de release van het besturingssysteem, niet de pakketversies daarop. Pin wat ertoe doet binnen de job: setup-actions met expliciete versies, en containerimages op digest. Vraag elke aanbieder wat u kunt pinnen. De runnerapplicatie zelf moet blijven updaten om met GitHub te kunnen communiceren.

Op CRACI zijn de images CRACI Slim op x86-64 en ARM64 (Ubuntu 24.04, zonder systemd) en een volledig met GitHub Actions compatibel Ubuntu 24.04-image, te kiezen als ubuntu-24.04 of ubuntu-latest, dat het Ubuntu 24.04-runnerimage van GitHub volgt en de gehoste tool cache bevat. Elk image heeft Docker Engine, Buildx en Compose v2.

Caches: wat meegaat en wat koud begint

De eerste runs bij een nieuwe aanbieder zijn vaak trager, en de gebruikelijke reden is een koude cache, geen trage machine. Hoe actions/cache werkt, bepaalt wat u ziet (README van actions/cache):

• Een entry wordt gevonden via zijn sleutel en een versie, een hash van de gecachete paden en de compressietool.
• Entries zijn per branch afgebakend; de entries van de standaardbranch zijn beschikbaar voor andere branches.
• Standaard kan een repository tot 10 GB aan caches bevatten voordat de oudste entries worden verwijderd. Repositorybeheerders en eigenaren van de organisatie of enterprise kunnen de limiet verhogen; gebruik boven 10 GB wordt aan het account gefactureerd (GitHub over dependency caching).
• Een cache die op Windows is opgeslagen, wordt niet hersteld op een ander besturingssysteem, of omgekeerd, tenzij enableCrossOsArchive is ingesteld; een andere compressietool geeft ook een andere versie.

Aanbieders serveren de cache op een van twee manieren:

Model	Eerste runs	Afweging
De runner gebruikt de cacheservice van GitHub, zoals door GitHub gehoste runners	Bestaande entries worden hersteld	Cacheverkeer gaat over internet tussen de aanbieder en GitHub
De aanbieder serveert de cache-API vanuit opslag naast zijn runners	Meestal leeg tot de eerste runs hem vullen, tenzij de aanbieder de entries van GitHub importeert of erop terugvalt	Sneller herstel; entries die daar worden geschreven, zijn meestal niet zichtbaar voor door GitHub gehoste runners

Dat tweede punt telt voor gemengde vloten en voor terugdraaien: schakelt u een job terug, dan kan hij ook op GitHub koud beginnen. Vraag welk model de aanbieder gebruikt en waar de entries staan.

Een koude cache onderscheiden van een trage runner. Neem een Node-build die een grote map node_modules cachet. Bij de eerste run bij een nieuwe aanbieder meldt actions/cache een miss, downloadt de installatiestap alles en slaat de post-stap de cache op. Vanaf de volgende run op dezelfde branch meldt de stap een hit en wordt de installatiestap korter. Vergelijk runs pas als de cache warm is: lees de output cache-hit, en meet de herstelstap en de installatiestap los van de build zelf. Zie hoe de GitHub Actions-cache werkt voor sleutels, scopes en cache poisoning.

Op CRACI werkt actions/cache zoals nu, en het buildrecord geeft per pakket aan of het uit een CI-cache is hersteld in plaats van opgehaald.

Docker-layercaching

Mechanisme	Waar de layers staan	Wat u moet weten
BuildKit type=gha	De GitHub Actions-cache	Dezelfde afbakening en groottelimieten als hierboven; hij vereist een builder die hem ondersteunt
BuildKit type=registry	Een apart image in uw registry	Werkt op elke runner en overleeft een wissel van aanbieder; u betaalt registryopslag en -verkeer
Lokale layercache of persistente schijf van de aanbieder	Naast de runners van de aanbieder	Meestal het snelst; blijft achter als u de aanbieder verlaat

Een registrycache is de draagbare optie (Docker-cachebackends):

- 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

Twee jobs die tegelijk starten, herstellen dezelfde cache en bouwen allebei de layers die erin ontbreken. Dat gebeurt in elke CI, dus zie het niet als een probleem van de aanbieder.

CRACI biedt containerlayercaching met een lokale layercache, een externe layercache en een bind-mountcache.

Secrets, OIDC en cloudreferenties

GitHub slaat uw secrets op en levert ze aan de runner die de job draait. Een job naar een aanbieder verplaatsen betekent die aanbieder vertrouwen met de secrets van die job. Vraag:

• Krijgt elke job een eigen virtuele machine, of een container op een gedeelde host?
• Wordt de machine na de job vernietigd, en blijft er iets bewaard?
• Welke logs bewaart de aanbieder? GitHub maskeert geregistreerde secrets in joblogs, en zegt dat automatische redactie niet gegarandeerd is voor getransformeerde waarden; vraag ook naar de eigen systeemlogs van de aanbieder.

OIDC blijft werken, met één addertje. GitHub geeft het OIDC-token uit, niet de runner, dus permissions: id-token: write werkt op elke runner. Maar de claim runner_environment van het token is github-hosted of self-hosted (OIDC-referentie van GitHub), en op een runner van derden is die self-hosted. Een cloudvertrouwensbeleid dat github-hosted vereist, weigert de job. Bijvoorbeeld een workload identity pool in Google Cloud met deze attribuutvoorwaarde:

# 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'

Wie de runnercontrole verwijdert, vergroot de kring die referenties kan krijgen, dus maak tegelijk een andere voorwaarde strenger. Doorzoek vóór de omschakeling elk cloudvertrouwensbeleid en elke workload identity-configuratie op runner_environment.

Images pushen: GITHUB_TOKEN met packages: write pusht vanaf elke runner naar GitHub Container Registry, en registrylogins met opgeslagen secrets werken ongewijzigd.

Op CRACI leest de GitHub App uw code en uw Actions-runs en beheert hij de runners die hij voor uw organisatie registreert. Elke job draait in een eigen geïsoleerde virtuele machine, en CRACI slaat uw broncode niet op.

Netwerkidentiteit: IP-allowlists en egress

De nieuwe runner gaat naar buiten vanaf nieuwe IP-adressen. Inventariseer alles wat op bronadres filtert:

• allowlists van databases en artefactrepositories;
• SaaS-API's met IP-beperkingen;
• SFTP-servers van partners en interne services achter een firewall.

De opties zijn statische of stabiele egress-IP-adressen van de aanbieder, of een proxy die u zelf beheert. Dit is ook het moment om te bepalen wat jobs überhaupt mogen bereiken: een egressbeleid op de runner voorkomt dat een gecompromitteerde dependency secrets naar een host stuurt die de build nooit nodig had. Zie egressbeleid voor GitHub Actions.

CRACI biedt een stabiel egress-IP-bereik en een egressbeleid, standaard weigeren of toestaan, dat wordt gevalideerd voordat de job start en fail-closed werkt. Zonder invoer network staat de standaardtemplate andere uitgaande verbindingen toe, dus egresscontrole is iets wat u configureert.

Gemengde vloten: verplaats Linux, houd macOS en iOS waar ze zijn

De runner wordt per job gekozen, dus één workflow kan zijn Linux-jobs bij een aanbieder draaien en zijn macOS-jobs op door GitHub gehoste runners. Artefacten die met actions/upload-artifact worden geüpload, slaat GitHub op, zodat een job op de ene runner bestanden kan doorgeven aan een job op een andere.

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

De jobs die op GitHub blijven, verbruiken nog steeds het inbegrepen gebruik van uw plan en worden daarboven door GitHub gefactureerd. CRACI draait vandaag Linux op x86-64 en ARM64, met Windows en macOS op de roadmap, dus een gemengde vloot met CRACI betekent CRACI voor Linux en door GitHub gehoste runners voor de rest.

Fallback als een aanbieder uitvalt

GitHub heeft geen ingebouwde fallback tussen runnerlabels. Is er geen runner voor het label online, dan wacht de job, en na 24 uur mislukt hij. Houd er rekening mee:

• De variabele-omschakeling hierboven: zet hem terug op ubuntu-latest en nieuwe runs gaan naar door GitHub gehoste runners.
• Een handmatige override voor dringende runs: een input van workflow_dispatch, gelezen als runs-on: ${{ inputs.runner || vars.LINUX_RUNNER || 'ubuntu-latest' }}.
• timeout-minutes op jobs, zodat een job die vastloopt een deployment niet urenlang ophoudt.
• Monitoring van de wachttijd, zodat u merkt wanneer jobs langer wachten dan normaal.

Vraag elke aanbieder of hij een automatische fallback biedt en wat die activeert. Houd ook rekening met de andere richting: GitHub zet elke job in de wachtrij en wijst hem toe, dus een storing van GitHub Actions stopt ook de jobs bij elke runneraanbieder.

Facturering: rekent GitHub nog?

GitHub rekent geen minuutprijs voor self-hosted runners, en runners van derden registreren zich als self-hosted, dus de minuten die u verplaatst, verdwijnen van de GitHub-factuur (facturering van GitHub Actions). GitHub factureert nog wel:

• seats in uw plan;
• opslag van artefacten en caches die het bewaart boven het inbegrepen tegoed;
• jobs die op door GitHub gehoste runners blijven, boven het inbegrepen gebruik van uw plan, dat niet wordt terugbetaald.

Tijdens de pilot betaalt u twee facturen. Aanbieders tellen buildminuten verschillend: GitHub rondt elke job af naar boven op een hele minuut, en sommige aanbieders meten per seconde. Gebruik de kostencalculator voor GitHub Actions om uw gebruik voor en na in te schatten. CRACI rekent alleen buildminuten: $0.002 per vCPU-minuut ($0.004 voor een standaardrunner met 2 vCPU), per seconde gemeten, zonder maandelijkse kosten.

Beveiligingsisolatie: wat u elke aanbieder vraagt

Vraag	Waarom het ertoe doet
Eén virtuele machine per job, of containers op een gedeelde host?	Op een gedeelde host kan een gecompromitteerde job zijn buren bereiken
Wordt de machine na de job vernietigd?	Een persistente machine neemt bestanden, referenties en processen mee naar de volgende job
Waar staat de hardware, en wie beheert die?	Datalocatie, jurisdictie en de contracten van uw klanten
Wat slaat de aanbieder op, en hoe lang?	Logs, caches en netwerkgegevens kunnen gevoelig materiaal bevatten
Welke certificeringen heeft hij?	Uw leveranciersbeoordeling vraagt ernaar
Kunt u egress beheersen?	Voorkomt dat secrets via een kwaadaardig pakket vertrekken
Wat kan zijn GitHub App lezen en wijzigen?	De rechten van de app gelden voor elke repository waarop u hem installeert

GitHub zegt dat self-hosted runners vrijwel nooit voor openbare repositories gebruikt moeten worden, omdat iedereen een pull request kan openen en de omgeving kan compromitteren, en dat just-in-time-runners hooguit één job draaien voordat ze worden verwijderd (referentie van GitHub voor veilig gebruik). Een nieuwe virtuele machine per job neemt het grootste deel van die zorg weg.

De antwoorden van CRACI: elke job draait in een eigen geïsoleerde virtuele machine op Europese bare-metalinfrastructuur. Het managementsysteem voor informatiebeveiliging van CRACI Corporation Oy, voor de ontwikkeling en exploitatie van het CRACI-platform, is ISO/IEC 27001-gecertificeerd door Into Certification, met details in het Trust Center. CRACI slaat buildmetadata, pakketgegevens, netwerktraces, SBOM's, provenance, caches en auditrecords op, en nooit uw broncode. Zie wat CRACI kan bereiken en beveiliging.

Test eerst met één repository

1. Kies een repository met een representatieve, vaak gedraaide Linux-workflow, niet de releasepipeline.
2. Leg een baseline vast op door GitHub gehoste runners: mediane duur en wachttijd over de laatste 30 runs, en gefactureerde minuten.
3. Installeer de GitHub App van de aanbieder alleen op die repository.
4. Schakel één job om via de repositoryvariabele, op een branch.
5. Draai hem minstens tien keer, en negeer de eerste drie als opwarming van de cache.
6. Vergelijk duur, wachttijd, cachehitratio, fouten en kosten; controleer logs, OIDC en uitgaande verbindingen.
7. Draai terug door de variabele te wijzigen, en controleer dat de job teruggaat naar door GitHub gehoste runners.

Meetwaarde	Baseline door GitHub gehost	Aanbieder	Drempel om te slagen
Mediane jobduur			Uw doel, bijvoorbeeld 30% korter
Mediane wachttijd			Niet slechter dan de baseline
Cachehitratio na opwarming			Gelijk aan de baseline
Mislukte runs die niet door de code komen			Geen
Kosten per run			Onder de baseline
OIDC, allowlists en uitgaande verbindingen			Alles werkt

Meet snelheid op uw eigen workflow. Elke aanbieder publiceert zijn eigen cijfers, en het enige getal dat voor u beslist, is dat van uw pipeline.

Waar CRACI past

CRACI is een GitHub Actions-runner. Het vervangt de runner, niet GitHub Actions: een job verhuist met runs-on: craci, groottes en images stelt u in met cracicorp/setup@v1 of een runnertemplate van de organisatie, en runs blijven in GitHub verschijnen. CRACI draait builds ongeveer twee keer zo snel als door GitHub gehoste runners, dankzij snellere hardware, kortere wachttijden en caching.

De reden om het boven andere aanbieders te kiezen, is wat elke job achterlaat: een SBOM van wat de build ophaalde, met een volledigheidsstatus, vastgelegd onder een egressbeleid dat fail-closed werkt. docs.craci.com biedt ook een prompt voor codeeragents die per job een migratieplan voor uw workflows voorstelt. Zie CI/CD-integratie.

Wanneer CRACI niet het antwoord is

• U hebt macOS- of Windows-runners nodig: die staan op de roadmap van CRACI.
• U gebruikt GitHub Enterprise Server, dat CRACI niet ondersteunt.
• Uw CI is GitLab CI of Jenkins: beide staan op de roadmap.
• Runners moeten in uw eigen cloudaccount staan: door de klant gehoste runners staan op de roadmap. RunsOn en de bring-your-own-cloud-optie van WarpBuild doen dat vandaag; zie CRACI vs RunsOn en CRACI vs WarpBuild.
• Uw hoofddoel is CI-observability en debugging; zie CRACI vs Avrea. Voor het draaien van uw eigen runners, zie beheerde vs self-hosted runners.

Van runneraanbieder wisselen: veelgestelde vragen

Wat moet ik wijzigen om een andere aanbieder van GitHub Actions-runners te gebruiken?

Installeer de GitHub App van de aanbieder en wijzig het label runs-on van de job in het label van de aanbieder. Workflows, triggers, secrets en de GitHub-interface blijven hetzelfde. Controleer voordat u belangrijke jobs verplaatst het runnerimage, de caches, uitgaande IP-adressen, cloudvertrouwensbeleid dat OIDC gebruikt, fallback en facturering.

Gaan mijn GitHub Actions-caches mee naar een nieuwe runneraanbieder?

Dat hangt af van waar de aanbieder de cache vandaan serveert. Gebruiken zijn runners de cacheservice van GitHub, dan worden bestaande entries hersteld. Serveert hij de cache-API vanuit opslag naast zijn runners, dan begint de cache meestal leeg en vult hij zich bij de eerste runs. Vraag de aanbieder welk model hij gebruikt en of entries die op zijn runners zijn geschreven zichtbaar zijn voor door GitHub gehoste runners.

Werkt Docker-layercaching op runners van derden?

Ja, met een van drie mechanismen: de backend type=gha van BuildKit, die de Actions-cache gebruikt; een registrycache met type=registry, die op elke runner werkt; of een layercache of persistente schijf die de aanbieder naast zijn runners bijhoudt.

Kan ik macOS- en iOS-builds op GitHub houden terwijl Linux-jobs verhuizen?

Ja. De runner wordt per job gekozen, dus Linux-jobs kunnen bij een aanbieder draaien terwijl macOS-jobs in dezelfde workflow op door GitHub gehoste runners blijven. Koppel ze met needs: en geef bestanden door met actions/upload-artifact en actions/download-artifact, die GitHub opslaat.

Wat gebeurt er met een job als de runner van derden uitvalt? Is er een fallback?

GitHub heeft geen ingebouwde fallback tussen runnerlabels. Een job waarvan het label bij geen enkele online runner past, blijft in de wachtrij en mislukt na 24 uur. Zet het label in een repository- of organisatievariabele, zodat terugschakelen één wijziging is, stel timeout-minutes in en vraag elke aanbieder of hij een eigen fallback biedt.

Werken secrets en OIDC nog op runners van derden?

Ja. GitHub slaat de secrets op en levert ze bij de start van de job aan de runner, en GitHub geeft het OIDC-token uit, dus id-token: write werkt op elke runner. Het addertje: de claim runner_environment van het token is self-hosted op een runner van derden, dus een cloudvertrouwensbeleid dat github-hosted vereist, weigert de job.

Factureert GitHub mij nog minuten als ik een andere runneraanbieder gebruik?

Niet voor de jobs die u verplaatst. Runners van derden registreren zich bij GitHub als self-hosted runners, en GitHub rekent voor self-hosted runners geen minuutprijs. GitHub factureert nog wel seats, opslag die het bewaart boven het inbegrepen tegoed, en jobs die op door GitHub gehoste runners blijven. De aanbieder factureert zijn eigen minuten.

Hoe pin ik het runnerimage zodat het niet ongemerkt verandert?

ubuntu-latest verschuift volgens het schema van GitHub, en ubuntu-24.04 pint de release van het besturingssysteem, maar niet de pakketversies daarop. Pin wat ertoe doet binnen de job: setup-actions met expliciete versies, en containerimages op digest. Vraag elke aanbieder wat u kunt pinnen; de runnerapplicatie zelf moet updaten om met GitHub te blijven werken.

Hoe zijn jobs op een runner van derden van elkaar geïsoleerd?

Dat verschilt per aanbieder. Vraag of elke job een eigen virtuele machine krijgt of een container op een gedeelde host, of de machine na de job wordt vernietigd, en wat de aanbieder daarna bewaart. Een nieuwe virtuele machine per job is het sterkste van de gangbare modellen, omdat er van de ene job niets achterblijft voor de volgende.

Hoe test ik een runneraanbieder eerst op één repository?

Installeer de GitHub App van de aanbieder op één repository, schakel één vaak gedraaide Linux-job om via een repositoryvariabele op een branch, draai hem minstens tien keer en vergelijk duur, wachttijd, cachehits, fouten en kosten met een baseline op door GitHub gehoste runners. Draai terug door de variabele te wijzigen.