CRACI vs CircleCI

The short answer

CircleCI is a mature, flexible CI/CD platform. It connects to GitHub, GitLab and Bitbucket, runs jobs on a wide range of machines from Docker containers to macOS and GPUs, and lets you package reusable configuration as orbs. For security, CircleCI protects credentials and leaves scanning to orbs and third-party tools.

CRACI takes the other approach: the runner is the security record. It runs GitHub Actions jobs, observes every external dependency each build fetches, enforces an egress policy on the build network, and produces SBOMs, signed provenance and CRA evidence from what it saw. That is the difference between traditional CI and security-aware CI.

CRACI supports GitHub Actions only today. CircleCI is not yet supported. Teams on CircleCI would need to move a pipeline to GitHub Actions to use CRACI runners, or wait until other CI systems are supported.

What CircleCI does well

Breadth of compute. CircleCI offers Docker, Linux VM, Arm, Windows, macOS and GPU resource classes, so one platform can build a backend, a Windows client and an iOS app. Self-hosted runners extend that to your own Linux, Windows and macOS machines and to Kubernetes, and runner job time does not consume credits.

Speed features. Docker layer caching is available on all plans. Test splitting spreads a suite across parallel executors by name, file size or historical timing data, which cuts wall-clock time on large test suites.

Reusable configuration. Orbs package jobs, commands and executors so teams can reuse them across projects, and they make it straightforward to plug in third-party tools, including security scanners.

Credential hygiene. CircleCI's supply chain guidance centers on protecting secrets: split them into contexts, put deploy and signing keys in restricted contexts governed by your VCS groups, and use OIDC tokens so jobs reach cloud services without long-lived credentials stored in CircleCI.

Where CRACI is different

The build is the source of truth

On a traditional CI platform, an SBOM is produced by a tool you add to the pipeline, which usually reads manifests and lockfiles. CRACI observes the build instead. A package-aware proxy records traffic to package sources while the job runs, across npm, PyPI, RubyGems, Cargo, Go, Nix and OCI, plus OS packages and source or download presets. Dependency evidence travels with CI caches, so a package restored from a cache is still counted.

You know how complete the SBOM is

Every job produces a CycloneDX or SPDX SBOM with a completeness state per job and per cache: Complete, Complete with connections, Incomplete, Unavailable or Not recorded.

The build network has a policy

CircleCI's IP ranges feature routes jobs through known CircleCI addresses so your own systems can allowlist them. That solves inbound access. CRACI adds control in the other direction: egress policies for each job, default deny or default allow, with 24 built-in software-source presets, typed custom sources, and explicit TLS, TCP, UDP and ICMP rules. Policies are validated before the job starts and fail closed. CRACI also provides a stable egress IP range.

Provenance and monitoring from the same record

CRACI signs provenance that links each artifact, including OCI artifacts, to its build, using Ed25519 over SHA-512. It aggregates vulnerabilities across builds and repositories and keeps re-evaluating monitored SBOMs.

Which one fits

• Stay with CircleCI if your code is on GitLab or Bitbucket, if you depend on Windows, macOS or GPU builds, or if you run jobs on your own hardware.
• Consider CRACI if your code is on GitHub and you are weighing GitHub Actions against CircleCI, and you ship software where you must show what went into each release.
• Use both during a gradual move: keep macOS and Windows pipelines on CircleCI, and run Linux GitHub Actions workflows on CRACI where build evidence matters most.

For the Cyber Resilience Act

The EU Cyber Resilience Act expects manufacturers to know what is in each release and to handle its vulnerabilities, with reporting obligations from September 2026 and full application from December 2027. On CircleCI, that evidence comes from whichever scanners and orbs you wire into your pipelines. CRACI produces it from the build record and exports reports in PDF, HTML, CSV, Excel and JSON. It automates a significant part of the software supply chain visibility and evidence that companies need for their wider CRA compliance process.

Moving a pipeline to CRACI

CRACI runs GitHub Actions workflows, so a CircleCI pipeline first needs a GitHub Actions equivalent. Once it has one, install the CRACI GitHub App on your organization and set the runner label:

runs-on: craci

Runs still appear in the GitHub UI. Jobs get Docker Engine, Buildx and Compose v2, runner sizes from 1 to 32 vCPU with 3 GB of RAM each, and GitHub Actions cache support. Read more about build-time SBOM generation, or see pricing and the startup program.