GitHub Actions Runner Alternatives: Every Published Price (2026)

Q: Is it hard to switch GitHub Actions runner providers?

No. Every drop-in provider here is selected by the runs-on label, so adopting one is a one-line change and reverting is the same. Because runner selection is per job, you can trial a single job without migrating the pipeline.

Q: How do I know whether I need faster runners or more reliable ones?

Measure two numbers. Add /usr/bin/time -v to your slowest job to see whether it is CPU-bound or waiting on I/O, and pull the last month of workflow runs to compute what share are retries of a failed run. The first tells you which architecture to buy; the second tells you whether rate is even the right thing to optimise.

By Kaveh Alemi·Latchkey

Eleven providers, their real published rates, and the two cases where the right answer is to stay on GitHub-hosted. Every figure verified against vendor pricing pages on 2026-08-20.

Most roundups of GitHub Actions runner alternatives describe vendors qualitatively and send you to check prices yourself. This one publishes the numbers, dated, with the source for each. That matters more than usual right now, because GitHub cut its standard Linux 2-core x64 rate from $0.008 to $0.006 per minute, and several vendors still advertise savings calibrated against the old price. A claim of "half the price of GitHub Actions" is a 33% saving against current list.

Two things to settle before the table. First, if your repository is public, standard GitHub-hosted runners are free and unlimited, at 4 vCPU and 16 GB. No paid provider can beat free, so unless wall-clock speed is your specific pain, stay. Second, if your private-repo usage fits inside your included minutes (2,000 on Free, 3,000 on Pro and Team, 50,000 on Enterprise Cloud), moving to a metered provider converts a zero bill into a real one.

Everything below assumes you are past both of those: a private repository, over your included minutes, paying real money for CI.

Every provider, Linux 2 vCPU, verified 2026-08-20

Provider	Linux ~2 vCPU rate	Recurring free tier	Distinctive property
GitHub-hosted	$0.006/min	2,000-50,000 min by plan; free and unlimited on public repos	The reference implementation
Latchkey	$0.0025/min (8 GB)	2,000-6,000 min by plan	Self-healing: repairs and retries transient failures on the runner
Namespace	~$0.002/min prepaid (4 GB)	Developer plan $0, pay-as-you-go	Unit-minute billing: 1 vCPU + 2 GB per unit
Blacksmith	$0.004/min; ARM $0.0025	3,000 min/month	Bare-metal gaming CPUs, sub-3-second Firecracker boot
Depot	$0.004/min	Bundled into $20/mo Developer plan	RAM disk by default, unlimited cache at 1,000 MiB/s, per-second billing
BuildJet	$0.004/min	One-time $5 credit only	20 GB per-repo cache, double the GitHub limit
WarpBuild	$0.004/min; ARM $0.003	Not published	BYOC mode at $0.002/min in your own cloud
Semaphore	$0.0075/min; ARM $0.003	$15 credits/month	Full CI platform, not a drop-in runner
Buildkite	$0.004/vCPU-min	2,000 Linux vCPU-min/month	Hybrid model; $30 per active user plus agent fees
RunsOn	No per-minute fee	Free for OSS, nonprofit, education	Flat annual licence from EUR 300/yr; runs in your AWS account
Ubicloud	Not published per size	$2/month credit	Claims 7x cheaper than GitHub Actions

The three pricing models, and why comparing them is hard

The providers above are not all selling the same shape of thing, which is why a naive per-minute sort misleads.

Flat per-minute, per size. GitHub-hosted, Blacksmith, Depot, BuildJet, WarpBuild, Latchkey. Easiest to forecast: pick a size, multiply by minutes.
Unit-based. Namespace bills vCPU x minutes x platform multiplier, with RAM fixed at 2 GB per vCPU. Very cheap at small shapes, but a memory-hungry job forces you up the vCPU ladder to buy RAM you would rather not pay cores for.
Licence or seat based. RunsOn charges a flat annual licence and no per-minute fee, because the compute is your own AWS bill. Buildkite charges per active user plus per agent on top of per-vCPU-minute. Both can be dramatically cheaper or more expensive than the table suggests depending on volume.

