Best CI runner for GitHub Actions in 2026: hosted and self-hosted alternatives

Most GitHub Actions workflows start on ubuntu-latest and stay there until a job runs out of memory, the bill climbs or the queue grows. On a private repository that runner has 2 CPUs and 8 GB of memory, and GitHub rounds every job up to the whole minute. Five ways to run the same jobs are compared here: the change each one needs in the workflow, the sizes it offers, how it bills, how you control spend and what you have to maintain. Our own product, Promigence, comes first; every fact about the others comes from that vendor's own pages, listed under Sources.

Key takeaways#

• Workflow change: every hosted option here moves a job by changing its runs-on label. Promigence's hosted runners also need the repository added under Runners in the console, and Blacksmith and Depot need their GitHub App installed on an organization.
• Billing unit: Promigence bills each job for the seconds it runs. GitHub rounds each job up to the whole minute, Blacksmith prices by the minute, and Depot tracks runner time by the second with no one-minute minimum per run.
• Spend control: with the Promigence runner command, --cap sets the most one job may cost. GitHub's budgets, Blacksmith's spending alert and Depot's usage caps cover an account's spend or minutes over a period.
• Sizes and systems: GitHub runs Linux, Windows or macOS jobs, with Linux and Windows sizes up to 96 vCPU and a GPU size. Blacksmith runs Ubuntu on x64 and Arm up to 32 vCPU, Windows in public beta and macOS on Apple M4. Depot goes up to 64 vCPU on Intel or Arm and also runs Windows and macOS, with GPUs on its Business plan.
• Public repositories: GitHub's standard runners are free and unlimited there.
• Upkeep: self-hosted runners give the most control and leave every update with you, and on GitHub Enterprise Server they are the only runners GitHub supports.

The best CI runners for GitHub Actions in 2026#

1. Promigence#

Here, every GitHub Actions or GitLab CI job gets its own sandbox. One line of the workflow changes, runs-on: promigence, and the steps and caches stay where they are, as do the repository secrets. The runners are hosted by Promigence AI once the repository is added in the console, or you start your own with one command on a machine of yours.

Key features#

• Hosted runners: open Runners in the console, choose Add a repository and pick it from a GitHub account you connected. Its jobs then run on runners we host, each in a fresh sandbox, with nothing to keep running on your side. Up to 10 of the repository's jobs run at once unless you change it there.
• Sizes by label: promigence-small (2 vCPU, 4 GiB), promigence-medium (4 vCPU, 16 GiB) and promigence-large (8 vCPU, 32 GiB). A job that says only promigence gets medium on hosted runners, or the size you set for the repository in the console.
• Your own runners: promigence runners github --repo OWNER/REPO takes queued jobs with a matching label until you press Ctrl-C. --org ORG covers every repository in an organization, --runner-group NAME places the runners in a group, and --github-api URL points the command at GitHub Enterprise Server.
• Per second, with limits per job: every job is billed for the seconds it runs. With the command, --cap sets the most one job may cost, --timeout the longest it may run and --max how many sandboxes run at once.
• Queue time is your choice: runners start on demand when a job is queued, and --warm N keeps N runners waiting so a job starts the moment it is queued. Waiting runners are billed while idle.
• GitLab CI from the same tool: a project runner tagged promigence on hosted runners, or promigence runners gitlab with the docker executor (the default) or shell. A self-managed GitLab takes --url.

Where it fits#

It suits teams whose jobs have outgrown the default runner or whose bill comes from many short jobs. A job that needs more memory names a bigger size in its label, and per-second billing means a short job pays for its seconds instead of a rounded-up minute. Moving one workflow is a one-line change you can undo, since the steps and the cache actions stay as they were.

Platform teams that want a ceiling on CI spend get one per job. With the runner command, every job has a cap, by default what its full timeout costs at its size, and --max holds how many sandboxes run at once, so a large matrix runs inside limits you set. Capacity follows the plan: 20 sandboxes at once on Free, up to 100 on Pro and up to 500 or 1,000 on Max.

It also fits teams that run more than one CI system or already use Promigence for agents. The same CLI takes GitHub Actions jobs, GitLab CI jobs and jobs from GitHub Enterprise Server, and teams running coding agents or evals on Promigence keep CI on the same account and the same bill. The runner image carries git and Python plus a compiler toolchain, so a job adds its language runtime with the usual setup step, such as actions/setup-node. Job logs stay in GitHub or GitLab, where your team already reads them.

Ideal for#

• Repositories whose jobs run out of memory on ubuntu-latest and need a bigger size for some jobs only.
• Projects with many short jobs, where rounding every job up to a minute adds up.
• Platform teams that want a limit on what one CI job may cost.
• Companies on both GitHub Actions and GitLab CI, or on GitHub Enterprise Server, that want one runner tool.
• Coding-agent and eval teams already on Promigence that want CI on the same account.
• Engineers who want to start and stop their own runners with one command and a token they control.

2. GitHub-hosted runners#

GitHub's own runners are the default for GitHub Actions: virtual machines GitHub hosts, with the runner application and other tools preinstalled, and machine maintenance and upgrades taken care of for you. A job picks one by label, such as ubuntu-latest, and apart from the single-CPU runners each job gets a new virtual machine.

