Kay

Posted on Nov 15 Originally published at latchkey.dev

Are GitHub larger runners worth it, or is a managed runner cheaper?

#devops #githubactions #cloud #cicd

Are github larger runners worth it: yes when a job uses the cores, and no when you are buying them to wait faster, because the rate at 4 vCPU is $0.012 a minute against $0.008 from two managed vendors and $0.005 from ours. The included allowance barely changes that: on GitHub Team, larger runners share the plan's $18 a month of included compute with standard runners, which is 1,500 minutes at 4 vCPU.

Ten thousand minutes a month on a 4 vCPU Linux runner, private repository, at rates read 20 September 2026, with GitHub Team's $18 included compute applied. The dashed band is the Latchkey plan fee, which the compute bars exclude.

A larger runner is GitHub's own answer to "this job needs a bigger machine". An organization owner creates it in settings, gives it a name, and jobs select it with that name in runs-on. It is the same runner image and the same billing relationship you already have, on hardware from 4 to 96 vCPU.

Managed runners are the same idea sold by somebody else. Blacksmith, WarpBuild, Depot, Namespace and Latchkey rent most of the same sizes and hand the job back to GitHub Actions unchanged, adopted with an app install and a label. At a given size they are typically 22% to 33% below GitHub, and one is above it.

Every rate, size and limit below was read from docs.github.com or the named vendor's own page on 20 September 2026, and GitHub's included allowance, which became a dollar amount on 28 October 2026, was read again on 12 November 2026. Where a vendor does not publish a figure, the cell says so rather than carrying a guess.

Comparison

	GitHub larger runners	Blacksmith and WarpBuild	Managed (Latchkey)
Price per minute, 4 vCPU Linux x64	$0.012	$0.008 on both	$0.005
Price per minute, 8 vCPU Linux x64	$0.022	$0.016 on both	$0.01
Free tier	$18 a month of included compute on Team and $300 on Enterprise Cloud, shared with standard runners and deducted at the larger runner's rate, so $18 is 1,500 minutes at 4 vCPU. Larger runners are not free for public repositories	Blacksmith gives 3,000 free minutes a month per organization, denominated in x64 2-vCPU minutes, so a 4 vCPU runner drains them twice as fast. WarpBuild publishes no allowance	2,000 included minutes a month on Developer, 4,000 on Launch, 6,000 on Scale
Billing granularity	Every job rounded up to the nearest whole minute	Per minute on both; neither publishes a sub-minute rule	Per minute, rounded up per job
Sizes and OS	2 to 96 vCPU on x64 and 2 to 64 on arm64, Ubuntu and Windows, plus a 12-core Intel and a 5-core M2 Pro macOS runner and a 4-core GPU runner with a Tesla T4	Both stop at 32 vCPU. Blacksmith adds arm64, Windows Server 2025 and macOS M4; WarpBuild adds arm64, Windows from 4 vCPU up and macOS M4 Pro	2 to 16 vCPU, Ubuntu 24.04 on x86_64 only
Cache: type, limit, persistence	`actions/cache`, 10 GB per repository, entries evicted after 7 days without access	Blacksmith redirects the same actions to a colocated cache with 25 GB free per repo per week; WarpBuild needs its own `WarpBuilds/cache` action and bills $0.20 per GB-month	`latchkey-dev/cache-action@v1` in place of `actions/cache`, as a restore step and a save step taking the same `path` and `key` (no `restore-keys`); 14-day retention, isolated per organization, no published size cap
Docker build acceleration	None built in	Blacksmith keeps the layer cache on a sticky disk at $0.50 per GB-month; WarpBuild sells separate Docker builders from $0.06 a minute	`latchkey-dev/docker-cache-action@v1`, one step wrapping `docker buildx build` with a registry-backed layer cache
Concurrency limits	1,000 jobs per larger runner on both Team and Enterprise, with macOS still capped at 5 (50 on Enterprise) and GPU jobs at 100	Both state no concurrency limit on Linux	20 busy runners per workspace by default, raisable on request
Where jobs run	GitHub's own fleet, optionally with static IP ranges drawn from up to 10 runner pools	Their own hardware. WarpBuild will also run the same fleet inside your cloud account at $0.002 a minute	AWS us-east-1
Self-healing or retries	None	None on either	Transient failures diagnosed and retried inside the run
Setup change required	An organization owner creates the runner in settings, grants repository access, then each job names it	A GitHub App or bot install, then a `runs-on` label	A GitHub App install, then a `runs-on` label

What you are actually buying

A larger runner is not a different product from ubuntu-latest. It is the same runner image on a bigger machine, with 4 GB of memory per core and storage from 75 GB at 2 vCPU to 2,040 GB at the top. Custom images, Azure private networking and static IP ranges are larger-runner features standard runners do not have.

