Self-hosted runners voor GitHub Actions vs beheerde CRACI-runners

Wat is een self-hosted runner voor GitHub Actions?

Een self-hosted runner is een machine die u zelf uitrolt en beheert en die GitHub Actions-jobs draait in plaats van een door GitHub gehoste VM. Dat kan een fysieke server, een virtuele machine of een container zijn, on-premises of in uw cloudaccount, en GitHub zegt dat u verantwoordelijk bent voor de machine en alle software erop.

• Registratie: een runner registreert zich bij één repository, organisatie of enterprise tegelijk. Registreer op organisatieniveau en gebruik runnergroepen om runners over repositories te delen.
• Platforms: de runnerapplicatie ondersteunt gangbare Linux-distributies, Windows 10, 11 en Windows Server, en macOS 11 en nieuwer, op x64 en ARM64.
• Netwerk: de runner maakt verbinding met GitHub via uitgaand HTTPS op poort 443.
• Updates: de runnerapplicatie moet binnen 30 dagen na een nieuwe release worden bijgewerkt. Hij werkt zichzelf bij, tenzij u dat uitschakelt.
• Limieten: een job kan tot 5 dagen draaien, tegenover 6 uur op door GitHub gehoste runners, en een job die langer dan 24 uur in de wachtrij staat, mislukt.
• Schalen: Actions Runner Controller (ARC), een Kubernetes-operator, schaalt runner scale sets mee met het aantal draaiende workflows. Runners die zijn geregistreerd met --ephemeral nemen één job aan.

Waarom teams zelf hosten

Teams hosten zelf om de kosten per minuut te verlagen, om interne systemen of specifieke hardware te bereiken, en om capaciteit te gebruiken waarvoor ze al betalen. De grotere runners van GitHub kunnen bovendien geen inbegrepen minuten gebruiken, dus grote machines worden op gehoste runners duur.

GitHub rekent op dit moment niets per minuut voor self-hosted runners. Het kondigde vanaf 1 maart 2026 een cloudplatformvergoeding van $0.002 per minuut voor self-hosted runners aan, en stelde die daarna uit om zijn aanpak te heroverwegen. Per september 2026 beschrijft de factureringsdocumentatie van GitHub self-hosted gebruik als gratis. Wat GitHub niet betaalt, is alles rond de runner.

De drie onderdelen van de kosten van self-hosting

De kosten van self-hosting bestaan uit infrastructuur, engineeringtijd en beveiligingshardening. Alleen het eerste verschijnt op een factuur.

Infrastructuur

U betaalt voor de hosts, of ze nu jobs draaien of stilstaan, dus u dimensioneert op uw drukste uur. Daar komen opslag voor caches en images bij, netwerkverkeer en alles wat u gebruikt om de vloot te monitoren en automatisch te schalen.

Engineeringtijd

De documentatie van GitHub is duidelijk over het eigenaarschap: met self-hosted runners bent u zelf verantwoordelijk voor het bijwerken van het besturingssysteem en alle andere software. In de praktijk betekent dat ook upgrades van de runnerversie, verschillen tussen images op hosts, schijven opruimen, scripts voor automatisch schalen, en iemand met piketdienst wanneer de wachtrij stilvalt.

Beveiligingshardening

De beveiligingsrichtlijnen van GitHub voor self-hosted runners bevatten twee waarschuwingen die het waard zijn om volledig te lezen:

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 beveelt just-in-time runners aan die maximaal één job draaien voordat ze worden verwijderd. Dit goed doen betekent kortstondige machines, isolatie tussen jobs, controle op uitgaand netwerkverkeer en zorgvuldige omgang met secrets. Elk daarvan is werk dat u ontwerpt, bouwt en draaiende houdt.

Best practices voor self-hosted runners op schaal

De beveiligingsrichtlijnen van GitHub en de gepubliceerde werkwijzen van AWS voor runners op schaal komen op dezelfde lijst uit. Elk punt is een project op zich:

