Selvhostede GitHub Actions-runnere vs. administrerte CRACI-runnere

Hva er en selvhostet runner for GitHub Actions?

En selvhostet runner er en maskin du selv setter opp og administrerer, og som kjører GitHub Actions-jobber i stedet for en GitHub-hostet VM. Den kan være en fysisk server, en virtuell maskin, en container, on-premise eller i skykontoen din, og GitHub sier at du er ansvarlig for maskinen og all programvaren på den.

• Registrering: En runner registreres hos ett repositorium, én organisasjon eller én enterprise om gangen. Registrer på organisasjonsnivå og bruk runnergrupper for å dele runnere mellom repositorier.
• Plattformer: Runner-applikasjonen støtter vanlige Linux-distribusjoner, Windows 10, 11 og Windows Server, og macOS 11 og nyere, på x64 og ARM64.
• Nettverk: Runneren kobler seg til GitHub over utgående HTTPS på port 443.
• Oppdateringer: Runner-applikasjonen må oppdateres innen 30 dager etter en ny utgivelse. Den oppdaterer seg selv med mindre du slår det av.
• Grenser: En jobb kan kjøre i opptil 5 dager, mot 6 timer på GitHub-hostede runnere, og en jobb som står i kø i mer enn 24 timer, feiler.
• Skalering: Actions Runner Controller (ARC), en Kubernetes-operator, skalerer runner scale sets etter antall workflows som kjører. Runnere registrert med --ephemeral tar én enkelt jobb.

Hvorfor team selvhoster

Team selvhoster for å kutte minuttkostnader, for å nå interne systemer eller spesifikk maskinvare, og for å bruke kapasitet de allerede betaler for. GitHubs større runnere kan heller ikke bruke inkluderte minutter, så store maskiner blir dyre på hostede runnere.

GitHub tar ikke betalt per minutt for selvhostede runnere i dag. Selskapet kunngjorde en plattformavgift på $0.002 per minutt for selvhostede runnere fra 1. mars 2026, og utsatte den deretter for å ta seg tid til å revurdere tilnærmingen. Per september 2026 beskriver GitHubs faktureringsdokumentasjon selvhostet bruk som gratis. Det GitHub ikke betaler for, er alt rundt runneren.

De tre delene av kostnaden ved selvhosting

Kostnaden ved selvhosting er infrastruktur, ingeniørtid og sikkerhetsherding. Bare den første vises på en faktura.

Infrastruktur

Du betaler for vertene enten de kjører jobber eller står ubrukt, så du dimensjonerer for den travleste timen. Legg til lagring for cacher og images, nettverkstrafikk og det du bruker for å overvåke og autoskalere flåten.

Ingeniørtid

GitHubs dokumentasjon er tydelig på eierskapet: Med selvhostede runnere er du selv ansvarlig for å oppdatere operativsystemet og all annen programvare. I praksis betyr det også oppgraderinger av runner-versjoner, images som glir fra hverandre mellom verter, diskopprydding, autoskaleringsskript og noen i beredskap når køen stopper opp.

Sikkerhetsherding

GitHubs sikkerhetsveiledning for selvhostede runnere inneholder to advarsler som er verdt å lese 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 anbefaler just-in-time-runnere som kjører maksimalt én jobb før de fjernes. Å gjøre dette godt betyr kortlivede maskiner, isolasjon mellom jobber, kontroll på utgående nettverkstrafikk og nøye håndtering av hemmeligheter. Alt dette er arbeid du utformer, bygger og holder i gang.

Beste praksis for selvhostede runnere i stor skala

GitHubs sikkerhetsveiledning og AWS' publiserte praksis for runnere i stor skala ender på samme liste. Hvert punkt er et prosjekt i seg selv:

