CRACI vs. Jenkins

Die kurze Antwort

Jenkins bezeichnet sich als „the leading open source automation server“, und das aus gutem Grund: Es läuft überall, wo Sie es installieren, verteilt Arbeit auf so viele Maschinen, wie Sie ihm geben, und mehr als 2.300 Community-Plugins verbinden es mit fast jedem Tool. Wenn Builds vollständig in Ihrem eigenen Netzwerk bleiben müssen oder Ihre Pipelines von Plugins abhängen, für die es anderswo keine Entsprechung gibt, ist Jenkins schwer zu ersetzen.

CRACI ist eine andere Art von Produkt. Es ist ein verwalteter Runner für GitHub Actions: Sie müssen keinen Controller aktualisieren und keinen Agenten patchen. Während jeder Job läuft, zeichnet CRACI jede externe Abhängigkeit auf, die der Build lädt, setzt eine Egress-Richtlinie im Build-Netzwerk durch und erzeugt aus dieser Aufzeichnung SBOMs, Provenienzdaten und Schwachstellenüberwachung. Jenkins kann Teile davon über Plugins leisten, die Sie auswählen, konfigurieren und aktuell halten; CRACI macht den Runner selbst zur Sicherheitsaufzeichnung.

Ein praktischer Punkt vorab. CRACI unterstützt heute GitHub Actions; Jenkins und GitLab CI sind ohne Termin auf der Roadmap. Um jetzt auf CRACI zu laufen, muss eine Jenkins-Pipeline zuerst zu einem GitHub-Actions-Workflow werden.

Auf einen Blick

Was Jenkins gut kann

Läuft dort, wo Sie es brauchen. Jenkins läuft auf Ihren eigenen Servern, in Ihrem eigenen Netzwerk, ohne SaaS-Control-Plane. Agents können Linux, Windows, macOS oder jede andere Maschine sein, die Sie anbinden können, sodass ein Controller ein Backend, einen Desktop-Client und Firmware bauen kann.

Plugins für fast alles. Das Plugin-Ökosystem ist die größte Stärke von Jenkins. Für Quellcodeverwaltung, Build-Tools, Testberichte, Deployment-Ziele und Sicherheitsscanner gibt es Plugins, und Teams mit ungewöhnlichen Toolchains stellen oft fest, dass Jenkins das einzige CI ist, das sie bereits unterstützt.

Keine Lizenzkosten. Jenkins ist kostenlos und Open Source. Ihre Kosten sind die Maschinen, auf denen es läuft, und die Zeit, die Ihr Team für den Betrieb aufwendet.

Worin sich CRACI unterscheidet

Nichts zu betreiben

Eine Jenkins-Installation ist ein System, für das Ihr Team zuständig ist: der Controller, die Agents, die Plugins und die Upgrades. Das Jenkins-Projekt veröffentlicht häufig Sicherheits-Advisories für Core und Plugins, 2026 mehrere pro Monat (zum Beispiel am 2. und 16. September und am 5. August), und jedes davon einzuspielen ist Ihre Aufgabe. CRACI führt Jobs auf verwalteten Runnern aus, in isolierten virtuellen Maschinen mit einer VM pro Job, es gibt also keinen Build-Server, den Sie patchen müssten.

Die SBOM stammt aus dem Build

Auf Jenkins stammt eine SBOM aus einem Plugin oder einem Scanner-Schritt, den Sie hinzufügen und der meist nachträglich Manifeste und Lockfiles liest. Builds tun oft mehr, als diese Dateien sagen: Install-Skripte laden Code herunter, Build-Skripte laden zur Build-Zeit nach, und Caches stellen Pakete wieder her, die kein Lockfile erwähnt. CRACI sieht diesen Datenverkehr, weil es der Runner ist. Ein paketbewusster Proxy zeichnet auf, was jeder Job von Paketquellen lädt, über npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk und Git-Quellen hinweg, und die Abhängigkeitsnachweise reisen mit CI-Caches mit. Jede SBOM in CycloneDX oder SPDX gibt an, wie vollständig sie ist, pro Job und pro Cache.

Eine Richtlinie für das Build-Netzwerk

