CRACI er den runner, dine builds kører på

Én linje flytter buildet

CRACI erstatter runneren, ikke GitHub Actions. Dine workflow-filer, actions og secrets bliver, hvor de er; det eneste, der ændres, er, hvor jobbet kører:

jobs:
  build:
    runs-on: craci

Kørslerne vises stadig i GitHub, så pull requests, checks og logs bliver der, hvor dit team allerede kigger. Det sørger GitHub-appen for, som du installerer på alle eller udvalgte repositories.

Hvad runnerne er

• Størrelser fra 1 til 32 compute units, hver med 1 vCPU og 3 GB RAM, standard 2. Du angiver størrelsen pr. job med cracicorp/setup@v1 og dens size:-input.
• Native x86-64 og ARM64 til samme pris.
• Images: CRACI Slim, CRACI Slim ARM64 og et GitHub-kompatibelt Ubuntu 24.04-image med Docker Engine, Buildx og Compose v2.
• Isolerede virtuelle maskiner pr. job. Indlejret virtualisering er tilgængelig på x86-64 og i preview på ARM64.
• Caching: GitHub Actions-cache plus caching af containerlag – lokale, eksterne og bind mount-lagcaches.
• Pipeline-infrastruktur: et fast egress-IP-interval og runner-skabeloner på organisationsniveau.
• Linux i dag. Windows- og macOS-runnere er på roadmappen.

Runnerne administreres af CRACI og kører på europæisk bare metal-infrastruktur med dataopbevaring i EU. Kundehostede runnere er på roadmappen for Enterprise; se administrerede over for selvhostede runnere for afvejningen.

Hvorfor forsyningskædesikkerhed hører hjemme i runneren

Produktionsbuildet er ikke buildet på en bærbar. Versionsintervaller resolves anderledes, tags flytter sig, caches er varme eller kolde, og miljøet er ikke det samme. Den eneste pålidelige registrering af, hvad der blev leveret, er den, der blev foretaget, mens release-buildet kørte – og derfor placerede CRACI registreringen i runneren frem for ved siden af den. Hele argumentet står i hvorfor forsyningskædesikkerhed hører hjemme i CI.

Fordi CRACI ejer runneren, kan CRACI gøre ting, som en scanner ikke kan:

• Registrere, ikke scanne. En pakkebevidst proxy observerer, hvad jobbet faktisk downloader, inklusive transitive afhængigheder og pakker gendannet fra CI-caches. Hvert jobs SBOM har en fuldstændighedsstatus.
• Håndhæve egress-politik. Politikken håndhæves på runneren, valideres, før jobbet starter, og blokerer ved fejl.
• Levere dokumentationen. API'et returnerer SBOM'er, netværkstraces og provenance for hvert job.

Omtrent dobbelt så hurtig som GitHub-hostede runnere

CRACI kører builds omtrent dobbelt så hurtigt som GitHubs hostede standardrunnere, med de samme workflows og uden at ændre dem. Det job, der tog ti minutter, tager omkring fem.

Hurtigere CI er mere værd end de minutter, det sparer. En pull request, der bliver grøn på fem minutter, er en, som en reviewer stadig kigger på; en, der tager tyve, er en, som forfatteren har skiftet væk fra. Build-tid er tiden mellem at skrive en ændring og finde ud af, om den virker, og den betales ved hvert push af hver udvikler på teamet.

Tre ting forklarer det: hardwaren, kortere ventetider og caching.

Hvad hastigheden koster

Fordi CRACI måler pr. sekund og tager mindre pr. minut, forstærker dobbelt hastighed besparelsen i stedet for at udligne den. For et build, der tager ti minutter på en GitHub-hostet 2-core x64-runner (GitHubs listepriser pr. september 2026, CRACI pr. oktober 2026):

Build på ti minutter, 1.000 gange om måneden	GitHub-hostet	CRACI
Faktisk tid pr. build	10 minutter	Omkring 5 minutter
Pris pr. build	$0.060	$0.020
Pris pr. måned	Omkring $60	Omkring $20

Det er omkring 67 % lavere, eller 3 gange billigere. Uden hastighedsforøgelsen er besparelsen alene forskellen i listepris, omkring 33 % på 2-core x64. Hvor meget hurtigere dine egne builds bliver, afhænger af arbejdsbyrden, så flyt ét workflow og mål det.

Afregning pr. sekund

Build-minutter måles pr. sekund, afrundet til nærmeste sekund. GitHub runder hvert job op til et helt minut, så en matrix af korte jobs bliver faktureret for tid, den aldrig brugte: Et job på 30 sekunder koster omkring 67 % mindre på CRACI, og et job på 70 sekunder omkring 61 % mindre. Lange jobs nærmer sig forskellen i listepris.

Build-minutter koster $0.002 pr. vCPU-minut, eller $0.004 pr. minut for en runner i størrelse 2, til samme pris på ARM64. CRACI er ikke den billigste runner på markedet, og prisen er ikke argumentet: Argumentet er, hvad runneren registrerer, mens den kører. Se priser.

Sådan klarer CRACI sig over for andre GitHub Actions-runnere

Blacksmith, Depot, Namespace og WarpBuild fungerer alle på samme måde som CRACI: Dine workflows bliver i GitHub Actions, og du ændrer, hvor jobbet kører. På hastighed og pris ligger de tæt på hinanden, og flere har en lavere ARM-pris end CRACI. Forskellen er, hvad runneren registrerer og kontrollerer, mens jobbet kører.

CRACI er en af de mest prisvenlige runnere, og det er den, der producerer en SBOM over, hvad jobbet faktisk hentede, håndhæver en egress-politik, der blokerer ved fejl, og returnerer provenance-data via sit API – som et biprodukt af at køre buildet, uden at noget føjes til workflowet. Vil du have den fulde version række for række: GitHub Actions-runnere sammenlignet.

Hvad der kører godt på CRACI

Alt, hvad et GitHub Actions-job gør: applikationsbuilds, container-images, testsuiter. To tilfælde er værd at fremhæve: Yocto- og BitBake-builds af embedded Linux-images, dokumenteret op til runnere i størrelse 32, og pi-gen-builds af Raspberry Pi OS.

På roadmappen

• Windows- og macOS-runnere: på roadmappen.
• Kundehostede runnere: på roadmappen, for Enterprise.
• Andre CI-systemer: GitHub Actions i dag, andre på roadmappen uden dato endnu.