What you are not billed for is idleness: GitHub charges a larger runner only while a workflow is executing on it, and says there is no cost for creating one that nothing uses. That is the sharpest contrast with self-hosting the same machine, where the meter runs on uptime.

Three lines on GitHub's billing pages decide most of the argument, and all three surprise people on the first invoice. Larger runners draw on the same included compute as standard runners, a dollar amount ($18 a month on Team, $300 on Enterprise Cloud) deducted at each runner's rate, so a 4 vCPU runner at $0.012 spends Team's $18 in 1,500 minutes. Larger runners are not free on public repositories, where standard runners are free and unlimited. And the same reference says they are only available to organizations and enterprises on GitHub Team or GitHub Enterprise Cloud, so a personal account cannot buy one at any price.

The ladder, and the rate at every rung

GitHub's x64 rates against the same sizes at four managed vendors. The specification column is GitHub's; vendors pair the same core counts with their own memory and disk, which Depot and Namespace both publish.

Size	GitHub's RAM and disk	GitHub larger runner	Blacksmith and WarpBuild	Depot	Latchkey
4 vCPU	16 GB, 150 GB	$0.012	$0.008	$0.012	$0.005
8 vCPU	32 GB, 300 GB	$0.022	$0.016	$0.024	$0.01
16 vCPU	64 GB, 600 GB	$0.042	$0.032	$0.048	$0.02
32 vCPU	128 GB, 1,200 GB	$0.082	$0.064	$0.096	Not offered
64 vCPU	256 GB, 2,040 GB	$0.162	Not offered	$0.192	Not offered
96 vCPU	384 GB, 2,040 GB	$0.252	Not offered	Not offered	Not offered

Read across the rows and the shape of the market appears. Blacksmith and WarpBuild are 33% below GitHub at 4 vCPU, 27% at 8, 24% at 16 and 22% at 32: the discount narrows as you climb, because their rates double at every step while GitHub's do not quite. Depot is level at 4 vCPU and above GitHub from 8 up, $0.024 against $0.022 and $0.096 against $0.082, the one managed vendor that is the expensive option here. Latchkey is 58% below at 4 vCPU and 52% below at 16, then has nothing to sell.

GitHub owns the top of the ladder outright: above 32 vCPU only Depot competes, and above 64 nobody does. Its arm64 ladder is the quiet bargain in its own rate card at $0.008 for 4 cores, the same rate Blacksmith and WarpBuild charge for x64.

The rate is only half of the arithmetic, and the other half is the one nobody prices in: does the job get faster? GitHub's ladder is slightly sublinear above 4 cores, so doubling from 4 to 8 costs 1.83 times as much and pays for itself if the job finishes in 55% of the time. On Blacksmith, WarpBuild and Latchkey, where the rate doubles exactly, the same move has to halve the wall clock to break even. A suite that shards cleanly will do that. A single-threaded build will not, and you have bought the same 20 minutes at twice the price.

Speed

Not benchmarked yet. Every vendor here publishes a multiple, GitHub publishes none, and none was measured on your workflow; the runner benchmark report will replace this section with one workload run on all of them.

The documentation does support one warning, about waiting rather than running. GitHub says larger-runner pools are smaller than the standard fleet, so a first job may wait while a VM is created, after which machines stay ready for about five minutes and a subset stays warm for 24 hours with continued use. A runner used twice a day can feel slower to start than the ubuntu-latest it replaced.

Cost: ten thousand minutes a month on a 4 vCPU Linux runner

One size up from standard is the common purchase, so that is the month to price: 10,000 minutes on a 4 vCPU Linux x64 runner, private repository, each allowance applied where the vendor's own page says it applies.

	Compute	What the allowance does	Monthly total
GitHub larger runner	10,000 x $0.012 = $120	On Team, the $18 of included compute comes off, if standard runners have not already spent it	$102
Blacksmith	8,500 x $0.008 = $68	3,000 free minutes at the 2-vCPU denomination, which is 1,500 minutes on this runner	$68
WarpBuild	10,000 x $0.008 = $80	No allowance published	$80
Depot on the $20 Developer plan	18,000 billed minutes x $0.006 = $108	The month bills 20,000 minutes at the 2x multiplier for this size, of which 2,000 are included	$128 with the plan
Namespace on the $100 Team plan	80,000 unit minutes, inside the plan	The plan fee is the prepaid minutes: 100,000 of them	$100
Latchkey	10,000 x $0.005 = $50	The 2,000 to 6,000 included minutes are not netted off this total	$50 plus $5 to $49 a month for the plan