Key features#

• Standard runners on Linux, Windows or macOS, on x64 and arm64. On a private repository the Linux and Windows runners have 2 CPUs and 8 GB of memory, and on a public one 4 CPUs and 16 GB.
• Free and unlimited standard runners on public repositories. Private repositories get included minutes each month: 2,000 on Free, 3,000 on Pro or Team, and 50,000 on Enterprise Cloud.
• Per-minute rates, with each job rounded up to the whole minute: $0.006 for 2-core Linux x64, $0.005 for 2-core Linux arm64, $0.010 for 2-core Windows and $0.062 for macOS.
• Larger runners on the Team and Enterprise Cloud plans: Linux and Windows up to 96 vCPU and 384 GB, arm64 up to 64 vCPU, a GPU size with one Tesla T4, and larger macOS sizes. Enterprise Cloud customers can give larger runners static IP addresses.
• A single-CPU ubuntu-slim runner for light tasks, with a 15-minute job limit.
• Concurrent jobs by plan: 20 on Free, 40 on Pro, 60 on Team and 500 on Enterprise. A job can run for up to 6 hours.

Where it fits#

GitHub-hosted runners are the place to start, and for many repositories the place to stay. There is nothing to install, no extra account and no token to manage, and GitHub keeps the machines and the images current. Open-source projects get standard runners free and without limit, which none of the other options here offers.

They also cover the widest range of systems and sizes on this list: Linux, Windows or macOS, x64 or arm64, a GPU size, and larger runners up to 96 vCPU. Workflows that build for several platforms can keep every job on one provider and one bill.

The cost grows with size and length. Each job is rounded up to the whole minute, larger runners are always billed (included minutes never cover them), and GitHub notes that a larger runner may not have a warm machine ready on the first request. Budgets can limit what the account spends. There are no GitHub-hosted runners on GitHub Enterprise Server, so teams there run their own.

Ideal for#

• Public repositories and open-source projects, where standard runners are free and unlimited.
• Small teams whose private repositories fit inside the included minutes.
• Workflows that need macOS, Windows or a GPU size.
• Very large jobs that need more than 64 vCPU, up to 96.
• Organizations on Enterprise Cloud that need static IP addresses for larger runners.
• Anyone who wants nothing outside GitHub to set up or pay for.

3. Blacksmith#

Blacksmith is a hosted runner service for GitHub Actions. An organization installs the Blacksmith GitHub App, then points runs-on at a Blacksmith tag such as blacksmith-2vcpu-ubuntu-2404, by hand or with its Migration Wizard. The runners boot from the same images as GitHub's runners, so the preinstalled software matches.

Key features#

• Ubuntu on x64 and Arm from 2 to 32 vCPU (up to 128 GB of memory on x64), Windows Server 2025 in public beta, and macOS on Apple M4 with 6 or 12 vCPU.
• Per-minute rates: $0.004 for 2 vCPU Ubuntu x64, doubling with each size up to $0.064 at 32 vCPU; $0.0025 for 2 vCPU Arm, $0.008 for 2 vCPU Windows and $0.08 for 6 vCPU macOS, with 3,000 free minutes a month.
• Every size available on demand, with no concurrency limits; Linux and Windows jobs run on ephemeral machines.
• A cache that the official GitHub and popular third-party cache actions use as they are, with 25 GB of free storage per repository each week. Docker layer caching and sticky disks are $0.50 per GB a month.
• Run history, log search, test analytics and CI analytics, plus SSH into a running job, which an admin turns on and which costs nothing extra.
• Static IP addresses at $100 per IP a month, a monthly spending alert by email, and GitHub Enterprise Server or Enterprise Cloud with data residency, set up through Blacksmith's support team.

Where it fits#

It suits teams that want hosted runners with the same software as GitHub's on different hardware. Because its runners start from GitHub's own images, a workflow that relies on a preinstalled tool keeps working after the label changes, and the Migration Wizard updates the labels in your workflow files. According to Blacksmith, its jobs run on gaming CPUs with higher single-thread performance.

It also sells the tools around CI. The standard cache actions use its cache unchanged, Docker builds can reuse cached layers, and run history, log search and test analytics show where time goes. When a job misbehaves, an admin can turn on SSH into the running job to inspect it.

Setup leaves no standing credentials: the GitHub App registers runners as they are needed, and the docs say no personal access tokens or deploy keys are involved. It serves GitHub organizations, not personal repositories, and Windows runners are still a public beta. The Enterprise plan adds a 99.9% SLA, 24/7 priority support and a dedicated Slack channel.

Ideal for#

• Organizations on GitHub that want hosted runners with the same preinstalled software as GitHub's.
• Heavy Docker builds that gain from Docker layer caching.
• Engineering teams that want CI observability: log search, test analytics and SSH into a running job.
• Arm and Windows workflows that want a lower per-minute rate than GitHub's standard runners.
• macOS jobs that should run on Apple M4.
• Enterprises that want an SLA and GitHub Enterprise Server support.

4. Depot#

