Egenhostade GitHub Actions-runners vs CRACI:s hanterade runners

Vad är en egenhostad runner för GitHub Actions?

En egenhostad runner är en maskin som du driftsätter och hanterar och som kör GitHub Actions-jobb i stället för en GitHub-hostad VM. Det kan vara en fysisk server, en virtuell maskin, en container, on-premises eller i ditt molnkonto, och GitHub säger att du ansvarar för maskinen och all dess programvara.

• Registrering: en runner registreras hos ett repo, en organisation eller ett enterprise-konto i taget. Registrera på organisationsnivå och använd runnergrupper för att dela runners mellan repon.
• Plattformar: runnerapplikationen stöder vanliga Linux-distributioner, Windows 10, 11 och Windows Server, och macOS 11 och senare, på x64 och ARM64.
• Nätverk: runnern ansluter till GitHub via utgående HTTPS på port 443.
• Uppdateringar: runnerapplikationen måste uppdateras inom 30 dagar efter en ny release. Den uppdaterar sig själv om du inte stänger av det.
• Gränser: ett jobb kan köras i upp till 5 dagar, mot 6 timmar på GitHub-hostade runners, och ett jobb som står i kö i mer än 24 timmar misslyckas.
• Skalning: Actions Runner Controller (ARC), en Kubernetes-operator, skalar runner scale sets med antalet arbetsflöden som körs. Runners som registreras med --ephemeral tar ett enda jobb.

Varför team väljer egen hosting

Team hostar själva för att sänka kostnaden per minut, nå interna system eller specifik hårdvara och använda kapacitet de redan betalar för. GitHubs större runners kan inte heller använda inkluderade minuter, så stora maskiner blir dyra på hostade runners.

GitHub tar i dag inte betalt per minut för egenhostade runners. Företaget meddelade en molnplattformsavgift på $0.002 per minut för egenhostade runners från den 1 mars 2026 och sköt sedan upp den för att utvärdera sitt tillvägagångssätt på nytt. I september 2026 beskriver GitHubs faktureringsdokumentation egenhostad användning som gratis. Det GitHub inte betalar för är allt runt runnern.

De tre delarna av kostnaden för egen hosting

Kostnaden för egen hosting består av infrastruktur, ingenjörstid och säkerhetshärdning. Bara den första syns på en faktura.

Infrastruktur

Du betalar för värdarna oavsett om de kör jobb eller står oanvända, så du dimensionerar för din mest hektiska timme. Lägg till lagring för cachar och avbilder, nätverkstrafik och det du använder för att övervaka och autoskala flottan.

Ingenjörstid

GitHubs dokumentation är tydlig om ansvaret: med egenhostade runners ansvarar du själv för att uppdatera operativsystemet och all annan programvara. I praktiken innebär det också versionsuppgraderingar av runnern, avbilder som glider isär mellan värdar, diskrensning, skript för autoskalning och någon i jour när kön slutar röra sig.

Säkerhetshärdning

GitHubs säkerhetsvägledning för egenhostade runners innehåller två varningar som är värda att läsa i sin helhet:

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 rekommenderar just-in-time-runners som kör högst ett jobb innan de tas bort. Att göra det här bra innebär tillfälliga maskiner, isolering mellan jobb, kontroll av utgående nätverkstrafik och försiktig hantering av hemligheter. Var och en av dem är arbete som du utformar, bygger och håller igång.

Bästa praxis för egenhostade runners i stor skala

GitHubs säkerhetsvägledning och AWS publicerade arbetssätt för runners i stor skala landar i samma lista. Varje punkt är ett projekt i sig:

• Tillfälliga runners: ett jobb per maskin, så att inget följer med mellan jobb.
• Runnergrupper: separera runners efter repo och miljö, helst i separata konton.
• Kortlivade inloggningsuppgifter: OpenID Connect mot ditt moln i stället för långlivade åtkomstnycklar.
• Kontroll av egress: begränsa vad ett jobb kan nå, inte bara vad det kör.
• Starttid: varma pooler och anpassade avbilder, eftersom tillfälliga maskiner startar långsammare.
• Kostnad: spotinstanser med en reservlösning för långvariga jobb.
• Övervakning: mätvärden för köade, pågående och slutförda jobb, med varningar.

