Selvhostede GitHub Actions-runnere vs. administrerede CRACI-runnere

Hvad er en selvhostet GitHub Actions-runner?

En selvhostet runner er en maskine, du selv udruller og administrerer, som kører GitHub Actions-jobs i stedet for en GitHub-hostet VM. Den kan være en fysisk server, en virtuel maskine, en container, on premises eller i din cloud-konto, og GitHub siger, at du er ansvarlig for maskinen og al dens software.

• Registrering: En runner registreres hos ét repository, én organisation eller én enterprise ad gangen. Registrér på organisationsniveau, og brug runner-grupper til at dele runnere på tværs af repositories.
• Platforme: Runner-applikationen understøtter almindelige Linux-distributioner, Windows 10, 11 og Windows Server og macOS 11 og nyere på x64 og ARM64.
• Netværk: Runneren forbinder til GitHub via udgående HTTPS på port 443.
• Opdateringer: Runner-applikationen skal opdateres inden for 30 dage efter en ny release. Den opdaterer sig selv, medmindre du slår det fra.
• Grænser: Et job kan køre i op til 5 dage mod 6 timer på GitHub-hostede runnere, og et job, der står i kø i mere end 24 timer, fejler.
• Skalering: Actions Runner Controller (ARC), en Kubernetes-operator, skalerer runner scale sets efter antallet af workflows, der kører. Runnere registreret med --ephemeral tager ét enkelt job.

Derfor selvhoster teams

Teams selvhoster for at skære ned på prisen pr. minut, for at nå interne systemer eller specifik hardware og for at bruge kapacitet, de allerede betaler for. GitHubs større runnere kan heller ikke bruge inkluderede minutter, så store maskiner bliver dyre på hostede runnere.

GitHub tager ikke betaling pr. minut for selvhostede runnere i dag. Det annoncerede et cloud-platformgebyr på $0.002 pr. minut for selvhostede runnere fra 1. marts 2026 og udskød det derefter "to take time to re-evaluate our approach." Pr. september 2026 beskriver GitHubs dokumentation om afregning selvhostet forbrug som gratis. Det, GitHub ikke betaler for, er alt omkring runneren.

De tre dele af prisen for selvhosting

Prisen for selvhosting består af infrastruktur, ingeniørtid og sikkerhedshærdning. Kun den første står på en faktura.

Infrastruktur

Du betaler for hostene, uanset om de kører jobs eller står ubrugte, så du dimensionerer til din travleste time. Læg lagring til caches og images, netværkstrafik og det, du bruger til at overvåge og autoskalere flåden, oveni.

Ingeniørtid

GitHubs dokumentation er direkte om ejerskabet: Med selvhostede runnere gælder "you are responsible for updating the operating system and all other software." I praksis betyder det også opgraderinger af runner-versioner, images, der glider fra hinanden mellem hosts, diskoprydning, autoskaleringsscripts og en person på vagt, når køen går i stå.

Sikkerhedshærdning

GitHubs sikkerhedsvejledning for selvhostede runnere indeholder to advarsler, der er værd at læse i deres helhed:

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, der højst kører ét job, før de fjernes. At gøre det godt kræver kortlivede maskiner, isolation mellem jobs, kontrol med udgående netværkstrafik og omhyggelig håndtering af secrets. Hver af dem er arbejde, du selv skal designe, bygge og holde kørende.

Bedste praksis for selvhostede runnere i stor skala

GitHubs sikkerhedsvejledning og AWS' offentliggjorte praksis for runnere i stor skala ender på samme liste. Hvert punkt er et projekt i sig selv:

• Kortlivede runnere: ét job pr. maskine, så intet føres videre mellem jobs.
• Runner-grupper: Adskil runnere efter repository og miljø, helst i separate konti.
• Kortlivede legitimationsoplysninger: OpenID Connect til din cloud i stedet for langtidsholdbare adgangsnøgler.
• Egress-kontrol: Begræns, hvad et job kan nå, ikke kun, hvad det kører.
• Opstartstid: varme puljer og tilpassede images, fordi kortlivede maskiner er langsommere at starte.
• Pris: spot-instanser med en reserve til langvarige jobs.
• Overvågning: metrikker for jobs i kø, kørende og afsluttede jobs, med alarmer.

På CRACI følger det første og det fjerde med runneren: Hvert job kører i en isoleret virtuel maskine under en egress-politik, der valideres, før jobbet starter, og blokerer ved fejl.

En omkostningsmodel, du kan udfylde

Eksempel A

Illustrative input, ikke benchmarks. 60.000 build-minutter om måneden på runnere med 2 vCPU, $350 om måneden til runner-hosts og 8 timers vedligehold om måneden til $85 i timen.

• Selvhostet: $350 + (8 × $85) = $350 + $680 = $1,030 pr. måned
• CRACI: 60.000 × $0.004 = $240 pr. måned

Eksempel B

Illustrative input, ikke benchmarks. De samme 60.000 minutter, men hostene koster $115 om måneden, og vedligeholdet tager 2 timer til $85 i timen.

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

I eksempel B er de to tæt på hinanden på compute alene. Det er et reelt udfald for teams med billige hosts og en stabil opsætning. For at finde dit eget break-even skal du trække din hostpris fra CRACI-tallet og dividere med din timepris. Med hostene fra eksempel B er det ($240 minus $115) ÷ $85, eller cirka 1,5 timers vedligehold om måneden.

To ting viser formlen ikke. For det første omfatter CRACI-tallet mere end compute (se næste afsnit). For det andet er timerne det input, de fleste teams undervurderer. Tæl opdateringer af images, sikkerhedspatches, skalering, diskoprydning og den tid, der bruges på fejlede jobs, ikke kun den første opsætning.

