CRACI vs RunsOn

La risposta breve

RunsOn offre runner GitHub Actions self-hosted senza l'onere di mantenere una flotta di runner. Un solo stack CloudFormation o modulo Terraform lo distribuisce nel Suo account AWS; ogni job riceve poi una nuova istanza EC2 del tipo che preferisce, e AWS fattura il calcolo al costo. Se vuole runner all'interno del Suo account cloud e la spesa di calcolo più bassa possibile, soprattutto sulle istanze spot, RunsOn è difficile da battere.

CRACI è una CI che gestisce nativamente la sicurezza della supply chain. È un runner gestito compatibile con GitHub Actions, e la sicurezza fa parte del runner anziché essere uno strumento aggiunto: CRACI registra ogni dipendenza esterna scaricata dalla build, applica una policy di egress sulla rete di build e trasforma quel record in SBOM, monitoraggio delle vulnerabilità ed evidenze. Entrambi i prodotti sostituiscono il runner su cui girano i Suoi job, quindi va scelto uno dei due.

In sintesi

Che cosa fa bene RunsOn

Il Suo account, i Suoi dati. Il control plane, le VM dei runner, la cache S3 e i log si trovano tutti nel Suo account AWS, e i flussi di dati di RunsOn si limitano a validazione della licenza, telemetria e supporto. Per i team la cui revisione di sicurezza si ferma a "una terza parte esegue il nostro codice e i nostri secret", questa è la risposta che RunsOn è progettato per dare. Oggi i runner CRACI sono gestiti; i runner ospitati dal cliente sono nella roadmap di CRACI per Enterprise.

Qualsiasi istanza, una per job. L'etichetta runs-on sceglie la macchina, quindi un job può richiedere una grande istanza ottimizzata per il calcolo, una GPU, storage NVMe locale o Windows. Ogni job riceve una nuova istanza EC2 che viene distrutta al termine, e RunsOn afferma che i job si avviano di solito in circa 30 secondi, o in meno di 6 con i warm pool.

Costi. RunsOn non aggiunge alcun ricarico al calcolo AWS e addebita una licenza fissa, da circa $348 (€300) all'anno. Afferma che il risultato è da 7 a 12 volte più economico dei runner ospitati da GitHub. Le istanze spot con fallback automatico su on-demand riducono ulteriormente la spesa. Queste sono cifre di RunsOn; il numero reale dipende dal Suo mix di istanze e dalla regione.

Caching e osservabilità. Una cache basata su S3 nel Suo VPC sostituisce la cache di GitHub senza il suo limite di dimensione, il caching dei layer Docker è integrato, e gli sticky disk EBS e i volumi condivisi EFS conservano lo stato tra i job. Metriche per job e report sui costi confluiscono in CloudWatch e OpenTelemetry.

Componenti aggiuntivi di sicurezza. Un'integrazione con StepSecurity Harden-Runner aggiunge monitoraggio e filtraggio dell'egress e rilevamento delle manomissioni del codice sorgente durante la build, con una licenza enterprise StepSecurity.

Prezzi e dimensioni

Per il solo calcolo, RunsOn su istanze spot costa una frazione dei $0.004 per minuto con 2 vCPU di CRACI. Il confronto però non si ferma al minuto. Con RunsOn paga anche la licenza e i servizi AWS attorno ai runner, come i NAT gateway per gli IP statici, e lo stack resta a carico del Suo team: aggiornamenti, quote AWS e incidenti. CRACI ha un unico prezzo al minuto, misurato al secondo, senza canone mensile, e l'infrastruttura la gestisce CRACI. Consulti i prezzi di CRACI per le condizioni attuali e runner gestiti e self-hosted per un quadro più ampio dei compromessi.

Quanto alla velocità, CRACI esegue le build circa due volte più velocemente dei runner ospitati da GitHub, grazie a hardware più veloce, tempi di coda più brevi e caching. La velocità di RunsOn dipende dal tipo di istanza scelto. Non abbiamo effettuato benchmark tra i due.

In che cosa CRACI è diverso

Un record di ciò che la build ha scaricato

