Comparison · verified August 2026
GitHub Actions runners: hosted, self-hosted and managed
Three ways to execute a job, with genuinely different failure modes. Here is what each one costs, what it asks of you, and when it is the wrong answer — including the cases where it is not us.
The three options
What each one is actually good and bad at
| Kind | Who it suits | What it gets right | What it costs you |
|---|---|---|---|
| GitHub-hosted | Anyone, by default. It is what runs-on: ubuntu-latest means. | Nothing to operate. Clean VM per job, GitHub's images, GitHub's security patches, GitHub's problem at 3am. | Priced per minute on hardware chosen for breadth rather than speed. Caches live a network away from the job, so a restore can cost more than the step it saves. You cannot make it faster; you can only buy a bigger one. |
| Self-hosted | Teams with an infrastructure function and a reason — specific hardware, a private network, a compliance boundary. | The hardware is yours, so single-core clock and disk are whatever you are willing to buy. No per-minute charge at all. Anyone claiming self-hosted is inherently slow is selling something. | You now run a fleet. Autoscaling, image updates, cache eviction, Docker layer reuse, a package proxy, and the ephemerality work that stops one job seeing the last one's secrets. That is not a weekend; it is a service with an on-call rota. |
| Managed | Teams who want the hardware without the fleet. | A runner label change, and someone else owns the autoscaling, the images and the caching. Priced per minute like GitHub, on hardware chosen like self-hosted. | A third party is executing your CI, which is a real trust decision — check the isolation model, not the marketing. And you are betting on a vendor's roadmap for anything they have not built yet. |
The change you make
One label, in the file you already have
Your workflows do not change. Same YAML, same actions, same secrets, same logs in the GitHub UI — you change the runner label and everything else carries on working.
Feature parity
Against GitHub-hosted, row by row
Read the third column first. If something in it is load-bearing for you, stop there — that answers your question faster than either of the other two.
Same as GitHub-hosted runners
- Your existing workflow files
One label changes. Nothing else. - actions/cache
Drop-in. We serve it ourselves, in Europe, where every job runs. - Secrets, environments, OIDC
Handled by GitHub, untouched by us. - Status checks and branch protection
Reported back the same way. - Matrix builds, reusable workflows, composite actions
- Job logs in the GitHub UI
Plus ours, which are searchable. - One clean VM per job
Its own virtual machine, which no other job uses, destroyed after. Never reused.
What we add
- $0.004/min at 2 vCPU
Against GitHub's $0.006 for the same size — and 1.3× to 2.2× faster on it, so the build itself costs about 35% of theirs. - Docker layer cache that persists across runs
Including RUN --mount=type=cache contents. - The same bill as your Terraform runs
Not yet
- macOS and Windows runners
GitHub has both. We are Linux x64 today. - ARM64
Planned. GitHub has it now. - GPU runners
Not on our roadmap. - Larger runners above 16 vCPU
The largest runner on sale today has 16 vCPU. - Queryable log search and monitors
Being built. Blacksmith has both today; GitHub has neither. - SSH into a running job
Planned. - GitHub Enterprise Server
Cloud only.
Questions
The ones worth asking first
What is a GitHub Actions runner?
The machine that executes a job. GitHub sends the job to a runner, the runner checks out your code, runs your steps and reports the result back. runs-on: in your workflow file is how you say which kind you want.
What is the difference between GitHub-hosted and self-hosted runners?
Who owns the machine. GitHub-hosted runners are GitHub's fleet, billed per minute, reimaged between jobs and unconfigurable. Self-hosted runners are yours: any hardware, no per-minute fee, and every operational concern — scaling, patching, isolation between jobs — becomes your responsibility.
Are managed runners a drop-in replacement?
For ours, one line: change runs-on: ubuntu-latest to runs-on: ghwarp-2vcpu-ubuntu-2404. Your workflow files, actions, secrets, environments, OIDC, matrix builds, reusable workflows, status checks and branch protection are untouched, and job logs still appear in the GitHub UI. actions/cache works unmodified.
How much do GitHub Actions runners cost?
GitHub charges $0.0060 per minute for a 2 vCPU Linux runner, per their published runner pricing read on 2026-08-22; public repositories are free. Ours is $0.0040 a minute for the same shape. The Actions cache is included and never metered. The Docker layer cache is running today and is metered at $0.50/GB-month, billed on what you actually use.
Is it safe to run CI on someone else's hardware?
It depends entirely on the isolation model, which is worth asking about specifically rather than taking on trust. Ours gives every job its own virtual machine, which no other job uses and which is destroyed when the job ends — never reused between jobs, including between jobs belonging to the same repository.
Can I run macOS, Windows or ARM64 jobs?
Not with us today. We are Linux x64. GitHub has macOS, Windows and ARM64 now, and every one of the six managed-runner competitors publishes an ARM rate; we have none. ARM64 is committed here. macOS, Windows and GPU runners are not. If any of those are load-bearing for you, this is the wrong product and it is better that you know now.