The 2026 CI Runner Market in One Table: When a $50 Hetzner Box Beats Every Meter

2026 repriced every CI-runner option at once. GitHub cut hosted-runner rates by up to 39% in January, then announced — and, after a community revolt, shelved — a per-minute platform charge on self-hosted runners. An agent skill called ci-cost started pricing one repo's real Actions usage across eight vendors in August. And Avrea's July benchmarks put hard numbers to the speed story: the fastest managed runner scores 4,406 PassMark single-thread on bare-metal EPYC, while spot-based runners cost a tenth as much per minute.

Read together, the new data settles the build-vs-buy question into something unusually crisp: below roughly 10,000 build-minutes a month, a metered managed runner wins and it is not close. Above roughly 15,000 minutes, a single owned Hetzner box beats every meter on price — with one gaping exception, GPU builds, where exactly one vendor has a credible answer. This post puts the whole market in one table, works the sheet at three workload sizes, and names the crossover points so you can place your own builds on the curve.

The 2026 CI-runner market in one table​

Prices are per-minute for a small-Linux-runner class unless noted, from August 2026 or earlier published sources. Speed and startup figures are Avrea's July 1, 2026 medians where available; a dash means Avrea did not publish that cell, not that the vendor is slow.

Three things to read off this table before the worked math. First, the managed metered field has converged: Blacksmith and WarpBuild both land at $0.004/min and ci-cost's sample workload prices them identically at $23.20/month against GitHub Team's $34.20 — so within the managed tier you now shop on speed, queue time, and caching, not price. Second, the two cheapest rows (Ubicloud's meter, RunsOn's spot) are both "your cloud account does the compute" models with different wrappers — the discount comes from cutting out the managed margin, not from slower silicon. Third, the owned row is the only flat price on the board, which is exactly why the answer flips with volume.

