CRACI runners vs GitHub-hosted runners

Same workflows, faster runner

If you use GitHub Actions, your jobs run on GitHub-hosted runners unless you have set up your own. They are convenient: each job gets a fresh virtual machine, there is nothing to operate, and Linux, Windows and macOS are all available.

CRACI is a GitHub Actions compatible runner. Install the CRACI GitHub App on your organization, on all repositories or a selected set, and change one line in your workflow:

runs-on: craci

Your workflow files, actions and the GitHub interface stay the same. CRACI replaces the runner, not GitHub Actions, and gives you three things a general-purpose runner does not: faster builds, a lower bill, and supply chain security built into the machine that runs the job.

Speed

Builds on CRACI finish in about half the time they take on GitHub's standard hosted runners. Three things add up: faster hardware, shorter queue times before a job starts, and caching.

How much faster your own builds get depends on the workload. CPU-bound compiles and test suites gain the most; jobs that spend most of their time waiting on the network or on external services gain less. The pieces that help:

• Runner sizes from 1 to 32 compute units, so heavy jobs can ask for more.
• Native x86-64 and ARM64, so ARM builds do not need emulation.
• GitHub Actions cache support, plus Docker Engine, Buildx and Compose v2 in every job.
• Nested virtualization on x86-64, for jobs that start their own virtual machines.

The best test is your own pipeline: move one job and compare the timings side by side in GitHub.

Cost

Two things lower the bill at the same time. Each minute is cheaper, and a faster build uses fewer of them.

CRACI bills $0.002 per vCPU-minute, metered per second, so a standard 2 vCPU Linux runner costs $0.004 per minute. GitHub lists its standard 2-core Linux x64 runner at $0.006 per minute, so CRACI's minute costs about 33% less.

A 10-minute build

Take a build that runs for 10 minutes on a GitHub-hosted 2-core runner:

The price difference alone saves about 33%. The shorter build is what takes it to about 67%. If a build is not faster on your workload, you still pay the lower per-minute price.

What else changes the bill

• Rounding. GitHub rounds each job up to a whole minute; CRACI meters per second. A job that takes 10 minutes 20 seconds is billed as 11 minutes on GitHub, and pipelines with many short jobs (lint, test shards, checks) pay for a lot of unused seconds.
• Included minutes. GitHub includes 2,000 to 50,000 minutes a month depending on your plan, and standard runners are free on public repositories. CRACI has no free tier and no included minutes: you pay per build minute from the first minute, with no monthly fee. Inside GitHub's allowance, the marginal cost there is zero.
• Architecture and size. CRACI charges the same rate for ARM64 and x86-64. GitHub's 2-core arm64 runner is $0.005 per minute, so CRACI's $0.004 is 20% less there. At 32 vCPUs, CRACI costs $0.064 per minute, about 22% less than GitHub's $0.082 on x64, but GitHub's 32-core arm64 runner at $0.050 is cheaper than CRACI's per minute. Memory differs too: a CRACI compute unit has 3 GB of RAM per vCPU, and GitHub's standard 2-core private runner has 8 GB. Match the shape your builds need before comparing.

See CRACI pricing for current terms.

Supply chain security in the runner

This is what a CRACI runner does that a general-purpose runner is not designed to do.

A record of every dependency the build fetched

While each job runs, a package-aware proxy records traffic to package sources: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk and Git sources, plus download presets. Evidence travels with CI caches, so packages restored from a cache are still counted. Every job produces an SBOM in CycloneDX or SPDX, with a completeness state per job and per cache.

GitHub's dependency graph is built from the manifests and lockfiles in your repository and can be exported as SPDX. It describes the repository, not a specific build.

Control over what a build can reach

CRACI egress policies are default deny or default allow, with 24 built-in software-source presets, typed custom sources for npm, PyPI, apt, apk, the Go proxy, Nix, Cargo, OCI registries and Git, and explicit TLS, TCP, UDP and ICMP rules. Policies are validated before the job starts, fail closed, and send an alert when violated. Under a default-deny policy, a compromised dependency that tries to reach an unexpected host is stopped at the runner.

GitHub's larger runners offer static IP addresses and Azure private networking, which let you manage outbound access through your own Azure network. That is useful, and it is a different approach: network plumbing you configure in Azure rather than a policy attached to the job.

Provenance

The API returns SBOMs, network traces and provenance. CRACI does not sign provenance and claims no SLSA level.

GitHub offers artifact attestations built on Sigstore, which GitHub states provide SLSA v1.0 Build Level 2 on their own and Level 3 with reusable workflows. If signed provenance or a formal SLSA level is a requirement for you, that is a point in GitHub's favor.

Isolation and data location

CRACI jobs run in isolated virtual machines. On the Enterprise plan, CRACI offers EU data residency, with build execution on European bare-metal infrastructure.

When to stay on GitHub-hosted runners

• You need Windows or macOS runners. CRACI is Linux only today; Windows and macOS are on the roadmap.
• Your repositories are public and standard runners cover you for free.
• Your usage fits inside your plan's included minutes.

Many teams mix both: Linux build and test jobs on CRACI, macOS and Windows jobs on GitHub. Because the switch is a runs-on label, you can move one job at a time.