CRACI vs Jenkins | GitHub Actions gestito vs CI self-hosted

La risposta breve

Jenkins si definisce "the leading open source automation server", e a ragione: gira ovunque lo si installi, distribuisce il lavoro su tutte le macchine che gli vengono assegnate, e più di 2.300 plugin della community lo collegano a quasi ogni strumento. Se le build devono restare interamente nella Sua rete, o le Sue pipeline dipendono da plugin senza equivalenti altrove, Jenkins è difficile da sostituire.

CRACI è un tipo di prodotto diverso. È un runner gestito per GitHub Actions: non c'è alcun controller da aggiornare né alcun agente da patchare. Durante l'esecuzione di ogni job, CRACI registra ogni dipendenza esterna scaricata dalla build, applica una policy di egress sulla rete della build e produce SBOM, dati di provenance e monitoraggio delle vulnerabilità da quella registrazione. Jenkins può fare parte di tutto ciò tramite plugin che Lei sceglie, configura e mantiene aggiornati; CRACI fa del runner stesso la registrazione di sicurezza.

Un punto pratico viene prima di tutto. Oggi CRACI supporta GitHub Actions, con Jenkins e GitLab CI in roadmap e senza una data. Per girare su CRACI adesso, una pipeline Jenkins deve prima diventare un workflow GitHub Actions.

In sintesi

Funzionalità	CRACI	Jenkins
Che cos'è	Un runner gestito e sicuro per GitHub Actions.	Un server di automazione open source ospitato da Lei.
Che cosa deve gestire	Niente: nessun controller o agente da far girare.	Il controller, gli agenti, gli aggiornamenti e i plugin.
Come viene prodotta la SBOM	Registrata da ciò che ogni job ha scaricato, con uno stato di completezza	Plugin o strumenti aggiunti da Lei
Policy di egress di rete per la build	Negazione o autorizzazione predefinita, validata prima del job, fail closed	Da costruire a Sua cura, sui Suoi agenti
Monitoraggio delle vulnerabilità	Le SBOM monitorate vengono rivalutate di continuo	Plugin o strumenti aggiunti da Lei
Sistemi CI	Oggi GitHub Actions; GitLab CI e Jenkins in roadmap	Pipeline Jenkins, con la maggior parte dei sistemi di controllo del codice tramite plugin
Windows e macOS	Oggi Linux su x86-64 e ARM64	Qualsiasi agente gestito da Lei
Gira sulle Sue macchine	Runner ospitati dal cliente, Enterprise	L'unica opzione
Estensibilità	GitHub Actions e il suo marketplace di action.	Più di 2.300 plugin della community.
Prezzo	$0.004 al minuto ($0.002 per vCPU-minuto), misurati al secondo. Nessun canone mensile e nessun costo per SBOM.	Gratuito e open source; si pagano le macchine e le persone che le gestiscono.

Incluso
In parte
In roadmap

Che cosa fa bene Jenkins

Gira dove serve. Jenkins gira sui Suoi server, nella Sua rete, senza alcun control plane SaaS. Gli agenti possono essere Linux, Windows, macOS o qualsiasi altra macchina collegabile, quindi un solo controller può compilare un backend, un client desktop e un firmware.

Plugin per quasi tutto. L'ecosistema dei plugin è il più grande punto di forza di Jenkins. Controllo del codice sorgente, strumenti di build, report di test, target di deployment e scanner di sicurezza hanno tutti i loro plugin, e i team con toolchain insolite scoprono spesso che Jenkins è l'unica CI che già le supporta.

Nessun costo di licenza. Jenkins è gratuito e open source. I Suoi costi sono le macchine su cui gira e il tempo che il Suo team dedica a gestirlo.

In che cosa CRACI è diverso

Niente da gestire

Un'installazione Jenkins è un sistema di cui è responsabile il Suo team: il controller, gli agenti, i plugin e gli aggiornamenti. Il progetto Jenkins pubblica spesso advisory di sicurezza per il core e i plugin, diversi al mese nel 2026 (ad esempio il 2 e il 16 settembre e il 5 agosto), e applicare ciascuno spetta a Lei. CRACI esegue i job su runner gestiti, in macchine virtuali isolate con una VM per job, quindi non c'è alcun server di build da patchare.