• Kortlivede runnere: én jobb per maskin, så ingenting følger med fra jobb til jobb.
• Runnergrupper: skill runnere etter repositorium og miljø, helst i separate kontoer.
• Kortlivet legitimasjon: OpenID Connect mot skyen din i stedet for langlivede tilgangsnøkler.
• Egress-kontroll: begrens hva en jobb kan nå, ikke bare hva den kjører.
• Oppstartstid: varme pooler og tilpassede images, fordi kortlivede maskiner bruker lengre tid på å starte.
• Kostnad: spot-instanser med en reserve for langvarige jobber.
• Overvåking: metrikker for køede, kjørende og fullførte jobber, med varsler.

På CRACI følger det første og det fjerde punktet med runneren: Hver jobb kjører i en isolert virtuell maskin under en egress-policy som valideres før jobben starter, og blokkerer ved feil.

En kostnadsmodell du kan fylle ut

Eksempel A

Illustrerende inndata, ikke benchmarks. 60 000 byggeminutter i måneden på runnere med 2 vCPU, $350 per måned for runner-verter, og 8 timer vedlikehold i måneden til $85 per time.

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

Eksempel B

Illustrerende inndata, ikke benchmarks. De samme 60 000 minuttene, men vertene koster $115 per måned og vedlikeholdet tar 2 timer til $85 per time.

• Selvhostet: $115 + (2 × $85) = $115 + $170 = $285 per måned
• CRACI: $240 per måned

I eksempel B er de to nær hverandre på regnekraft alene. Det er et reelt utfall for team med billige verter og et stabilt oppsett. For å finne ditt eget break-even-punkt trekker du vertskostnaden fra CRACI-tallet og deler på timekostnaden din. Med vertene i eksempel B blir det ($240 minus $115) ÷ $85, eller omtrent 1,5 timer vedlikehold i måneden.

To ting formelen ikke viser. For det første omfatter CRACI-tallet mer enn regnekraft (se neste avsnitt). For det andre er timene den delen av inndataene de fleste team undervurderer. Tell med image-oppdateringer, sikkerhetspatcher, skalering, diskopprydding og tiden som går med til feilede jobber, ikke bare det første oppsettet.

Dette gir ikke selvhostede runnere deg

En selvhostet runner kjører jobben din, men registrerer ikke hva jobben gjorde. På CRACI-runnere produserer hvert bygg dokumentasjon mens det kjører:

• En SBOM fra bygget i CycloneDX eller SPDX, fra en pakkebevisst proxy som observerer hva jobben henter, inkludert pakker gjenopprettet fra CI-cacher. Fullstendighet oppgis per jobb og per cache.
• Egress-policy for nettverket, default deny eller allow, med 24 innebygde forhåndsinnstillinger for programvarekilder og typede egendefinerte kilder. Policyer valideres før jobben starter, og blokkerer ved feil. Brudd utløser varsler.
• Et nettverksspor per jobb, tilgjengelig via API-et.
• Provenance-data, tilgjengelig via API-et.
• Sårbarhetssporing på tvers av bygg og repositorier, der overvåkede SBOM-er vurderes på nytt kontinuerlig.

Du kan bygge deler av dette på selvhostede runnere med din egen proxy, dine egne SBOM-verktøy og din egen nettverkslogging. Gjør du det, hører tiden det tar å bygge og vedlikeholde det, hjemme i kostnadsmodellen ovenfor.

Dette tilbyr ikke CRACI

CRACI tilbyr ikke kundehostede eller on-premise-runnere i dag; de står på veikartet for Enterprise. Bygg kjører på CRACIs administrerte runnere på europeisk infrastruktur. Hvis en jobb må kjøre inne i ditt eget nettverk, på maskinvare du eier, eller i et air-gapped miljø, bør du beholde en selvhostet runner for den jobben.

• CRACI-runnere kjører bare Linux i dag; Windows og macOS står på veikartet. macOS- og Windows-bygg blir værende der de er.
• x86-64 og ARM64 kjører til samme pris.
• Images: CRACI Slim, CRACI Slim ARM64 og et GitHub-kompatibelt Ubuntu 24.04-image. Nestet virtualisering er tilgjengelig på x86-64 og i preview på ARM64.
• GitHub Actions er den støttede CI-integrasjonen.

