CRACI is de runner waarop uw builds draaien

Eén regel verplaatst de build

CRACI vervangt de runner, niet GitHub Actions. Uw workflowbestanden, actions en secrets blijven waar ze zijn; alleen de plek waar de job wordt uitgevoerd verandert:

jobs:
  build:
    runs-on: craci

Runs verschijnen nog steeds in GitHub, dus pull requests, checks en logs blijven op de plek waar uw team al kijkt. Dat regelt de GitHub App, die u installeert op alle of op geselecteerde repositories.

Wat de runners zijn

• Formaten van 1 tot 32 compute units, elk 1 vCPU en 3 GB RAM, standaard 2. U stelt het formaat per job in met cracicorp/setup@v1 en de input size:.
• Native x86-64 en ARM64 tegen hetzelfde tarief.
• Images: CRACI Slim, CRACI Slim ARM64 en een GitHub-compatibele Ubuntu 24.04-image, met Docker Engine, Buildx en Compose v2.
• Geïsoleerde virtuele machines per job. Geneste virtualisatie is beschikbaar op x86-64 en in preview op ARM64.
• Caching: GitHub Actions-cache, plus caching van containerlagen: lokale, externe en bind-mount-laagcaches.
• Pipelinevoorzieningen: een vast egress-IP-bereik en runnertemplates op organisatieniveau.
• Momenteel Linux. Windows- en macOS-runners staan op de roadmap.

De runners worden beheerd door CRACI en draaien op Europese bare-metalinfrastructuur, met dataopslag in de EU. Door de klant gehoste runners staan op de roadmap voor Enterprise; zie beheerde versus self-hosted runners voor de afweging.

Waarom ketenbeveiliging in de runner thuishoort

De productiebuild is niet de build op een laptop. Versiebereiken worden anders opgelost, tags verschuiven, caches zijn warm of koud en de omgeving is niet dezelfde. De enige betrouwbare vastlegging van wat er is uitgeleverd, is die tijdens de releasebuild zelf. Daarom heeft CRACI de recorder in de runner geplaatst in plaats van ernaast. Het volledige betoog staat op waarom ketenbeveiliging in CI thuishoort.

Omdat CRACI de runner zelf beheert, kan het dingen die een scanner niet kan:

• Vastleggen, niet scannen. Een proxy die pakketten herkent, observeert wat de job daadwerkelijk downloadt, inclusief transitieve afhankelijkheden en pakketten die uit CI-caches worden teruggezet. De SBOM van elke job heeft een volledigheidsstatus.
• Egressbeleid afdwingen. Het beleid wordt afgedwongen op de runner, gevalideerd voordat de job start en is fail-closed.
• Het bewijs teruggeven. De API levert voor elke job SBOM's, netwerktraces en herkomstgegevens.

Ongeveer twee keer zo snel als door GitHub gehoste runners

CRACI draait builds ongeveer twee keer zo snel als de standaard gehoste runners van GitHub, met dezelfde workflows en zonder ze aan te passen. De job die tien minuten duurde, duurt ongeveer vijf.

Snellere CI is meer waard dan de minuten die hij bespaart. Een pull request die binnen vijf minuten groen is, heeft nog de aandacht van de reviewer; een pull request die twintig minuten duurt, is er een waar de auteur zijn aandacht al van heeft verlegd. Buildtijd is de tijd tussen het schrijven van een wijziging en weten of die werkt, en elke engineer in het team betaalt die bij elke push.

Drie dingen verklaren het verschil: de hardware, kortere wachttijden en caching.

Wat de versnelling kost

Omdat CRACI per seconde meet en minder per minuut rekent, versterkt twee keer zo snel draaien de besparing in plaats van die op te heffen. Voor een build die tien minuten duurt op een door GitHub gehoste 2-core x64-runner (GitHub-catalogusprijzen per september 2026, CRACI per oktober 2026):

Build van tien minuten, 1000 keer per maand	GitHub-hosted	CRACI
Doorlooptijd per build	10 minuten	Ongeveer 5 minuten
Kosten per build	$0.060	$0.020
Kosten per maand	Ongeveer $60	Ongeveer $20

Dat is ongeveer 67% lager, of 3 keer goedkoper. Zonder de versnelling blijft alleen het verschil in catalogusprijs over, ongeveer 33% op 2-core x64. Hoeveel sneller uw eigen builds worden, hangt af van de workload, dus verplaats één workflow en meet het.

Facturering per seconde

Buildminuten worden per seconde gemeten, afgerond op de dichtstbijzijnde seconde. GitHub rondt elke job naar boven af op een hele minuut, dus een matrix van korte jobs wordt gefactureerd voor tijd die nooit is gebruikt: een job van 30 seconden kost op CRACI ongeveer 67% minder, en een job van 70 seconden ongeveer 61% minder. Bij lange jobs nadert het verschil de kloof in catalogusprijs.

Buildminuten kosten $0.002 per vCPU-minuut, of $0.004 per minuut voor een runner van formaat 2, tegen hetzelfde tarief op ARM64. CRACI is niet de goedkoopste runner op de markt, en de prijs is niet het argument: het argument is wat de runner vastlegt terwijl hij draait. Zie prijzen.

Hoe CRACI zich verhoudt tot andere GitHub Actions-runners

Blacksmith, Depot, Namespace en WarpBuild werken allemaal op dezelfde manier als CRACI: uw workflows blijven op GitHub Actions, alleen de plek waar de job draait verandert. Qua snelheid en prijs liggen ze dicht bij elkaar, en verschillende noemen een lagere ARM-prijs dan CRACI. Het verschil zit in wat de runner vastlegt en controleert terwijl de job draait.

CRACI is een van de voordeligste runners, en het is de runner die een SBOM maakt van wat de job daadwerkelijk heeft opgehaald, een fail-closed egressbeleid afdwingt en herkomstgegevens via zijn API levert. Dat alles als bijproduct van het draaien van de build, zonder iets aan de workflow toe te voegen. Wilt u de volledige vergelijking rij voor rij? Zie GitHub Actions-runners vergeleken.

Wat goed draait op CRACI

Alles wat een GitHub Actions-job doet: applicatiebuilds, containerimages, testsuites. Twee gevallen springen eruit: Yocto- en BitBake-builds van embedded Linux-images, gedocumenteerd tot runners van formaat 32, en pi-gen-builds van Raspberry Pi OS.

Op de roadmap

• Windows- en macOS-runners: op de roadmap.
• Door de klant gehoste runners: op de roadmap, voor Enterprise.
• Andere CI-systemen: momenteel GitHub Actions, andere op de roadmap, nog zonder datum.