GitHub Actions self-hosted runners vs managed CRACI runners

What is a GitHub Actions self-hosted runner?

A self-hosted runner is a machine you deploy and manage that runs GitHub Actions jobs instead of a GitHub-hosted VM. It can be a physical server, a virtual machine, a container, on premises or in your cloud account, and GitHub says you are responsible for the machine and all its software.

• Registration: a runner registers with one repository, organization or enterprise at a time. Register at the organization level and use runner groups to share runners across repositories.
• Platforms: the runner application supports common Linux distributions, Windows 10, 11 and Windows Server, and macOS 11 and later, on x64 and ARM64.
• Network: the runner connects to GitHub over outbound HTTPS on port 443.
• Updates: the runner application must be updated within 30 days of a new release. It updates itself unless you turn that off.
• Limits: a job can run for up to 5 days, against 6 hours on GitHub-hosted runners, and a job queued for more than 24 hours fails.
• Scaling: Actions Runner Controller (ARC), a Kubernetes operator, scales runner scale sets with the number of workflows running. Runners registered with --ephemeral take a single job.

Why teams self-host

Teams self-host to cut per-minute costs, to reach internal systems or specific hardware, and to use capacity they already pay for. GitHub's larger runners also cannot use included minutes, so big machines get expensive on hosted runners.

GitHub does not charge per minute for self-hosted runners today. It announced a $0.002 per-minute cloud platform charge for self-hosted runners from March 1, 2026, 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

Self-hosted cost is infrastructure, engineering time and security hardening. Only the first shows up on an invoice.

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.

Best practices for self-hosted runners at scale

GitHub's security guidance and AWS's published practices for runners at scale converge on the same list. Each item is a project of its own:

• Ephemeral runners: one job per machine, so nothing carries over between jobs.
• Runner groups: separate runners by repository and environment, ideally in separate accounts.
• Short-lived credentials: OpenID Connect to your cloud instead of long-lived access keys.
• Egress control: limit what a job can reach, not only what it runs.
• Startup time: warm pools and custom images, because ephemeral machines are slower to start.
• Cost: spot instances with a fallback for long-running jobs.
• Monitoring: metrics on queued, running and completed jobs, with alerts.

On CRACI the first and fourth come with the runner: every job runs in an isolated virtual machine under an egress policy that is validated before the job starts and fails closed.

A cost model you can fill in

Example A

Illustrative inputs, not benchmarks. 60,000 build minutes a month on 2 vCPU runners, $350 a month for runner hosts, and 8 hours a month of upkeep at $85 an hour.

• Self-hosted: $350 + (8 × $85) = $350 + $680 = $1,030 per month
• CRACI: 60,000 × $0.004 = $240 per month

Example B

Illustrative inputs, not benchmarks. The same 60,000 minutes, but the hosts cost $115 a month and upkeep takes 2 hours at $85 an hour.

• Self-hosted: $115 + (2 × $85) = $115 + $170 = $285 per month
• CRACI: $240 per month

In Example B, the two are close 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 B's hosts, that is ($240 minus $115) ÷ $85, or about 1.5 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, but 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 alerts.
• A network trace per job, available through the API.
• Provenance data, available through the API.
• Vulnerability tracking across builds and repositories, with monitored SBOMs re-evaluated continuously.

You can build parts of this on self-hosted runners with your own proxy, SBOM tooling and network logging. If you do, the time to build and maintain it belongs in the cost model above.

What CRACI does not offer

CRACI does not offer customer-hosted or on-premise runners today; they are on the roadmap for Enterprise. Builds run on CRACI's managed runners on European infrastructure. 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 today; Windows and macOS are on the roadmap. 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. 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

Decide on your own numbers: last month's runner cost and hours, the evidence you are asked for, and one real workflow run on each option.

1. Add up last month's host bill and the hours your team spent on runners, including incidents.
2. Count your build minutes.
3. Put both into the formulas above.
4. List the evidence you are asked for (SBOMs, provenance, network controls) and what it would take to produce it on your current runners.
5. Book a demo and run one real workflow on CRACI to compare.

More on how the runners work: CI/CD integration, security at CRACI, and the documentation.

GitHub Actions self-hosted runner FAQ

Short answers on cost, setup, security and limits.

What is a GitHub Actions self-hosted runner?

A self-hosted runner is a machine you deploy and manage that runs GitHub Actions jobs. It can be physical, virtual, a container, on premises or in a cloud account. You install the GitHub runner application on it, register it with a repository, organization or enterprise, and target it with runs-on: self-hosted or your own labels.

Are GitHub Actions self-hosted runners free?

GitHub does not charge per minute for self-hosted runners as of September 2026. It announced a $0.002 per-minute platform charge from March 1, 2026, then postponed it to re-evaluate its approach. You still pay for the machines, their storage and network, and the time to keep them patched and secure.

Can one self-hosted runner serve several repositories?

A runner registers with one repository, organization or enterprise at a time. To share one across repositories, register it at the organization level and control access with runner groups, or run several runner instances on the same machine, each registered separately.

Which operating systems can run a self-hosted runner?

GitHub supports the runner application on common Linux distributions such as Ubuntu 20.04 and later, Debian 10 and later and RHEL 8 and later, on Windows 10, 11 and Windows Server 2016 to 2022, and on macOS 11 and later. It runs on x64 and ARM64, and on ARM32 for Linux.

How long can a job run on a self-hosted runner?

Up to 5 days, compared with 6 hours on GitHub-hosted runners. A job that stays queued for more than 24 hours fails.

Are self-hosted runners safe for public repositories?

GitHub says self-hosted runners should almost never be used for public repositories, because anyone can open a pull request and run code on the machine. Its recommendation is ephemeral, just-in-time runners that run at most one job, plus isolation, egress control and careful handling of secrets.

What does Actions Runner Controller do?

Actions Runner Controller (ARC) is a Kubernetes operator that orchestrates and scales self-hosted runners for GitHub Actions. Runner scale sets grow and shrink with the number of workflows running. You still operate the cluster, the images and the network around it.

Can CRACI runners run in my own network?

Not today. CRACI offers managed runners on European infrastructure, with customer-hosted runners on the roadmap for Enterprise. Jobs that must run inside your network can stay on self-hosted runners while other jobs move to CRACI.