CRACI is the runner your builds run on

One line moves the build

CRACI replaces the runner, not GitHub Actions. Your workflow files, actions and secrets stay where they are; the job changes where it executes:

jobs:
  build:
    runs-on: craci

Runs still appear in GitHub, so pull requests, checks and logs stay in the place your team already looks. Setting that up is the job of the GitHub App, which you install on all or selected repositories.

What the runners are

• Sizes 1 to 32 compute units, each 1 vCPU and 3 GB RAM, default 2. Set the size per job with cracicorp/setup@v1 and its size: input.
• Native x86-64 and ARM64 at the same rate. ARM64 capacity is limited today.
• Images: CRACI Slim, CRACI Slim ARM64, and a GitHub-compatible Ubuntu 24.04 image, with Docker Engine, Buildx and Compose v2.
• Isolated virtual machines per job. Nested virtualization is available on x86-64 and in preview on ARM64.
• Caching: GitHub Actions cache, plus container layer caching — local, remote and bind mount layer caches.
• Pipeline plumbing: a stable egress IP range and organization-level runner templates.
• Linux today. Windows and macOS runners are on the roadmap.

Runners are managed by CRACI and execute on European bare-metal infrastructure, with EU data residency. Customer-hosted runners are on the roadmap for Enterprise; see managed versus self-hosted runners for the trade-off.

Why the runner is where supply chain security belongs

The production build is not the build on a laptop. Version ranges resolve differently, tags move, caches are warm or cold, and the environment is not the same. The only reliable record of what shipped is the one taken while the release build ran — which is why CRACI put the recorder in the runner rather than next to it. The full argument is on why supply chain security belongs in CI.

Because CRACI owns the runner, it can do things a scanner cannot:

• Record, not scan. A package-aware proxy observes what the job actually downloads, including transitive dependencies and packages restored from CI caches. Each job's SBOM carries a completeness state.
• Enforce egress policy. The policy is enforced at the runner, validated before the job starts, and fails closed.
• Sign provenance. Signed provenance links an artifact, including OCI images, to the build that produced it.

About twice as fast as GitHub-hosted runners

CRACI runs builds about twice as fast as GitHub's standard hosted runners, on the same workflows and without changing them. The job that took ten minutes takes about five.

Faster CI is worth more than the minutes it saves. A pull request that goes green in five minutes is one a reviewer is still looking at; one that takes twenty is one the author has context-switched away from. Build time is the interval between writing a change and finding out whether it works, and it is paid on every push by every engineer on the team.

Three things account for it: the hardware, lower wait times, and caching.

What the speed-up costs

Because CRACI meters per second and charges less per minute, running twice as fast compounds instead of cancelling out. On a build that takes ten minutes on a GitHub-hosted 2-core x64 runner (GitHub list prices as of September 2026; €1 = $1.16):

Ten-minute build, 1,000 times a month	GitHub-hosted	CRACI
Wall-clock time per build	10 minutes	About 5 minutes
Cost per build	$0.060	€0.020, about $0.023
Cost per month	About $60	About $23

That is about 61% lower, or 2.6 times cheaper. Take the speed-up away and the saving is the list-price gap alone, about 23% on 2-core x64. How much faster your own builds get depends on the workload, so move one workflow and measure it.

Billing by the second

Build minutes are metered per second, rounded to the nearest second. GitHub rounds each job up to a whole minute, so a matrix of short jobs is billed for time it never used: a 30-second job costs about 61% less on CRACI, and a 70-second job about 55% less. Long jobs converge toward the list-price gap.

Extra build minutes are €0.004 per minute for a size 2 runner, at the same rate on ARM64. CRACI is not the cheapest runner on the market, and price is not the argument: the argument is what the runner records while it runs. See pricing.

How CRACI compares with other GitHub Actions runners

Blacksmith, Depot, Namespace and WarpBuild all work the same way CRACI does: keep your workflows on GitHub Actions, change where the job runs. On speed and price they are close to each other, and several list a lower ARM price than CRACI. The difference is what the runner records and controls while the job is running.

CRACI is not the cheapest runner and does not try to be. It is the one that produces an SBOM of what the job actually fetched, enforces an egress policy that fails closed, and signs provenance for what it built — as a by-product of running the build, with nothing added to the workflow. If you want the full row-by-row version: GitHub Actions runners compared.

What runs well on CRACI

Anything a GitHub Actions job does: application builds, container images, test suites. Two cases worth calling out are Yocto and BitBake builds of embedded Linux images, documented up to size 32 runners, and pi-gen builds of Raspberry Pi OS.

On the roadmap

• Windows and macOS runners: on the roadmap.
• Customer-hosted runners: on the roadmap, for Enterprise.
• Other CI systems: GitHub Actions today, others on the roadmap with no date yet.