• Kortstondige runners: één job per machine, zodat er niets tussen jobs overblijft.
• Runnergroepen: scheid runners per repository en omgeving, bij voorkeur in aparte accounts.
• Kortlevende inloggegevens: OpenID Connect naar uw cloud in plaats van langlevende toegangssleutels.
• Egresscontrole: beperk wat een job kan bereiken, niet alleen wat hij draait.
• Opstarttijd: warme pools en aangepaste images, omdat kortstondige machines langzamer starten.
• Kosten: spot-instances met een terugvaloptie voor langlopende jobs.
• Monitoring: statistieken over jobs in de wachtrij, draaiende en voltooide jobs, met meldingen.

Op CRACI komen het eerste en het vierde punt met de runner mee: elke job draait in een geïsoleerde virtuele machine onder een egressbeleid dat wordt gevalideerd voordat de job start en fail-closed werkt.

Een kostenmodel dat u kunt invullen

Voorbeeld A

Illustratieve invoer, geen benchmarks. 60.000 buildminuten per maand op runners met 2 vCPU, $350 per maand voor runnerhosts, en 8 uur onderhoud per maand tegen $85 per uur.

• Self-hosted: $350 + (8 × $85) = $350 + $680 = $1,030 per maand
• CRACI: 60.000 × $0.004 = $240 per maand

Voorbeeld B

Illustratieve invoer, geen benchmarks. Dezelfde 60.000 minuten, maar de hosts kosten $115 per maand en onderhoud kost 2 uur tegen $85 per uur.

• Self-hosted: $115 + (2 × $85) = $115 + $170 = $285 per maand
• CRACI: $240 per maand

In voorbeeld B liggen de twee op alleen rekenkracht dicht bij elkaar. Dat is een reële uitkomst voor teams met goedkope hosts en een stabiele opzet. Om uw eigen break-evenpunt te vinden, trekt u uw hostkosten af van het CRACI-bedrag en deelt u door uw uurtarief. Met de hosts van voorbeeld B is dat ($240 min $115) ÷ $85, of ongeveer 1,5 uur onderhoud per maand.

Twee dingen laat de formule niet zien. Ten eerste omvat het CRACI-bedrag meer dan rekenkracht (zie het volgende onderdeel). Ten tweede zijn uren de invoer die de meeste teams onderschatten. Tel image-updates, beveiligingspatches, schalen, schijven opruimen en de tijd die opgaat aan mislukte jobs mee, niet alleen de eerste installatie.

Wat self-hosted runners u niet geven

Een self-hosted runner draait uw job, maar legt niet vast wat de job heeft gedaan. Op CRACI-runners levert elke build bewijs terwijl hij draait:

• Een SBOM uit de build in CycloneDX of SPDX, van een proxy die pakketten herkent en observeert wat de job ophaalt, inclusief pakketten die uit CI-caches zijn teruggezet. De volledigheid wordt per job en per cache vermeld.
• Netwerkegressbeleid, default deny of allow, met 24 ingebouwde presets voor softwarebronnen en getypeerde aangepaste bronnen. Beleid wordt gevalideerd voordat de job start en werkt fail-closed. Overtredingen leiden tot meldingen.
• Een netwerktrace per job, beschikbaar via de API.
• Herkomstgegevens, beschikbaar via de API.
• Kwetsbaarheden volgen over builds en repositories heen, waarbij gemonitorde SBOM's continu opnieuw worden beoordeeld.

U kunt hiervan delen bouwen op self-hosted runners met uw eigen proxy, SBOM-tools en netwerklogging. Doet u dat, dan hoort de tijd om dit te bouwen en te onderhouden in het kostenmodel hierboven.

Wat CRACI niet biedt

CRACI biedt momenteel geen door de klant gehoste of on-premise runners; die staan op de roadmap voor Enterprise. Builds draaien op de beheerde runners van CRACI op Europese infrastructuur. Moet een job binnen uw eigen netwerk draaien, op hardware van uzelf of in een air-gapped omgeving, houd dan voor die job een self-hosted runner aan.

• CRACI-runners draaien momenteel alleen Linux; Windows en macOS staan op de roadmap. macOS- en Windows-builds blijven waar ze zijn.
• x86-64 en ARM64 draaien tegen hetzelfde tarief.
• Images: CRACI Slim, CRACI Slim ARM64 en een GitHub-compatibele Ubuntu 24.04-image. Geneste virtualisatie is beschikbaar op x86-64 en in preview op ARM64.
• GitHub Actions is de ondersteunde CI-integratie.