What each one is actually optimised for

Price converges. Architecture does not, and it is the better basis for a decision.

If your bottleneck is	The provider built for it	Mechanism
Single-threaded compile or bundle	Blacksmith	Bare-metal gaming CPUs, single-thread PassMark 4484
Docker layer builds and large caches	Depot	RAM disk by default, unlimited cache at 1,000 MiB/s
Many short jobs in a wide matrix	Depot	Per-second billing removes per-minute rounding
Raw Linux compute cost at equal vCPU	Namespace	Unit pricing from $0.001/vCPU-min prepaid
Very high volume with in-house AWS	RunsOn	Flat annual licence, compute billed by AWS to you
Data residency or private networking	RunsOn or WarpBuild BYOC	Runners execute inside your own cloud account
Jobs that fail intermittently and get re-run	Latchkey	Detects, repairs, and retries transient failures on the runner

The cost nobody in this table prices

Every provider above competes on making a successful job cheaper or faster. Only one of them changes what happens when a job fails for a reason unrelated to your code, which is where a surprising share of CI spend actually goes.

A transient failure bills the failed minutes, then bills the re-run minutes. You buy the same work twice at whatever rate you negotiated.
The larger cost is wall-clock: the gap between a job failing at 02:00 and an engineer seeing it at 09:00 is not a runner-minute problem and no per-minute discount touches it.
Flake rate is independent of runner speed. A 2x faster runner fails exactly as often, just sooner.

Switching is one line, in both directions

Every drop-in provider here is selected by a runs-on label. That is the strongest practical argument for testing rather than modelling: the cost of a wrong choice is a revert commit, and runner selection is per job, so you can trial one job without touching the pipeline.

workflow.yml

jobs:
  build:
    runs-on: ubuntu-latest              # GitHub-hosted
    # runs-on: blacksmith-4vcpu-ubuntu-2404
    # runs-on: depot-ubuntu-24.04
    # runs-on: buildjet-4vcpu-ubuntu-2204
    # runs-on: namespace-profile-default
    # runs-on: latchkey-small

How to choose without guessing

Confirm you are actually paying. Public repo, or inside your included minutes, means stay on GitHub-hosted.
Measure where the minutes go. Add /usr/bin/time -v to your slowest job and read CPU percentage against wall clock: near 100% is CPU-bound, well under is I/O-bound or waiting.
Count your re-runs. Pull the last month of workflow runs and compute what share are retries of a failed run. This number decides whether rate or reliability is your problem.
Shortlist on mechanism, not price, using the table above. Prices are within 2x of each other; architectures are not.
Trial one job for two weeks on real traffic. Model nothing you can measure.

How to evaluate a managed runner honestly

Runner vendors compete on a headline per-minute rate, and the rate is rarely what decides the bill. Measure the whole job, on your own pipeline, before committing.

Compare at equal machine shape. A cheaper per-minute rate on fewer vCPUs or less RAM is not cheaper per unit of work.
Check billing granularity. Per-minute rounding costs real money on a wide matrix of short jobs; per-second does not.
Include queue and boot time. A runner that is cheaper per minute but slower to start can cost more per merge.
Count your re-runs. If a meaningful share of your runs are retries of a failed job, you are paying for the same work twice at whatever rate you negotiated, and no rate card prices that.
Verify the free tier is recurring. A one-time credit is not a free tier.

The short answer

Public repository, or inside your included minutes: stay on GitHub-hosted. Free and unlimited is unbeatable, and public repos get the larger 4 vCPU / 16 GB machine.

CPU-bound builds on a private repo: Blacksmith, whose bare-metal high-clock architecture targets exactly the single-threaded critical path most pipelines have, with ARM at $0.0025/min as the strongest published rate for that workload.

Docker-heavy or cache-heavy builds: Depot, for the RAM disk, uncapped cache at 1,000 MiB/s, and per-second billing that stops a wide matrix paying for rounding.

