Cost
Managed CRACI runners vs self-hosted runners
Self-hosted runners look free on the invoice. The real cost is the hosts, the hours spent keeping them patched, and the hardening GitHub itself says they need. Here is a model you can fill in with your own numbers.
Why teams self-host
Teams move to self-hosted runners for good reasons. Hosted minutes add up. GitHub's larger runners cannot use included minutes. Some jobs need access to internal systems or specific hardware. Some companies have spare capacity they already pay for.
GitHub does not charge per minute for self-hosted runners today. It announced a billing change for self-hosted runners, then postponed it "to take time to re-evaluate our approach." As of September 2026, GitHub's billing docs describe self-hosted usage as free. What GitHub does not pay for is everything around the runner.
The three parts of self-hosted cost
Infrastructure
You pay for the hosts whether they run jobs or sit idle, so you size for your busiest hour. Add storage for caches and images, network traffic, and whatever you use to monitor and autoscale the fleet.
Engineering time
GitHub's documentation is direct about ownership: with self-hosted runners, "you are responsible for updating the operating system and all other software." In practice that also means runner version upgrades, image drift between hosts, disk cleanup, autoscaling scripts, and someone on call when the queue stops moving.
Security hardening
GitHub's security guidance for self-hosted runners includes two warnings worth reading in full:
Self-hosted runners should almost never be used for public repositories on GitHub, because any user can open pull requests against the repository and compromise the environment. GitHub Docs, Secure use reference
Self-hosted runners for GitHub do not have guarantees around running in ephemeral clean virtual machines, and can be persistently compromised by untrusted code in a workflow. GitHub Docs, Secure use reference
GitHub recommends just-in-time runners that run at most one job before they are removed. Doing this well means ephemeral machines, isolation between jobs, controls on outbound network traffic, and careful handling of secrets. Each of these is work you design, build and keep running.
A cost model you can fill in
Self-hosted monthly cost = host cost + (upkeep and hardening hours × your hourly cost)
CRACI Pro monthly cost (2 vCPU runners) = €30 + (minutes above 10,000 × €0.004) + (€300 × each actively monitored SBOM beyond the first)
The CRACI formula uses the Pro plan card on the pricing page, where €30 per month applies until the end of 2026 and the card shows a list price of €330. Check the pricing page for current numbers.
Example A
Illustrative inputs, not benchmarks. 60,000 build minutes a month on 2 vCPU runners, one monitored SBOM, €300 a month for runner hosts, and 8 hours a month of upkeep at €75 an hour.
- Self-hosted: €300 + (8 × €75) = €300 + €600 = €900 per month
- CRACI: 60,000 minus 10,000 included leaves 50,000 minutes. €30 + (50,000 × €0.004) = €30 + €200 = €230 per month
- CRACI at the €330 list price: €330 + €200 = €530 per month
Example B
Illustrative inputs, not benchmarks. The same 60,000 minutes, but the hosts cost €100 a month and upkeep takes 2 hours at €75 an hour.
- Self-hosted: €100 + (2 × €75) = €100 + €150 = €250 per month
- CRACI: €230 per month at the current plan price, or €530 at the list price
In Example B, self-hosted is cheaper than CRACI at list price on compute alone. That is a real outcome for teams with cheap hosts and a stable setup. To find your own break-even, subtract your host cost from the CRACI figure and divide by your hourly cost. With Example A's hosts and the list price, that is (€530 minus €300) ÷ €75, or about 3 hours of upkeep a month.
Two things the formula does not show. First, the CRACI figure includes more than compute (see the next section). Second, hours are the input most teams underestimate. Count image updates, security patches, scaling, disk cleanup and the time spent on failed jobs, not just the initial setup.
What self-hosted runners do not give you
A self-hosted runner runs your job. It does not record what the job did. On CRACI runners, each build produces evidence as it runs:
- A build-time SBOM in CycloneDX or SPDX, from a package-aware proxy that observes what the job pulls, including packages restored from CI caches. Completeness is stated per job and per cache.
- Network egress policy, default deny or allow, with 24 built-in software-source presets and typed custom sources. Policies are validated before the job starts and fail closed. Violations trigger email alerts.
- A network trace per job, available through the API.
- Signed provenance that links an artifact, including OCI artifacts, to the build that produced it. Signatures are Ed25519 over SHA-512. CRACI does not claim a SLSA level.
- Vulnerability tracking across builds and repositories, with monitored SBOMs re-evaluated continuously.
- Report export in PDF, HTML, CSV, Excel and JSON.
You can build parts of this on self-hosted runners with your own proxy, SBOM tooling and signing. If you do, the time to build and maintain it belongs in the cost model above.
| Capability | CRACI | Self-hosted runners |
|---|---|---|
| Who patches the OS and runner | CRACI | You |
| Job isolation | Each job runs in an isolated virtual machine | Depends on your setup; GitHub does not guarantee ephemeral clean machines |
| Network egress | Org policies with default deny available, validated before the job starts, fail closed | Whatever firewall or proxy you build and maintain |
| SBOM | Recorded during the build, with completeness stated per job and per cache | A separate tool you add to each pipeline |
| Provenance | Signed evidence links each artifact to the build that produced it | Signing and attestation tooling you add |
| Billing | Per second of job time | Hosts cost the same whether busy or idle |
| Where jobs run | CRACI managed runners on European bare-metal infrastructure | Your own network, cloud account or hardware |
| Operating systems | Linux on x86-64 and ARM64 | Any machine you can install the runner on |
| Availability commitment | SLA with service credits: at least 99.5% of jobs start within 10 minutes | Your own monitoring and on-call |
What CRACI does not offer
Customer-hosted and on-premise CRACI runners are not offered. Builds run on CRACI's managed runners. If a job must run inside your own network, on hardware you own, or in an air-gapped environment, keep a self-hosted runner for that job.
- CRACI runners are Linux only. macOS and Windows builds stay where they are.
- x86-64 and ARM64 run at the same rate, but ARM64 capacity is limited.
-
Images: CRACI Slim, CRACI Slim ARM64, and a GitHub-compatible Ubuntu 24.04 image. Slim has no
systemd. Nested virtualization is available on x86-64 and in preview on ARM64. - GitHub Actions is the supported CI integration.
A mixed setup is common. Moving a job is a change to its runs-on line, so you can move most jobs and
keep a few on self-hosted runners. Only jobs on CRACI runners get build-time SBOMs and network policy.
How to decide
- Add up last month's host bill and the hours your team spent on runners, including incidents.
- Count your build minutes and the products that need an actively monitored SBOM.
- Put both into the formulas above.
- List the evidence you are asked for (SBOMs, provenance, network controls) and what it would take to produce it on your current runners.
- Run one real workflow on CRACI and compare.
More on how the runners work: CI/CD integration, security at CRACI, and the documentation.
Compare runners on your own workload
Book a demo and move one real workflow to CRACI. Compare cost, speed and the evidence each build produces.
Book a demo