Een gemengde opzet komt vaak voor. Een job verplaatsen is een wijziging van de regel runs-on, dus u kunt de meeste jobs verplaatsen en er een paar op self-hosted runners houden. Alleen jobs op CRACI-runners krijgen SBOM's uit de build en netwerkbeleid.

Hoe u beslist

Beslis op basis van uw eigen getallen: de runnerkosten en uren van vorige maand, het bewijs dat van u wordt gevraagd, en één echte workflow die op elke optie draait.

1. Zet de hostrekening van vorige maand en de uren die uw team aan runners heeft besteed, inclusief incidenten, op een rij.
2. Tel uw buildminuten.
3. Vul beide in de formules hierboven in.
4. Maak een lijst van het bewijs dat van u wordt gevraagd (SBOM's, herkomst, netwerkcontroles) en wat er nodig is om dat op uw huidige runners te produceren.
5. Boek een demo en draai één echte workflow op CRACI om te vergelijken.

Meer over hoe de runners werken: CI/CD-integratie, beveiliging bij CRACI en de documentatie.

Veelgestelde vragen over self-hosted runners voor GitHub Actions

Korte antwoorden over kosten, installatie, beveiliging en limieten.

Wat is een self-hosted runner voor GitHub Actions?

Een self-hosted runner is een machine die u zelf uitrolt en beheert en die GitHub Actions-jobs draait. Dat kan een fysieke machine, een virtuele machine of een container zijn, on-premises of in een cloudaccount. U installeert de runnerapplicatie van GitHub, registreert die bij een repository, organisatie of enterprise, en stuurt jobs ernaartoe met runs-on: self-hosted of uw eigen labels.

Zijn self-hosted runners voor GitHub Actions gratis?

GitHub rekent per september 2026 niets per minuut voor self-hosted runners. Het kondigde een platformvergoeding van $0.002 per minuut aan vanaf 1 maart 2026, en stelde die daarna uit om zijn aanpak te heroverwegen. U betaalt nog steeds voor de machines, hun opslag en netwerk, en de tijd om ze gepatcht en veilig te houden.

Kan één self-hosted runner meerdere repositories bedienen?

Een runner registreert zich bij één repository, organisatie of enterprise tegelijk. Om er een over repositories te delen, registreert u hem op organisatieniveau en regelt u de toegang met runnergroepen, of u draait meerdere runnerinstanties op dezelfde machine, elk apart geregistreerd.

Op welke besturingssystemen draait een self-hosted runner?

GitHub ondersteunt de runnerapplicatie op gangbare Linux-distributies zoals Ubuntu 20.04 en nieuwer, Debian 10 en nieuwer en RHEL 8 en nieuwer, op Windows 10, 11 en Windows Server 2016 tot 2022, en op macOS 11 en nieuwer. Hij draait op x64 en ARM64, en op ARM32 voor Linux.

Hoe lang kan een job op een self-hosted runner draaien?

Tot 5 dagen, tegenover 6 uur op door GitHub gehoste runners. Een job die langer dan 24 uur in de wachtrij staat, mislukt.

Zijn self-hosted runners veilig voor openbare repositories?

GitHub zegt dat self-hosted runners vrijwel nooit voor openbare repositories moeten worden gebruikt, omdat iedereen een pull request kan openen en code op de machine kan uitvoeren. De aanbeveling is kortstondige just-in-time runners die maximaal één job draaien, plus isolatie, egresscontrole en zorgvuldige omgang met secrets.

Wat doet Actions Runner Controller?

Actions Runner Controller (ARC) is een Kubernetes-operator die self-hosted runners voor GitHub Actions orkestreert en schaalt. Runner scale sets groeien en krimpen met het aantal draaiende workflows. U beheert nog steeds het cluster, de images en het netwerk eromheen.

Kunnen CRACI-runners in mijn eigen netwerk draaien?

Op dit moment niet. CRACI biedt beheerde runners op Europese infrastructuur, met door de klant gehoste runners op de roadmap voor Enterprise. Jobs die binnen uw netwerk moeten draaien, kunnen op self-hosted runners blijven terwijl andere jobs naar CRACI verhuizen.