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, 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. At an exchange rate of €1 = $1.16, CRACI's minute costs about $0.0046, roughly 23% 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 23%. The shorter build is what takes it to about 61%. 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; the Pro plan is €30 per month until the end of 2026 and includes 10,000 build minutes. Inside those allowances, the marginal cost on both sides 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 the per-minute gap there is smaller. At 32 vCPUs, CRACI costs €0.064 (about $0.074) per minute against 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 and OCI, plus operating system packages and source downloads. 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 email 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

CRACI signs provenance that links each artifact, including OCI images, to the build that produced it, using Ed25519 over SHA-512, and the API traces an artifact to its build, SBOM and network trace. CRACI does not claim a 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 a formal SLSA level is a requirement for you, that is a point in GitHub's favor today.

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.
• 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.