Det, selvhostede runnere ikke giver dig

En selvhostet runner kører dit job, men den registrerer ikke, hvad jobbet gjorde. På CRACI-runnere producerer hvert build dokumentation, mens det kører:

• En SBOM fra buildet i CycloneDX eller SPDX fra en pakkebevidst proxy, der observerer, hvad jobbet henter, inklusive pakker gendannet fra CI-caches. Fuldstændigheden angives pr. job og pr. cache.
• Netværks-egress-politik, default deny eller allow, med 24 indbyggede presets for softwarekilder og typede tilpassede kilder. Politikker valideres, før jobbet starter, og blokerer ved fejl. Overtrædelser udløser alarmer.
• Et netværkstrace pr. job, tilgængeligt via API'et.
• Provenance-data, tilgængelige via API'et.
• Sårbarhedsopfølgning på tværs af builds og repositories, hvor overvågede SBOM'er genvurderes løbende.

Du kan bygge dele af det på selvhostede runnere med din egen proxy, dine egne SBOM-værktøjer og din egen netværkslogning. Gør du det, hører tiden til at bygge og vedligeholde det med i omkostningsmodellen ovenfor.

Det, CRACI ikke tilbyder

CRACI tilbyder ikke kundehostede eller on-premise-runnere i dag; de er på roadmappen for Enterprise. Builds kører på CRACI's administrerede runnere på europæisk infrastruktur. Skal et job køre inde i dit eget netværk, på hardware, du ejer, eller i et air-gapped miljø, så behold en selvhostet runner til det job.

• CRACI-runnere kører kun Linux i dag; Windows og macOS er på roadmappen. macOS- og Windows-builds bliver, hvor de er.
• x86-64 og ARM64 kører til samme pris.
• Images: CRACI Slim, CRACI Slim ARM64 og et GitHub-kompatibelt Ubuntu 24.04-image. Indlejret virtualisering er tilgængelig på x86-64 og i preview på ARM64.
• GitHub Actions er den understøttede CI-integration.

En blandet opsætning er almindelig. At flytte et job er en ændring af dets runs-on-linje, så du kan flytte de fleste jobs og beholde nogle få på selvhostede runnere. Kun jobs på CRACI-runnere får SBOM'er fra buildet og netværkspolitik.

Sådan beslutter du

Beslut ud fra dine egne tal: sidste måneds runner-omkostning og timer, den dokumentation, du bliver bedt om, og ét reelt workflow kørt på hver mulighed.

1. Læg sidste måneds host-regning sammen med de timer, dit team brugte på runnere, inklusive hændelser.
2. Tæl dine build-minutter.
3. Sæt begge tal ind i formlerne ovenfor.
4. Oplist den dokumentation, du bliver bedt om (SBOM'er, provenance, netværkskontroller), og hvad det ville kræve at producere den på dine nuværende runnere.
5. Book en demo, og kør ét reelt workflow på CRACI for at sammenligne.

Mere om, hvordan runnerne virker: CI/CD-integration, sikkerhed hos CRACI og dokumentationen.

Selvhostede GitHub Actions-runnere: ofte stillede spørgsmål

Korte svar om pris, opsætning, sikkerhed og grænser.

Hvad er en selvhostet GitHub Actions-runner?

En selvhostet runner er en maskine, du selv udruller og administrerer, som kører GitHub Actions-jobs. Den kan være fysisk, virtuel, en container, on premises eller i en cloud-konto. Du installerer GitHubs runner-applikation på den, registrerer den hos et repository, en organisation eller en enterprise og peger på den med runs-on: self-hosted eller dine egne labels.

Er selvhostede GitHub Actions-runnere gratis?

GitHub tager ikke betaling pr. minut for selvhostede runnere pr. september 2026. Det annoncerede et platformgebyr på $0.002 pr. minut fra 1. marts 2026 og udskød det derefter for at genoverveje sin tilgang. Du betaler stadig for maskinerne, deres lagring og netværk og tiden til at holde dem patchede og sikre.

Kan én selvhostet runner betjene flere repositories?

En runner registreres hos ét repository, én organisation eller én enterprise ad gangen. For at dele den på tværs af repositories registrerer du den på organisationsniveau og styrer adgangen med runner-grupper, eller du kører flere runner-instanser på samme maskine, hver registreret for sig.

Hvilke styresystemer kan køre en selvhostet runner?

GitHub understøtter runner-applikationen på almindelige Linux-distributioner 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 kører på x64 og ARM64 og på ARM32 for Linux.

Hvor længe kan et job køre på en selvhostet runner?

Op til 5 dage mod 6 timer på GitHub-hostede runnere. Et job, der står i kø i mere end 24 timer, fejler.

Er selvhostede runnere sikre til offentlige repositories?

GitHub siger, at selvhostede runnere næsten aldrig bør bruges til offentlige repositories, fordi enhver kan åbne en pull request og køre kode på maskinen. Anbefalingen er kortlivede just-in-time-runnere, der højst kører ét job, plus isolation, egress-kontrol og omhyggelig håndtering af secrets.

Hvad gør Actions Runner Controller?

Actions Runner Controller (ARC) er en Kubernetes-operator, der orkestrerer og skalerer selvhostede runnere til GitHub Actions. Runner scale sets vokser og skrumper med antallet af workflows, der kører. Du driver stadig clusteret, images og netværket omkring det.

Kan CRACI-runnere køre i mit eget netværk?

Ikke i dag. CRACI tilbyder administrerede runnere på europæisk infrastruktur, med kundehostede runnere på roadmappen for Enterprise. Jobs, der skal køre inde i dit netværk, kan blive på selvhostede runnere, mens andre jobs flytter til CRACI.