Et blandet oppsett er vanlig. Å flytte en jobb er en endring av runs-on-linjen, så du kan flytte de fleste jobbene og beholde noen på selvhostede runnere. Bare jobber på CRACI-runnere får SBOM-er fra bygget og nettverkspolicy.

Slik bestemmer du deg

Bestem deg ut fra dine egne tall: forrige måneds runnerkostnad og timer, dokumentasjonen du blir bedt om, og én reell workflow kjørt på hvert alternativ.

1. Legg sammen forrige måneds regning for verter og timene teamet ditt brukte på runnere, inkludert hendelser.
2. Tell byggeminuttene dine.
3. Legg begge inn i formlene ovenfor.
4. List opp dokumentasjonen du blir bedt om (SBOM-er, provenance, nettverkskontroller), og hva det ville kreve å produsere den på dine nåværende runnere.
5. Book en demo, og kjør én reell workflow på CRACI for å sammenligne.

Mer om hvordan runnerne fungerer: CI/CD-integrasjon, sikkerhet i CRACI og dokumentasjonen.

Selvhostede GitHub Actions-runnere: ofte stilte spørsmål

Korte svar om kostnad, oppsett, sikkerhet og grenser.

Hva er en selvhostet runner for GitHub Actions?

En selvhostet runner er en maskin du selv setter opp og administrerer, og som kjører GitHub Actions-jobber. Den kan være fysisk, virtuell, en container, on-premise eller i en skykonto. Du installerer GitHubs runner-applikasjon på den, registrerer den hos et repositorium, en organisasjon eller en enterprise, og peker på den med runs-on: self-hosted eller dine egne etiketter.

Er selvhostede GitHub Actions-runnere gratis?

GitHub tar ikke betalt per minutt for selvhostede runnere per september 2026. Selskapet kunngjorde en plattformavgift på $0.002 per minutt fra 1. mars 2026, og utsatte den deretter for å revurdere tilnærmingen. Du betaler fortsatt for maskinene, lagringen og nettverket deres, og for tiden det tar å holde dem patchet og sikre.

Kan én selvhostet runner betjene flere repositorier?

En runner registreres hos ett repositorium, én organisasjon eller én enterprise om gangen. For å dele en runner mellom repositorier registrerer du den på organisasjonsnivå og styrer tilgangen med runnergrupper, eller du kjører flere runner-instanser på samme maskin, hver registrert for seg.

Hvilke operativsystemer kan kjøre en selvhostet runner?

GitHub støtter runner-applikasjonen på vanlige Linux-distribusjoner som Ubuntu 20.04 og nyere, Debian 10 og nyere og RHEL 8 og nyere, på Windows 10, 11 og Windows Server 2016 til 2022, og på macOS 11 og nyere. Den kjører på x64 og ARM64, og på ARM32 for Linux.

Hvor lenge kan en jobb kjøre på en selvhostet runner?

Opptil 5 dager, mot 6 timer på GitHub-hostede runnere. En jobb som står i kø i mer enn 24 timer, feiler.

Er selvhostede runnere trygge for offentlige repositorier?

GitHub sier at selvhostede runnere nesten aldri bør brukes for offentlige repositorier, fordi hvem som helst kan åpne en pull request og kjøre kode på maskinen. Anbefalingen er kortlivede just-in-time-runnere som kjører maksimalt én jobb, pluss isolasjon, egress-kontroll og nøye håndtering av hemmeligheter.

Hva gjør Actions Runner Controller?

Actions Runner Controller (ARC) er en Kubernetes-operator som orkestrerer og skalerer selvhostede runnere for GitHub Actions. Runner scale sets vokser og krymper med antall workflows som kjører. Du drifter fortsatt klyngen, imagene og nettverket rundt.

Kan CRACI-runnere kjøre i mitt eget nettverk?

Ikke i dag. CRACI tilbyr administrerte runnere på europeisk infrastruktur, med kundehostede runnere på veikartet for Enterprise. Jobber som må kjøre inne i nettverket ditt, kan bli på selvhostede runnere mens andre jobber flyttes til CRACI.