Cheapest raw Linux compute at equal vCPU: Namespace prepaid, provided the fixed 2 GB per vCPU suits your jobs.

Very high volume with AWS in-house: RunsOn, where a flat annual licence plus your own EC2 bill beats every metered rate at scale.

Pipelines where re-runs are a real share of spend: this is the axis the rest of the table does not compete on, and the one worth measuring before you optimise the rate.

Switching costs you one line

Latchkey runners are a drop-in replacement: change runs-on: and the rest of the workflow is untouched. Self-healing is on by default, so transient failures are fixed and retried instead of failing the build.

.github/workflows/ci.yml

# before
    runs-on: ubuntu-latest

# after
    runs-on: latchkey-medium

Start free - 30-day trial, no credit card required, or estimate your savings first.

Frequently asked questions

What is the cheapest GitHub Actions runner alternative?

On flat published rates for a 2 vCPU / 8 GB Linux shape, Latchkey at $0.0025/min is the lowest on this page. Namespace can go lower still at roughly $0.002/min prepaid, but that buys 2 vCPU with 4 GB under its unit model rather than 8 GB. At very high volume RunsOn can beat both, because it charges a flat annual licence and the compute lands on your own AWS bill.

Are GitHub Actions runners free for public repositories?

Yes. GitHub documents that standard GitHub-hosted runners are free and unlimited on public repositories, and public repos get 4 vCPU and 16 GB rather than the 2 vCPU and 8 GB private repositories receive. The exception is larger runners, which GitHub bills even on public repos.

Is it hard to switch GitHub Actions runner providers?

No. Every drop-in provider here is selected by the runs-on label, so adopting one is a one-line change and reverting is the same. Because runner selection is per job, you can trial a single job without migrating the pipeline.

Why do vendors claim half the price of GitHub Actions?

Because that was true against GitHub older $0.008/min list price for Linux 2-core. GitHub now lists $0.006/min, so a $0.004 rate is a 33% saving, not 50%. Several vendor sites have not updated the claim, so recompute against current list before building a business case on any headline figure.

What is the difference between managed runners and self-hosted runners?

Self-hosted means you provision, patch, secure, and scale the machines yourself, and pay your cloud provider directly. Managed runners are operated by a vendor and billed per minute, keeping the ephemeral clean-VM-per-job model. RunsOn and WarpBuild BYOC sit between the two: the vendor operates the control plane while the compute runs in your own cloud account.

Do any of these providers fix failing jobs automatically?

Only Latchkey, of the providers listed. The rest compete on the speed and price of a job that runs to completion. A transient failure on the others fails the job, bills the failed minutes and the re-run, and waits for a human to press re-run.

Can I use more than one provider at once?

Yes, and for a large monorepo it is often correct. Runner selection is per job, so compile-heavy jobs can target one provider and Docker-heavy jobs another within the same workflow file. The cost is multiple vendor relationships, bills, and status pages to watch.

How do I know whether I need faster runners or more reliable ones?

Measure two numbers. Add /usr/bin/time -v to your slowest job to see whether it is CPU-bound or waiting on I/O, and pull the last month of workflow runs to compute what share are retries of a failed run. The first tells you which architecture to buy; the second tells you whether rate is even the right thing to optimise.

References

Every provider on this page bills your flaky job twice

You have the rate cards now, and they land within about 2x of each other. Here is the line item none of them show: the run that failed on a registry timeout, a missing browser binary, or a transient resolution error. That run bills. The re-run bills. And between the two, the merge waits for a human to notice - which at 2am is not a minutes problem at all. Latchkey runs the same workflows at $0.0025/min for 2 vCPU with 8 GB, the lowest flat published rate for that shape on this page, and detects, repairs, and retries those failures on the runner before anyone is paged. Pull your last month of runs, count what share are retries, and price that number against the rate you were about to optimise.

Start free Estimate your savings

30-day free trial · No credit card required · Set up in minutes