Durante l'esecuzione di ogni job, un proxy che riconosce i pacchetti registra il traffico verso le sorgenti dei pacchetti: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e sorgenti Git, oltre ai preset di download. Le evidenze sulle dipendenze viaggiano con le cache CI, quindi anche i pacchetti ripristinati da una cache vengono conteggiati. Questo comprende le dipendenze nascoste che nessun lockfile elenca, come il codice scaricato da hook di installazione o script di build, e i layer delle immagini base. Ogni job produce una SBOM CycloneDX o SPDX con uno stato di completezza per job e per cache.

Controllo su ciò che la build può raggiungere

I security group decidono quali reti può raggiungere un runner RunsOn; non sanno quale package registry un job dovrebbe usare. La policy di egress di CRACI sì: negazione o autorizzazione predefinita, 24 preset integrati di sorgenti software, sorgenti personalizzate tipizzate per npm, PyPI, apt, apk, il proxy Go, Nix, Cargo, registry OCI e Git su HTTPS e SSH, e regole esplicite per TLS, TCP, UDP e ICMP. Le policy vengono convalidate prima dell'avvio del job, operano in modalità fail closed e inviano un avviso in caso di violazione. Poiché la policy consente solo ciò di cui la build ha bisogno, blocca l'esfiltrazione verso gli host di cui la build non ha bisogno, anche in un attacco mai visto prima.

Harden-Runner su RunsOn va oltre su un punto: sorveglia anche la modifica dei file sorgente durante la build, cosa che CRACI non fa.

Provenance e monitoraggio

L'API restituisce SBOM, tracce di rete e provenance. CRACI non firma la provenance e non dichiara alcun livello SLSA. Aggrega le vulnerabilità tra build e repository e continua a rivalutare le SBOM monitorate.

Due domande di sicurezza diverse

RunsOn risponde a "chi detiene il mio codice, i miei secret e lo stato dei miei runner?" mantenendo tutto nel Suo account AWS. CRACI risponde a una domanda diversa: "che cosa ha scaricato questa build e a che cosa si è connessa?" CRACI esegue ogni job in una VM isolata dedicata, non conserva il Suo codice sorgente ed è certificato ISO 27001. La seconda risposta è quella che Le chiedono un auditor, un cliente o il Cyber Resilience Act.

Prenoti una demo per vedere la SBOM, la traccia di rete e la provenance di uno dei Suoi workflow.

Quale scegliere

RunsOn è più adatto quando

• I runner devono girare all'interno del Suo account AWS, accanto alle risorse del Suo VPC.
• Il costo di calcolo più basso è la priorità e Lei è a Suo agio nel gestire uno stack in AWS.
• Le servono oggi runner Windows, istanze GPU o tipi specifici di istanze EC2.
• I Suoi progetti non sono commerciali, un caso che RunsOn copre gratuitamente.

CRACI è più adatto quando

• Distribuisce software per cui deve mostrare che cosa è entrato in ogni release, a partire dalla build stessa.
• Vuole limitare ciò che le build possono raggiungere, con una policy fail closed che non richiede licenze aggiuntive.
• Le serve il monitoraggio di ciò che è stato distribuito, senza aggiungere strumenti a ogni workflow.
• Preferisce non gestire infrastruttura CI e vuole le build su infrastruttura europea.

A che cosa rinuncia con CRACI. Runner nel Suo account AWS, che sono in roadmap per Enterprise, runner Windows, anch'essi in roadmap, e la spesa di calcolo più bassa. Ciò che ottiene è un record di build che sicurezza e compliance possono usare senza un altro scanner nella pipeline, su un'infrastruttura che non deve gestire.

Per il Cyber Resilience Act

Il Cyber Resilience Act dell'UE richiede ai fabbricanti di sapere che cosa contiene ogni release e di gestirne le vulnerabilità, con obblighi di segnalazione da settembre 2026 e piena applicazione da dicembre 2027. Un runner self-hosted non produce da solo queste evidenze; dovrebbe aggiungere strumenti SBOM e di scansione ai Suoi workflow. CRACI le produce dal record della build ed esporta le SBOM in CycloneDX o SPDX. Automatizza una parte significativa della visibilità e delle evidenze sulla software supply chain di cui le aziende hanno bisogno nel loro più ampio processo di conformità al CRA.

Passare da RunsOn