What 2026 actually changed (and what it didn't)​

The cut is real. On January 1, 2026, GitHub reduced hosted-runner list prices by roughly 40% across sizes, with the new platform charge already folded into the reduced meter price. For teams that stayed on GitHub-hosted runners, CI got materially cheaper with no action required — the baseline every alternative has to beat moved down.

The $0.002 charge is announced, not live — and the distinction matters. GitHub's December 2025 announcement said self-hosted runners in private repos would pay a $0.002/minute cloud platform charge starting March 1, 2026, with those minutes also counting against plan quotas. After large-scale community backlash, GitHub postponed the charge indefinitely. Self-hosted minutes remain $0 on the GitHub side today, and public repos remain free either way.

Why budget attention on a charge that never landed? Because the meter exists on paper and the logic behind it — GitHub monetizing orchestration separately from compute — did not get refuted, only deferred. A build-vs-buy sheet that assumes self-hosted stays $0 forever is making a bet; this post's worked math shows the owned case both ways so you can see how much headroom you have if the meter ever returns. At $0.002/min, a 20,000-minute self-hosted workload would owe $40/month before buying a single server — enough to erase the owned advantage at the middle workload below, but not at the heavy one.

Rounding and free tiers still shape small bills. GitHub rounds every job up to a whole minute, which silently taxes repos with many short jobs: one hundred 20-second lint jobs bill as 100 minutes, not 34. The 2,000 free minutes a month on the Free plan are unchanged, which is why the light workload below barely registers as a bill on any managed option — and why the fixed-cost rows look absurd there.

The worked sheet: three workloads, four bills​

Take a typical team running standard-class Linux builds and price the same minutes four ways: GitHub-hosted post-cut ($0.006/min), a managed $0.004/min vendor (Blacksmith/WarpBuild), RunsOn spot ($0.0012/min compute plus ~$29/month amortized commercial license), and one owned Hetzner AX42 (€46/month flat, roughly $50, setup fee amortized away after month one). License and rounding included — no hidden lines.

The crossover points fall out of simple division, and they are the numbers to remember:

• Owned beats GitHub-hosted above ~8,300 minutes/month ($50 ÷ $0.006). That is roughly one developer's steady push-and-PR cadence on a medium repo — lower than most teams guess.
• Owned beats managed $0.004/min vendors above ~12,500 minutes/month ($50 ÷ $0.004). A team of five pushing a few times a day with a 10-minute suite clears this without trying.
• RunsOn beats managed vendors above ~10,400 minutes/month, where its spot savings finally outweigh its flat license ($29 ÷ $0.0028/min gap). Below that line the license makes it the most expensive metered option — the table's least intuitive row, and the one most "RunsOn is cheapest" summaries skip.

Two sensitivity notes before you anchor on these. First, GitHub's per-job rounding pushes its effective rate up for short-job repos, which moves both GitHub crossovers down — possibly under 6,000 true minutes for a lint-heavy workflow. Second, if the shelved $0.002 self-hosted charge ever activates, add $0.002 × minutes to both the RunsOn and owned columns: at 20,000 minutes that is +$40, flipping the middle row back to managed — but at 40,000 minutes owned ($130 all-in) still beats every meter. The heavy end of the curve is robust to the charge returning; the middle is not.

Where owned builders win — and where they quietly lose​

Winning on the monthly bill is only half the sheet. The owned row's real advantages are operational: a persistent box holds a warm Docker layer cache and a warm registry mirror, so builds skip the cold-pull tax every ephemeral runner pays; there is no queue behind anyone else's jobs; and Hetzner Cloud's hourly VMs (a 2-core box at about €0.006/hour) give you a burst tier on the same account for spiky parallelism without a second vendor. Tooling like TestFlows' Hetzner autoscaler, which claims up to 75x savings over GitHub-hosted by recycling cloud VMs per job, exists precisely to make the owned row elastic.

The honest debits: one AX42 runs about four concurrent 2-vCPU jobs, so a team whose builds arrive in bursts will queue unless it adds boxes or a cloud-burst tier — and every added box moves the crossover up. Spot-based RunsOn has the mirror risk: ~23-second starts and spot-interruption exposure on the cheapest instances. And self-hosted runners of any kind carry the security footnote GitHub's docs have always carried: persistent, network-reachable runners need hardening, per-run cleanup, and no secrets on fork-PR jobs — an ops cost the managed $0.004/min quietly includes. Price the hour a month you will spend patching and reaping runners, or the sheet is lying to you.

The shape of the right answer is therefore a stack, not a single vendor: owned persistent builders for the steady base load where warm caches compound, a metered burst tier (managed vendor or hourly cloud VMs) for parallel spikes, and — the row most teams forget until they need it — a GPU answer.

The GPU gap no CPU fleet can close​

Here the one table turns into a one-row table. An April 2026 survey of the managed field found that Blacksmith, Namespace, WarpBuild, and Depot offered no GPU runners at all — and a CPU-only owned Hetzner fleet obviously cannot conjure a CUDA device either. The only credible metered GPU-CI path it named is RunsOn: T4 runners (g4dn.xlarge, on your own AWS account) at $0.009/min, launched from its open-source MIT-licensed CloudFormation with no per-minute markup on the compute.

$0.009/min sounds steep next to $0.0012 CPU spot until you price the alternative, which is buying and babysitting a GPU box for a workload that runs twenty minutes a day. For the team whose GPU need is "run the CUDA test shard and build the inference image," a metered T4 tier bolted onto an otherwise owned fleet is the correct shape: flat-rate CPUs for the base load, metered GPUs for the exception. If your roadmap says GPU builds arrive next year rather than next quarter, this row is also the strongest argument for keeping one foot in a metered ecosystem even after the owned crossover says to leave — re-entry is instant, while procuring GPU hardware is not.

The decision sheet​

• Under ~5,000 minutes/month: stay metered. A $0.004/min managed vendor (or GitHub-hosted inside free-tier range) costs less than any flat license or box, with zero ops. Do not buy hardware to optimize a $20 bill.
• 5,000–12,000 minutes/month: the awkward middle. Managed metered still wins on pure price, but GitHub rounding may already be pushing you toward the exit — audit billed vs. true minutes before deciding. RunsOn's license makes it the wrong pick here despite its cheap compute.
• Above ~12,500 minutes/month: buy the box. One owned AX42-class server beats every meter, and the margin grows with every additional minute. Add an hourly cloud-burst tier before you add a second box.
• Any GPU-CI need, at any volume: keep RunsOn (or your cloud's own GPU spot) as the metered exception tier. Nothing else in the table has a row for it.
• If the $0.002 charge returns: re-run the middle row. The heavy end survives it; the 10,000–20,000-minute band is where the decision flips.

2026's real lesson is not that one runner type won — it is that the market finally priced itself into legibility. A year ago the choice was vibes: GitHub's $0.008 against hand-waved "self-hosted is free." Now there is a published meter for every tier, a benchmark table for the speed claims, and a skill that will price your own repo's usage across eight vendors in minutes. Run your minutes through the sheet above; the crossovers do the rest.

Running a git-push PaaS means running a build pool, and the same math applies to the fleet behind it: owned builders for the steady base, metered burst for the spikes. Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.