La SBOM proviene dalla build

Su Jenkins, una SBOM proviene da un plugin o da uno step di scansione aggiunto da Lei, che di solito legge manifest e lockfile a posteriori. Le build spesso fanno più di quanto dicano quei file: gli script di installazione scaricano codice, gli script di build scaricano durante la build e le cache ripristinano pacchetti che nessun lockfile menziona. CRACI vede quel traffico perché è il runner. Un proxy che riconosce i pacchetti registra ciò che ogni job scarica dalle sorgenti dei pacchetti, per npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e sorgenti Git, e le evidenze sulle dipendenze viaggiano con le cache CI. Ogni SBOM CycloneDX o SPDX indica quanto è completa, per job e per cache.

Una policy sulla rete della build

Su Jenkins, controllare che cosa può raggiungere una build significa regole firewall o proxy attorno ai Suoi agenti, che Lei progetta e mantiene. Su CRACI, una policy di egress su ogni job decide quali host può raggiungere: negazione o autorizzazione predefinita, con 24 preset integrati di sorgenti software e sorgenti personalizzate tipizzate, validata prima dell'avvio del job. Le policy operano in modalità fail closed, e le violazioni generano un avviso.

Monitorare ciò che è stato distribuito

L'API restituisce SBOM, tracce di rete e provenance. CRACI aggrega le vulnerabilità tra build e repository, continua a rivalutare le SBOM monitorate man mano che compaiono nuovi advisory e mostra quali build passate contenevano una dipendenza vulnerabile, così Lei conosce il periodo in cui è stato esposto.

Prezzi per minuto di build

Jenkins non ha un costo di licenza, ma gestirlo non è gratuito: Lei paga il controller e gli agenti, inattivi o occupati, e le persone che li mantengono aggiornati. CRACI addebita solo i minuti di build: $0.002 per vCPU-minuto ($0.004 per un runner predefinito da 2 vCPU), misurati al secondo, senza canone mensile e senza costo per SBOM.

Quale scegliere

Resti su Jenkins se le build devono girare interamente sulla Sua infrastruttura, se dipende da plugin senza equivalenti in GitHub Actions, se Le servono build Windows o macOS, oppure se ha le persone per gestirlo e funziona.
Scelga CRACI se il Suo codice è su GitHub, sta spostando o è pronto a spostare le pipeline su GitHub Actions e vuole smettere di gestire server di build ottenendo al tempo stesso una registrazione di ciò che è entrato in ogni release.
Usi entrambi durante una migrazione graduale: sposti i nuovi progetti e le pipeline Linux su GitHub Actions con CRACI, e lasci dove sono i job Jenkins stabili.

Sia consapevole di ciò a cui rinuncia scegliendo CRACI oggi. Esegue solo job Linux, con Windows e macOS in roadmap; i runner ospitati dal cliente sono in roadmap per Enterprise; e le pipeline Jenkins devono diventare workflow GitHub Actions finché non arriverà il supporto a Jenkins.

Per i prodotti regolamentati

Framework come il Cyber Resilience Act dell'UE si aspettano che i fabbricanti sappiano che cosa c'è in ogni release e ne gestiscano le vulnerabilità, con obblighi di segnalazione da settembre 2026. Su Jenkins, quelle evidenze provengono dai plugin e dagli scanner che Lei collega a ogni pipeline. CRACI le produce dalla registrazione 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 un'azienda ha bisogno per il suo più ampio processo CRA; nessuno dei due strumenti rende conforme un prodotto da solo.

Spostare una pipeline su CRACI

GitHub Actions Importer, lo strumento di GitHub, converte le pipeline Jenkins in workflow GitHub Actions. GitHub punta a convertire automaticamente l'80% di ogni workflow e afferma che ogni workflow convertito va ispezionato prima di andare in produzione, quindi preveda un po' di lavoro manuale. Una volta che una pipeline gira come workflow GitHub Actions, gira su CRACI con una sola riga:

runs-on: craci

Le esecuzioni continuano a comparire nell'interfaccia di GitHub. Approfondisca la generazione di SBOM in fase di build, veda le alternative a Jenkins, confronti le piattaforme CI/CD oppure consulti i prezzi.