CRACI vs Jenkins

The short answer

Jenkins calls itself "the leading open source automation server", and for good reason: it runs anywhere you install it, distributes work across as many machines as you give it, and more than 2,300 community plugins connect it to almost any tool. If builds must stay entirely inside your own network, or your pipelines depend on plugins with no equivalent elsewhere, Jenkins is hard to replace.

CRACI is a different kind of product. It is a managed runner for GitHub Actions: there is no controller to upgrade and no agent to patch. While each job runs, CRACI records every external dependency the build pulls in, enforces an egress policy on the build network, and produces SBOMs, provenance data and vulnerability monitoring from that record. Jenkins can do parts of that through plugins you choose, configure and keep current; CRACI makes the runner itself the security record.

One practical point comes first. CRACI supports GitHub Actions today, with Jenkins and GitLab CI on the roadmap and no date. To run on CRACI now, a Jenkins pipeline moves to a GitHub Actions workflow first.

At a glance

What Jenkins does well

Runs where you need it. Jenkins runs on your own servers, in your own network, with no SaaS control plane involved. Agents can be Linux, Windows, macOS or any other machine you can connect, so one controller can build a backend, a desktop client and firmware.

Plugins for almost everything. The plugin ecosystem is Jenkins' biggest strength. Source control, build tools, test reports, deployment targets and security scanners all have plugins, and teams with unusual toolchains often find Jenkins is the only CI that already supports them.

No license cost. Jenkins is free and open source. Your costs are the machines it runs on and the time your team spends running it.

Where CRACI is different

Nothing to operate

A Jenkins installation is a system your team owns: the controller, the agents, the plugins and the upgrades. The Jenkins project publishes security advisories for core and plugins often, several a month in 2026 (for example on 2 and 16 September and 5 August), and applying each one is your job. CRACI runs jobs on managed runners, in isolated virtual machines with one VM per job, so there is no build server for you to patch.

The SBOM comes from the build

On Jenkins, an SBOM comes from a plugin or a scanner step you add, which usually reads manifests and lockfiles after the fact. Builds often do more than those files say: install scripts download code, build scripts fetch at build time, and caches restore packages that no lockfile mentions. CRACI sees that traffic because it is the runner. A package-aware proxy records what each job fetches from package sources, across npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk and Git sources, and dependency evidence travels with CI caches. Each CycloneDX or SPDX SBOM states how complete it is, per job and per cache.

A policy on the build network

On Jenkins, controlling what a build may reach means firewall rules or proxies around your agents, which you design and maintain. On CRACI, an egress policy on each job decides which hosts it may reach: default deny or default allow, with 24 built-in software-source presets and typed custom sources, validated before the job starts. Policies fail closed, and violations send an alert.

Monitoring what shipped

The API returns SBOMs, network traces and provenance. CRACI aggregates vulnerabilities across builds and repositories, keeps re-evaluating monitored SBOMs as advisories appear, and shows which past builds contained a vulnerable dependency, so you know the period you were affected.

Pricing per build minute

Jenkins has no license fee, but it is not free to run: you pay for the controller and agents, idle or busy, and for the people who keep them current. CRACI charges only for build minutes: $0.002 per vCPU-minute ($0.004 for a default 2 vCPU runner), metered per second, with no monthly fee and no per-SBOM charge.

Which one fits

• Stay with Jenkins if builds must run entirely on your own infrastructure, if you depend on plugins with no GitHub Actions equivalent, if you need Windows or macOS builds, or if you have the people to run it and it works.
• Choose CRACI if your code is on GitHub, you are moving or ready to move pipelines to GitHub Actions, and you want to stop running build servers while gaining a record of what went into each release.
• Use both during a gradual move: move new projects and Linux pipelines to GitHub Actions on CRACI, and leave stable Jenkins jobs where they are.

Be clear about what you give up by choosing CRACI today. It runs Linux jobs only, with Windows and macOS on the roadmap; customer-hosted runners are on the roadmap for Enterprise; and Jenkins pipelines need to become GitHub Actions workflows until Jenkins support arrives.

For regulated products

Frameworks such as the EU Cyber Resilience Act expect manufacturers to know what is in each release and to handle its vulnerabilities, with reporting obligations from September 2026. On Jenkins, that evidence comes from whichever plugins and scanners you wire into each pipeline. CRACI produces it from the build record and exports SBOMs as CycloneDX or SPDX. It automates a significant part of the software supply chain visibility and evidence a company needs for its wider CRA process; neither tool makes a product compliant on its own.

Moving a pipeline to CRACI

GitHub's own GitHub Actions Importer converts Jenkins pipelines into GitHub Actions workflows. GitHub aims for 80% of each workflow to convert automatically and says every converted workflow should be inspected before it runs in production, so plan for some manual work. Once a pipeline runs as a GitHub Actions workflow, it runs on CRACI with one line:

runs-on: craci

Runs still appear in the GitHub UI. Read more about build-time SBOM generation, see Jenkins alternatives, compare CI/CD platforms, or see pricing.