CRACI vs Azure Pipelines

The short answer

Azure Pipelines is the CI/CD part of Azure DevOps. It builds and tests on Linux, Windows and macOS, works with Azure Repos and GitHub, and deploys to virtual machines, containers, on-premises and cloud targets. If your work tracking, repositories and releases live in Azure DevOps, or you need Windows and macOS builds from one Microsoft contract, it fits well.

CRACI covers a narrower part and goes deeper into it. It is a runner for GitHub Actions: while each job runs, it 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. In Azure Pipelines, that evidence comes from the tasks and tools you add to each pipeline.

One practical point comes first. CRACI supports GitHub Actions only today, with GitLab CI and Jenkins on the roadmap. Azure Pipelines is not supported, so a pipeline moves to a GitHub Actions workflow to run on CRACI.

At a glance

What Azure Pipelines does well

One platform with Azure DevOps. Pipelines sit next to work tracking, Azure Repos and Azure Artifacts, so work items, code, builds and packages live in one place. It also builds code hosted on GitHub.

Every operating system. Microsoft-hosted agents run Linux, Windows and macOS, and one parallel job runs any of them at the same price. Self-hosted agents extend that to your own machines, and Azure DevOps Server brings the whole platform on-premises.

Unlimited minutes per job. A paid parallel job has no monthly minute limit, with each run allowed up to 360 minutes. A team that keeps its jobs busy all day pays a flat price however long the builds take.

Deployments built in. Pipelines carry builds through to deployment on virtual machines, containers, on-premises servers and cloud targets.

Where CRACI is different

The SBOM comes from the build

In Azure Pipelines, an SBOM comes from a task 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 Microsoft-hosted agents, what a build may reach is not yours to set; on self-hosted agents, it is network plumbing you build and maintain. CRACI puts an egress policy on each job: 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.

Paying per minute, not per parallel job

Azure Pipelines sells concurrency: each build you want running at the same time needs its own $40-a-month hosted job, on one size of 2 cores and 7 GB. Busy 8 hours on each of 22 working days, a job works out to about $0.0038 a minute, a little below CRACI's $0.004 for 2 vCPU. Busy half that time, it is about $0.0076. Builds come in bursts, so the jobs bought for the busiest hour sit idle the rest of the day.

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. A job that needs more power can use up to 32 vCPU. See CI runner pricing for the full comparison.

Which one fits

• Stay with Azure Pipelines if your work tracking, repositories and releases live in Azure DevOps, if you need Windows or macOS builds, if you deploy from the same pipelines, or if your jobs are busy all day.
• Choose CRACI if your code is on GitHub or moving there, and you want each build to produce a record of what went into the release, priced by the build minute.
• Use both during a gradual move: the choice is per pipeline, so Linux builds can move to GitHub Actions on CRACI while Windows, macOS and deployment pipelines stay.

Be clear about what you give up by choosing CRACI. It does not deploy software, it runs Linux jobs only today with Windows and macOS on the roadmap, and customer-hosted runners are on the roadmap for Enterprise.

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. In Azure Pipelines, that evidence comes from whichever tasks 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 Azure DevOps 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 Azure Pipelines alternatives, compare CI/CD platforms, or see pricing.