CRACI è il runner su cui girano le Sue build

Una riga sposta la build

CRACI sostituisce il runner, non GitHub Actions. I Suoi file di workflow, le action e i secret restano dove sono; cambia solo il luogo in cui il job viene eseguito:

jobs:
  build:
    runs-on: craci

Le esecuzioni continuano a comparire in GitHub, quindi pull request, check e log restano dove il Suo team già li consulta. Di questo si occupa la GitHub App, che Lei installa su tutti i repository o solo su quelli che sceglie.

Come sono fatti i runner

• Dimensioni da 1 a 32 unità di calcolo, ciascuna con 1 vCPU e 3 GB di RAM, 2 come impostazione predefinita. La dimensione si imposta per job con cracicorp/setup@v1 e il relativo input size:.
• x86-64 e ARM64 nativi alla stessa tariffa.
• Immagini: CRACI Slim, CRACI Slim ARM64 e un'immagine Ubuntu 24.04 compatibile con GitHub, con Docker Engine, Buildx e Compose v2.
• Macchine virtuali isolate per ogni job. La virtualizzazione annidata è disponibile su x86-64 e in anteprima su ARM64.
• Caching: la cache di GitHub Actions, più il caching dei layer dei container (cache dei layer locali, remote e tramite bind mount).
• Infrastruttura della pipeline: un intervallo stabile di IP in uscita e template di runner a livello di organizzazione.
• Per ora Linux. I runner Windows e macOS sono in roadmap.

I runner sono gestiti da CRACI e girano su infrastruttura bare-metal europea, con residenza dei dati nell'UE. I runner ospitati dal cliente sono in roadmap per Enterprise; per valutare pro e contro, veda runner gestiti e self-hosted a confronto.

Perché la sicurezza della supply chain va nel runner

La build di produzione non è la build su un portatile. Gli intervalli di versione si risolvono in modo diverso, i tag si spostano, le cache sono calde o fredde e l'ambiente non è lo stesso. L'unico record affidabile di ciò che è stato rilasciato è quello acquisito mentre girava la build di release: per questo CRACI ha messo il registratore dentro il runner anziché accanto a esso. L'argomentazione completa è in perché la sicurezza della supply chain va nella CI.

Poiché il runner è di CRACI, CRACI può fare cose che uno scanner non può fare:

• Registrare, non scansionare. Un proxy che riconosce i pacchetti osserva ciò che il job scarica effettivamente, comprese le dipendenze transitive e i pacchetti ripristinati dalle cache CI. La SBOM di ogni job riporta uno stato di completezza.
• Applicare una policy di egress. La policy viene applicata sul runner, convalidata prima dell'avvio del job ed è fail-closed.
• Restituire le evidenze. L'API restituisce SBOM, tracce di rete e provenance per ogni job.

Circa due volte più veloce dei runner ospitati da GitHub

CRACI esegue le build circa due volte più velocemente dei runner standard ospitati da GitHub, con gli stessi workflow e senza modificarli. Il job che richiedeva dieci minuti ne richiede circa cinque.

Una CI più veloce vale più dei minuti che fa risparmiare. Una pull request che diventa verde in cinque minuti è ancora sotto gli occhi del revisore; se ne richiede venti, l'autore è già passato ad altro. Il tempo di build è l'intervallo tra scrivere una modifica e scoprire se funziona, e lo paga ogni ingegnere del team a ogni push.

Le ragioni sono tre: l'hardware, tempi di attesa più brevi e il caching.

Quanto costa la maggiore velocità

Poiché CRACI misura al secondo e costa meno al minuto, andare due volte più veloce moltiplica il vantaggio anziché annullarlo. Su una build che richiede dieci minuti su un runner x64 a 2 core ospitato da GitHub (prezzi di listino di GitHub a settembre 2026, di CRACI a ottobre 2026):

Build da dieci minuti, 1.000 volte al mese	GitHub-hosted	CRACI
Tempo reale per build	10 minuti	Circa 5 minuti
Costo per build	$0.060	$0.020
Costo mensile	Circa $60	Circa $20

Significa un costo inferiore di circa il 67%, ovvero 3 volte più basso. Senza la maggiore velocità, il risparmio si riduce alla sola differenza di prezzo di listino, circa il 33% su x64 a 2 core. Quanto diventino più veloci le Sue build dipende dal carico di lavoro, quindi sposti un workflow e lo misuri.

Fatturazione al secondo

I minuti di build sono misurati al secondo, arrotondati al secondo più vicino. GitHub arrotonda ogni job al minuto intero superiore, quindi una matrice di job brevi viene fatturata per tempo mai utilizzato: un job da 30 secondi costa circa il 67% in meno su CRACI, uno da 70 secondi circa il 61% in meno. Sui job lunghi il risparmio converge verso la differenza di prezzo di listino.

I minuti di build costano $0.002 per vCPU-minuto, ovvero $0.004 al minuto per un runner di dimensione 2, alla stessa tariffa su ARM64. CRACI non è il runner più economico sul mercato, e il prezzo non è il punto: il punto è ciò che il runner registra mentre è in esecuzione. Veda i prezzi.

CRACI a confronto con altri runner GitHub Actions

Blacksmith, Depot, Namespace e WarpBuild funzionano tutti come CRACI: i workflow restano su GitHub Actions e cambia il luogo in cui gira il job. Per velocità e prezzo sono vicini tra loro, e diversi indicano un prezzo ARM inferiore a quello di CRACI. La differenza sta in ciò che il runner registra e controlla mentre il job è in esecuzione.

CRACI è tra i runner più convenienti, ed è quello che produce una SBOM di ciò che il job ha effettivamente scaricato, applica una policy di egress fail-closed e restituisce i dati di provenance tramite la sua API, come sottoprodotto dell'esecuzione della build, senza aggiungere nulla al workflow. Se desidera la versione completa, riga per riga: Runner GitHub Actions a confronto.

Che cosa funziona bene su CRACI

Tutto ciò che fa un job di GitHub Actions: build di applicazioni, immagini container, suite di test. Due casi da segnalare sono le build Yocto e BitBake di immagini Linux embedded, documentate fino a runner di dimensione 32, e le build di Raspberry Pi OS con pi-gen.

In roadmap

• Runner Windows e macOS: in roadmap.
• Runner ospitati dal cliente: in roadmap, per Enterprise.
• Altri sistemi di CI: oggi GitHub Actions, altri in roadmap, ancora senza data.