Auf Jenkins bedeutet die Kontrolle darüber, was ein Build erreichen darf, Firewall-Regeln oder Proxys rund um Ihre Agents, die Sie entwerfen und pflegen. Auf CRACI entscheidet eine Egress-Richtlinie pro Job, welche Hosts er erreichen darf: standardmäßig sperrend oder standardmäßig erlaubend, mit 24 integrierten Presets für Softwarequellen und typisierten eigenen Quellen, vor dem Start des Jobs validiert. Richtlinien blockieren im Zweifel (fail closed), und Verstöße lösen eine Warnung aus.

Überwachung des Ausgelieferten

Die API liefert SBOMs, Netzwerk-Traces und Provenienz. CRACI führt Schwachstellen über Builds und Repositories hinweg zusammen, bewertet überwachte SBOMs laufend neu, sobald Advisories erscheinen, und zeigt, welche früheren Builds eine verwundbare Abhängigkeit enthielten, sodass Sie den Zeitraum kennen, in dem Sie betroffen waren.

Preise pro Build-Minute

Jenkins hat keine Lizenzgebühr, doch sein Betrieb ist nicht kostenlos: Sie zahlen für Controller und Agents, ob ausgelastet oder im Leerlauf, und für die Menschen, die sie aktuell halten. CRACI berechnet nur Build-Minuten: $0.002 pro vCPU-Minute ($0.004 für einen Standard-Runner mit 2 vCPU), sekundengenau abgerechnet, ohne Monatsgebühr und ohne Gebühr pro SBOM.

Was zu Ihnen passt

• Bleiben Sie bei Jenkins, wenn Builds vollständig auf Ihrer eigenen Infrastruktur laufen müssen, wenn Sie von Plugins ohne Entsprechung in GitHub Actions abhängen, wenn Sie Windows- oder macOS-Builds brauchen oder wenn Sie die Leute haben, es zu betreiben, und es funktioniert.
• Wählen Sie CRACI, wenn Ihr Code auf GitHub liegt, Sie Pipelines zu GitHub Actions migrieren oder dazu bereit sind und Sie keine Build-Server mehr betreiben, aber eine Aufzeichnung dessen gewinnen wollen, was in jedes Release eingeflossen ist.
• Nutzen Sie beide während eines schrittweisen Umzugs: Migrieren Sie neue Projekte und Linux-Pipelines zu GitHub Actions auf CRACI und lassen Sie stabile Jenkins-Jobs, wo sie sind.

Seien Sie sich im Klaren darüber, worauf Sie mit CRACI heute verzichten. Es führt nur Linux-Jobs aus; Windows und macOS sind auf der Roadmap, vom Kunden gehostete Runner sind für Enterprise auf der Roadmap, und Jenkins-Pipelines müssen zu GitHub-Actions-Workflows werden, bis die Unterstützung für Jenkins kommt.

Für regulierte Produkte

Frameworks wie der EU Cyber Resilience Act erwarten von Herstellern, dass sie wissen, was in jedem Release steckt, und seine Schwachstellen behandeln, mit Meldepflichten ab September 2026. Auf Jenkins stammen diese Nachweise aus den Plugins und Scannern, die Sie in jede Pipeline einbinden. CRACI erzeugt sie aus der Build-Aufzeichnung und exportiert SBOMs als CycloneDX oder SPDX. Es automatisiert einen erheblichen Teil der Transparenz und der Nachweise zur Software-Lieferkette, die ein Unternehmen für seinen umfassenderen CRA-Prozess braucht; keines der beiden Tools macht ein Produkt allein konform.

Eine Pipeline zu CRACI migrieren

Der GitHub Actions Importer von GitHub wandelt Jenkins-Pipelines in GitHub-Actions-Workflows um. GitHub strebt an, dass 80 % jedes Workflows automatisch konvertiert werden, und sagt, dass jeder konvertierte Workflow geprüft werden sollte, bevor er in Produktion läuft. Planen Sie also etwas Handarbeit ein. Sobald eine Pipeline als GitHub-Actions-Workflow läuft, läuft sie mit einer Zeile auf CRACI:

runs-on: craci

Läufe erscheinen weiterhin in der GitHub-Oberfläche. Lesen Sie mehr über SBOM-Generierung während des Builds, sehen Sie sich die Jenkins-Alternativen an, vergleichen Sie CI/CD-Plattformen, oder sehen Sie sich die Preise an.