GitHub Actions larger runners: how to set one up, or get 16 vCPU at a flat price

You want more cores because the build is slow or runs out of memory. GitHub's answer is a larger runner, and it bills every minute: 8 cores for 20,000 minutes a month comes to $422, and 16 cores to $822.

Skipbox gives you the same vCPU at a flat price with unlimited minutes: $79 a month for 8 vCPU, $149 for 16. Change one runs-on line; there is no runner to create and no plan upgrade to ask for.

How to set up a larger runner

Three conditions first: your organization is on GitHub Team or Enterprise Cloud, you are an organization owner, and a payment method is on file. Then:

1. In the organization, open Settings → Actions → Runners.
2. Click New runner → New GitHub-hosted runner.
3. Fill in the name (it becomes the label, such as ubuntu-24.04-16core), platform, image, size, maximum concurrency and runner group, then Create runner.
4. Point a job at it: runs-on: ubuntu-24.04-16core.

By default every repository in the organization can use it. A new larger runner can make the first job wait while GitHub starts a VM, because its pool keeps fewer machines ready than ubuntu-latest.

What a larger runner costs you

Larger runners bill per minute, every job rounded up to a whole minute, on public repositories too. On GitHub Team their minutes draw on the plan's included compute first, then bill. At 20,000 minutes a month:

Run the 8-core machine all month and GitHub's bill reaches $932.40; Skipbox's M stays $79. Put your own minutes into the calculator on the home page.

And the minutes grow. Coding agents push more than people do, and each push runs every job. Bigger test suites run longer on bigger machines. Set a budget to cap it, and every job stops the day it is spent.

The other way: self-hosted runners

GitHub bills nothing for self-hosted runner minutes; the charge it announced in December 2025 was shelved the next day. A 16-core machine of your own costs GitHub nothing per minute. Running it yourself means work:

• buying or renting servers sized for the build, and more when jobs queue
• keeping the OS, Docker and the runner application patched
• cleaning credentials, checkouts and containers between jobs
• fixing it when it stops taking jobs

Skipbox is a self-hosted runner with that work done for you.

Skipbox: bigger machines, flat price

Pick the size with one label

Minutes are unlimited, with no usage charges. Skipbox's runners register as self-hosted runners, so they use none of your GitHub minutes and keep running when an Actions budget runs out. Jobs beyond your plan's machines wait their turn.

Faster than more cores alone

A larger runner still starts each job on a blank VM. Skipbox keeps your account's own VM between jobs: Docker images, layers and build cache, package caches and the tool cache are on disk when the next job starts, with at least 7× the cache room GitHub gives a repository.

Nothing to manage

Skipbox updates the image, wipes each job's leftovers, health-checks the machine after every job and rebuilds one that fails. The VMs run Ubuntu 24.04 with Docker, Node.js and Python.

Moving is one line

jobs:
  build:
    runs-on: skipbox-8x16 # was ubuntu-24.04-8core
    steps:
      - uses: actions/checkout@v4
      - run: make -j"$(nproc)"

1. Sign in to Skipbox with GitHub.
2. Install the Skipbox GitHub App and pick the repositories.
3. Change runs-on and push.

skipbox-8x16 runs on plan M or L, skipbox-16x32 on plan L. To move back, change the line back.

Security

• Each account gets its own machine, for public and private repositories.
• The runner's credentials, processes and containers are wiped after every job; from 13 November 2026 the checkout and Cargo's target/ stay, so the next build is incremental.
• Code from people without write access (such as pull requests from forks) runs on a fresh VM that is deleted afterwards.

Try it on your own jobs

The trial is free for 7 days or 3,000 job-minutes, whichever comes first, with no card, and runs runs-on: skipbox jobs at 4 vCPU and 16 GB. Move one job, watch the second run start with its caches in place, then pick the plan whose size your build needs.

Updated November 11, 2026