Depot sells GitHub Actions runners alongside its container builds. An organization owner connects the Depot organization to GitHub and installs the Depot GitHub App, and from then on switching a job is one label, such as runs-on: depot-ubuntu-24.04.

Key features#

• Ubuntu from 2 vCPU and 8 GB up to 64 vCPU and 256 GB, on Intel or Arm at the same prices; Windows from 2 to 64 vCPU; macOS on M2 and M4 with 8 vCPU and 24 GB; GPU runners on the Business plan.
• Runner time tracked by the second, with no one-minute minimum per run, and the minutes added up at the end of the billing period.
• Plans: Developer at $20 a month with 2,000 GitHub Actions minutes and one user, Startup at $200 a month with 20,000 minutes and unlimited users, and Business on custom pricing. Past the included minutes, a 2 vCPU Linux runner is $0.006 a minute, and each size up doubles the rate.
• No concurrency limits, cache size limits or network limits.
• A cache built into the runners with no configuration, and container builds that run next to the runner.
• Ephemeral machines that are never reused, monthly usage caps on GitHub Actions minutes, and egress filtering to control which services a runner can reach.

Where it fits#

It fits teams whose CI is mostly short jobs and container builds. Runner time is tracked by the second with no one-minute minimum per run, so a pile of small jobs is not rounded up job by job, and a container build sent to Depot runs on a builder next to the runner.

Its plans bundle minutes. The $20 Developer plan includes 2,000 a month for one user, the $200 Startup plan 20,000 for unlimited users, and every plan has unlimited concurrency. Intel and Arm runners cost the same at every size, which suits teams that build for both.

Control comes from the account: a monthly cap on minutes, egress filtering for the runners, and machines that are never reused. Two limits come from its own pages: the runners serve repositories owned by GitHub organizations only, which Depot puts down to a GitHub limitation, and macOS jobs can wait longer at times of high demand.

Ideal for#

• Short-job pipelines that want runner time tracked by the second.
• Teams that also build container images and want those builds next to the runner.
• Companies that want unlimited concurrency on a fixed monthly plan.
• Arm workloads that should cost the same as Intel.
• Builds that need GPU runners or 64 vCPU sizes.
• Security-minded teams that want egress filtering on their runners.

5. Self-hosted runners#

Self-hosted runners are GitHub's runner application on machines of your own, for one repository, an organization or a whole enterprise. Actions usage is free on them, and you pay for the machines and keep them running.

Key features#

• More control of hardware, operating system and software tools than GitHub-hosted runners provide.
• No minutes billed by GitHub; the cost is the machines and their upkeep.
• A job can run for up to 5 days and can wait in the queue for up to 24 hours.
• Ephemeral, just-in-time runners take at most one job before they are removed.
• Machines register with a time-limited token that expires after one hour.
• The only runners GitHub supports on GitHub Enterprise Server.

Where it fits#

Self-hosting fits companies that already run machines and want CI on them: special hardware, a private network, or software that has to be installed a certain way. Jobs can run for days, well past the 6-hour limit on GitHub's runners.

The work is yours. According to GitHub, you are responsible for updating the operating system and all other software, and a self-hosted runner need not have a clean instance for every job. Adding runners as the queue grows is yours to automate.

Self-hosted runners should almost never be used for public repositories, GitHub's security guide says, so this option is for private code. It is also the only option GitHub offers on GitHub Enterprise Server.

Ideal for#

• Anyone on GitHub Enterprise Server.
• Jobs that need special hardware or access to a private network.
• Long jobs, up to 5 days.
• Operations teams that already maintain machines.
• Private repositories whose CI must stay on company machines.

What sets Promigence apart#

A cap on each job#

The promigence runners command gives every job a limit on what it may cost. --cap sets it, and by default it is what the job's full timeout costs at its size, so no single job can run up the bill past that. --max holds how many sandboxes run at once. Budgets on GitHub, Blacksmith's spending alert and Depot's usage caps limit an account's spend or minutes over a period, never one job.

Billed for the seconds a job runs#

Every job is billed for the seconds it runs, on hosted runners and with the command. By comparison, GitHub rounds every job up to the whole minute and Blacksmith prices by the minute, while Depot tracks time by the second and totals the minutes at the end of the billing period. For GitHub Actions jobs, waiting runners (--warm) are the one setting billed while nothing runs, and they stay off unless you ask for them.

One runner for GitHub Actions and GitLab CI#

The same CLI runs GitHub Actions and GitLab CI jobs, on runners Promigence AI hosts or on runners you start yourself, and the command serves GitHub Enterprise Server with --github-api. Each job gets a fresh sandbox, and its log stays in GitHub or GitLab, where your team already reads it.

Try Promigence free#

All plans start with $50 of free credit. Create an account and follow the quickstart, then move one workflow with the GitHub Actions runner guide: change runs-on to promigence, add the repository under Runners in the console, and compare the job log and the bill with the original over a week.

Sources#

These vendor pages were read on 25 Oct 2026. Prices and limits change, and each vendor's own page is the authority.

If anything on this page is out of date or wrong, write to support@promigence.ai and we will correct it and note the date.