På CRACI ingår den första och fjärde punkten i runnern: varje jobb körs i en isolerad virtuell maskin under en egress-policy som valideras innan jobbet startar och blockerar vid fel.

En kostnadsmodell du kan fylla i

Exempel A

Illustrativa indata, inte benchmarkresultat. 60 000 byggminuter i månaden på runners med 2 vCPU, $350 i månaden för runnervärdar och 8 timmars underhåll i månaden à $85 i timmen.

• Egen hosting: $350 + (8 × $85) = $350 + $680 = $1,030 per månad
• CRACI: 60 000 × $0.004 = $240 per månad

Exempel B

Illustrativa indata, inte benchmarkresultat. Samma 60 000 minuter, men värdarna kostar $115 i månaden och underhållet tar 2 timmar à $85 i timmen.

• Egen hosting: $115 + (2 × $85) = $115 + $170 = $285 per månad
• CRACI: $240 per månad

I exempel B ligger de två nära varandra enbart sett till beräkningskapacitet. Det är ett verkligt utfall för team med billiga värdar och en stabil konfiguration. För att hitta din egen brytpunkt drar du av din värdkostnad från CRACI-siffran och delar med din timkostnad. Med värdarna i exempel B blir det ($240 minus $115) ÷ $85, eller omkring 1,5 timmars underhåll i månaden.

Två saker visar formeln inte. För det första omfattar CRACI-siffran mer än beräkningskapacitet (se nästa avsnitt). För det andra är timmarna den indata som de flesta team underskattar. Räkna med avbildsuppdateringar, säkerhetspatchar, skalning, diskrensning och tiden som går åt till misslyckade jobb, inte bara den första konfigurationen.

Det egenhostade runners inte ger dig

En egenhostad runner kör ditt jobb, men den registrerar inte vad jobbet gjorde. På CRACI-runners ger varje bygge underlag medan det körs:

• En SBOM från bygget i CycloneDX eller SPDX, från en paketmedveten proxy som observerar vad jobbet hämtar, inklusive paket som återställs från CI-cachar. Fullständigheten anges per jobb och per cache.
• Egress-policy för nätverket, som nekar eller tillåter som standard, med 24 inbyggda förinställningar för programvarukällor och typade egna källor. Policyer valideras innan jobbet startar och blockerar vid fel. Överträdelser utlöser varningar.
• En nätverksspårning per jobb, tillgänglig via API:t.
• Proveniensdata, tillgängliga via API:t.
• Sårbarhetsuppföljning över byggen och repon, där bevakade SBOM:er omvärderas löpande.

Du kan bygga delar av detta på egenhostade runners med din egen proxy, dina egna SBOM-verktyg och din egen nätverksloggning. Om du gör det hör tiden för att bygga och underhålla det hemma i kostnadsmodellen ovan.

Det CRACI inte erbjuder

CRACI erbjuder i dag inga kundhostade eller on-premise-runners; de finns på roadmapen för Enterprise. Byggen körs på CRACI:s hanterade runners på europeisk infrastruktur. Om ett jobb måste köras i ditt eget nätverk, på hårdvara du äger eller i en air-gappad miljö, behåll en egenhostad runner för det jobbet.

• CRACI-runners kör i dag bara Linux; Windows och macOS finns på roadmapen. macOS- och Windows-byggen stannar där de är.
• x86-64 och ARM64 körs till samma pris.
• Avbilder: CRACI Slim, CRACI Slim ARM64 och en GitHub-kompatibel Ubuntu 24.04-avbild. Nästlad virtualisering finns på x86-64 och i förhandsversion på ARM64.
• GitHub Actions är den CI-integration som stöds.

