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

By Kaveh Alemi·Latchkey

Are github larger runners worth it: yes when a job genuinely 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 detail that decides most first bills is not the rate at all: included minutes cannot be spent on larger runners, so they bill from the first job of the month.

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. Where a vendor does not publish a figure, the cell says so rather than carrying a guess.

Larger runners against managed runners, at the same sizes (read 20 September 2026)

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 the billing reference decide most of the argument, and all three surprise people on the first invoice. Included minutes cannot be used for larger runners. 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.

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.

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.

GitHub is the most expensive row at every volume, which is the answer on cost alone. 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 $52 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, included minutes cannot touch them, 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 genuinely 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, at 58% less on our own 4 vCPU runner, and the way back is that same line.

Frequently asked questions

Related guides

References

• GitHub larger runners reference: machine sizes, images and troubleshooting
• GitHub Actions runner pricing, including the larger-runner rate card
• GitHub Actions limits, including job concurrency by plan and runner type
• Blacksmith instance types, free minutes and concurrency
• Latchkey runner sizes, rates and plans
• GitHub Actions documentation