CRACI sostituisce il runner, non GitHub Actions. I workflow e l'interfaccia di GitHub restano gli stessi, e l'etichetta del job diventa runs-on: craci. I job dispongono di Docker Engine, Buildx e Compose v2, di un'immagine Ubuntu 24.04 compatibile con GitHub e della virtualizzazione annidata su x86-64. Scopra di più sull'integrazione CI/CD e sulla generazione di SBOM in fase di build. Le startup possono candidarsi al programma startup.

RunsOn e CRACI: domande frequenti

Prezzi, hosting, piattaforme e sicurezza, in base alle informazioni pubblicate da ciascun vendor

Che cos'è RunsOn?

RunsOn offre runner GitHub Actions self-hosted sotto forma di prodotto. Lei distribuisce uno stack CloudFormation o un modulo Terraform nel Suo account AWS, e RunsOn avvia una nuova istanza EC2 per ogni job e la termina alla fine del job. Runner, cache, log e credenziali restano nel Suo account AWS. È stato fondato nel 2023 da Cyril Rohr, che vive a Rennes, in Francia.

Quanto costa RunsOn?

A settembre 2026, RunsOn addebita una licenza annuale fissa per entità giuridica: da circa $348 (€300) all'anno per Starter, circa $1,044 (€900) per Growth, circa $2,088 (€1,800) per Scale e circa $4,176 (€3,600) per Enterprise, a seconda di quanti runner avvia al mese. AWS fattura direttamente il calcolo, al secondo, senza ricarico di RunsOn. RunsOn indica un'istanza spot x64 da 2 vCPU in us-east-1 a circa $0.0009 al minuto. È gratuito per uso non commerciale e prevede una prova di 15 giorni.

RunsOn costa meno di CRACI?

Per il calcolo sì, e con un ampio margine sulle istanze spot. CRACI addebita $0.004 per minuto con 2 vCPU, mentre un'istanza spot da 2 vCPU tramite RunsOn costa circa $0.0009 al minuto in us-east-1, più la licenza. Il totale comprende anche la rete e lo storage AWS e il tempo per gestire lo stack. Ciò che CRACI aggiunge sul runner è il record della build: una SBOM per ogni job, una policy di egress, dati di provenance e il monitoraggio delle vulnerabilità.

RunsOn genera SBOM o provenance di build?

Non figura tra le funzionalità documentate. RunsOn si concentra su calcolo, caching, costi e osservabilità nel Suo account AWS. CRACI registra i pacchetti scaricati da ogni job, compresi quelli ripristinati dalle cache, e produce una SBOM CycloneDX o SPDX con uno stato di completezza. L'API restituisce SBOM, tracce di rete e provenance.

RunsOn può limitare ciò che una build può raggiungere in rete?

I runner RunsOn si trovano nel Suo VPC, quindi si applicano i security group e il routing di AWS, e gli IP di egress statici provengono dai NAT gateway. Per il filtraggio dell'egress all'interno del job, RunsOn integra StepSecurity Harden-Runner, che costruisce una baseline del traffico in uscita di ogni job e può applicarla come allow list; su RunsOn richiede una licenza enterprise StepSecurity. CRACI applica una policy di egress sul runner stesso: negazione o autorizzazione predefinita, 24 preset integrati di sorgenti software, convalida prima dell'avvio del job e modalità fail closed.

Posso eseguire CRACI nel mio account AWS?

Oggi no. I runner CRACI sono gestiti, su infrastruttura europea, e i runner ospitati dal cliente sono in roadmap per il piano Enterprise. Se i runner all'interno del Suo account AWS sono un requisito imprescindibile, RunsOn è fatto esattamente per questo.

CRACI supporta runner Windows o macOS?

Oggi CRACI esegue Linux su x86-64 e ARM64, con Windows e macOS in roadmap. RunsOn offre Windows Server 2022 e 2025 e istanze GPU; anche con RunsOn i job macOS restano sui runner ospitati da GitHub.

Devo riscrivere i miei workflow GitHub Actions per passare a CRACI?

No. Entrambi i prodotti sostituiscono il runner, non GitHub Actions. Workflow, trigger e interfaccia di GitHub restano gli stessi; su CRACI l'etichetta del job diventa runs-on: craci.