En blandad konfiguration är vanlig. Att flytta ett jobb är en ändring på dess runs-on-rad, så du kan flytta de flesta jobb och behålla några på egenhostade runners. Bara jobb på CRACI-runners får SBOM:er från bygget och nätverkspolicy.

Så bestämmer du dig

Bestäm utifrån dina egna siffror: förra månadens runnerkostnad och timmar, underlaget du ombeds lämna och ett riktigt arbetsflöde som körs på varje alternativ.

1. Summera förra månadens värdfaktura och timmarna ditt team lade på runners, inklusive incidenter.
2. Räkna dina byggminuter.
3. För in båda i formlerna ovan.
4. Lista underlaget du ombeds lämna (SBOM:er, proveniens, nätverkskontroller) och vad som skulle krävas för att ta fram det på dina nuvarande runners.
5. Boka en demo och kör ett riktigt arbetsflöde på CRACI för att jämföra.

Mer om hur runnerna fungerar: CI/CD-integration, säkerhet på CRACI och dokumentationen.

Egenhostade runners för GitHub Actions: vanliga frågor

Korta svar om kostnad, konfiguration, säkerhet och gränser.

Vad är en egenhostad runner för GitHub Actions?

En egenhostad runner är en maskin som du driftsätter och hanterar och som kör GitHub Actions-jobb. Den kan vara fysisk, virtuell, en container, on-premises eller i ett molnkonto. Du installerar GitHubs runnerapplikation på den, registrerar den hos ett repo, en organisation eller ett enterprise-konto och pekar ut den med runs-on: self-hosted eller dina egna etiketter.

Är egenhostade runners för GitHub Actions gratis?

GitHub tar inte betalt per minut för egenhostade runners i september 2026. Företaget meddelade en plattformsavgift på $0.002 per minut från den 1 mars 2026 och sköt sedan upp den för att utvärdera sitt tillvägagångssätt på nytt. Du betalar fortfarande för maskinerna, deras lagring och nätverk, och tiden det tar att hålla dem patchade och säkra.

Kan en egenhostad runner betjäna flera repon?

En runner registreras hos ett repo, en organisation eller ett enterprise-konto i taget. För att dela en mellan repon registrerar du den på organisationsnivå och styr åtkomsten med runnergrupper, eller kör flera runnerinstanser på samma maskin, var och en separat registrerad.

Vilka operativsystem kan köra en egenhostad runner?

GitHub stöder runnerapplikationen på vanliga Linux-distributioner som Ubuntu 20.04 och senare, Debian 10 och senare och RHEL 8 och senare, på Windows 10, 11 och Windows Server 2016 till 2022, och på macOS 11 och senare. Den körs på x64 och ARM64, och på ARM32 för Linux.

Hur länge kan ett jobb köras på en egenhostad runner?

Upp till 5 dagar, jämfört med 6 timmar på GitHub-hostade runners. Ett jobb som står i kö i mer än 24 timmar misslyckas.

Är egenhostade runners säkra för publika repon?

GitHub säger att egenhostade runners nästan aldrig bör användas för publika repon, eftersom vem som helst kan öppna en pull request och köra kod på maskinen. Rekommendationen är tillfälliga just-in-time-runners som kör högst ett jobb, plus isolering, kontroll av egress och försiktig hantering av hemligheter.

Vad gör Actions Runner Controller?

Actions Runner Controller (ARC) är en Kubernetes-operator som orkestrerar och skalar egenhostade runners för GitHub Actions. Runner scale sets växer och krymper med antalet arbetsflöden som körs. Du driver fortfarande klustret, avbilderna och nätverket runt det.

Kan CRACI-runners köras i mitt eget nätverk?

Inte i dag. CRACI erbjuder hanterade runners på europeisk infrastruktur, med kundhostade runners på roadmapen för Enterprise. Jobb som måste köras i ditt nätverk kan stanna på egenhostade runners medan andra jobb flyttar till CRACI.