Two honest readings. Latchkey has the lowest compute line at $50, but on the $19 Launch plan the bill is $69 against Blacksmith's $68, and Blacksmith is ahead at the $49 tier. And Namespace's $100 is a plan rather than a rate: 100,000 unit minutes covers 12,500 minutes of this 4 vCPU shape, so the $100 here buys 10,000 minutes that WarpBuild sells for $80, and it pays for itself only if the same plan also covers your Docker builds, cache volumes and smaller shapes.

On a Team plan GitHub is $34 a month above Blacksmith and $52 above Latchkey's compute line, which is the answer on cost alone. Enterprise Cloud is the exception: its $300 allowance would cover this whole $120 month, if nothing else drew on it first. What the premium buys is the absence of a third party: no app, no vendor review, no second status page, one invoice. Whether that is worth $34 a month is a procurement question.

Reliability: different failure modes, not fewer

GitHub publishes a troubleshooting list for larger runners worth reading before you buy: jobs are delayed by the maximum concurrency you configured, by repository permissions that are off by default for enterprise runners, by a missing credit card, by a spending limit left at zero, and by fair use throttling. None of those applies to a standard runner, which is why "we only changed the label" sometimes queues.

Managed vendors swap that for vendor risk, which is not theoretical: BuildJet stopped running GitHub Actions jobs on 31 March 2026.

Neither column does anything for a job that failed for a reason unrelated to your code. A registry timeout on a 32 vCPU runner is an expensive registry timeout, billed when it fails and again on the re-run. Count the runs in your history that passed on a second attempt with no code change before deciding cores were missing.

When each one is worth it

A larger runner when the job uses the cores, when you need more than 32 vCPU or an arm64 machine at 64, when a job needs the Tesla T4 GPU runner at $0.052 a minute, or when static IPs, private networking or a custom image is the real requirement.
A larger runner when adding a vendor means redoing a compliance review for a handful of jobs. A rate difference on a small workload rarely survives a security questionnaire.
A managed runner when the same size is on sale 22% to 33% cheaper and adoption is one line per job. Check OS coverage first: Latchkey is Linux x86_64 only, so Windows and macOS jobs stay where they are.
Neither, when nobody has profiled the job. Caching, sharding and skipping unchanged work are free; cores are $0.012 a minute and bill from the first job of the month.

Switching: the exact diff

A larger runner is referenced by the name your organization owner gave it, so the label is whatever your settings page says; a vendor label is published and the same for everyone. Both are one line per job, and both can sit in one workflow.

jobs:
   build:
-    runs-on: ubuntu-latest
+    runs-on: ubuntu-4-core          # the name your org gave the larger runner

   test:
-    runs-on: ubuntu-latest
+    runs-on: blacksmith-4vcpu-ubuntu-2404   # same size, $0.008 against $0.012

   lint:
     runs-on: ubuntu-latest          # left alone: 2 vCPU was never the problem

The verdict

The case for buying one is narrow, and the list above is all of it. Everything else argues the other way: the rate is the highest of any option at every size both sides sell, Team's $18 of included compute covers only 1,500 minutes at 4 vCPU, they are billed on public repositories, and the billing reference puts them out of reach below the Team plan. If one job is slow, profile it first, because a bigger machine is the most expensive way to not fix a cache miss. If a workload needs 8 or 16 cores every day, the same machine is on sale at 22% to 33% less from vendors you adopt with a label, and at 55% less at 8 vCPU and 52% less at 16 vCPU on Latchkey ($0.010 and $0.020 a minute against $0.022 and $0.042), and the way back is that same line.

FAQ

Do larger runners use my included GitHub Actions minutes?

Yes, on GitHub Team and Enterprise Cloud. Since 28 October 2026 the included allowance is a dollar amount, $18 a month on Team and $300 on Enterprise Cloud, and larger runners draw on it at their own per-minute rate alongside standard runners, with no priority between them. At $0.012 a minute, $18 covers 1,500 minutes on a 4 vCPU runner, so on Team a busy month still bills most of its larger-runner minutes.

Are larger runners free on public repositories?

No. Standard GitHub-hosted runners are free and unlimited on public repositories, and the billing reference says in as many words that larger runners are not free for public repositories. A public repository that moves one job to a larger runner starts paying full rate.

Why are my larger runner jobs queuing?

GitHub lists five causes: the maximum concurrency configured on the runner, repository permissions that are off by default for enterprise-level runners, no valid credit card on file, a spending limit of zero, and fair use throttling. Warm pools are the sixth: larger-runner pools are smaller than the standard fleet, so an infrequently used runner has to create a VM first.

Is a managed runner cheaper than a larger runner at the same size?

At 4 to 32 vCPU, yes for most vendors: Blacksmith and WarpBuild are 22% to 33% below GitHub at every size all three sell, and Latchkey is 52% to 58% below at 4 to 16 vCPU. Depot is the exception, level at 4 vCPU and above GitHub from 8 up.

DEV Community