DEV Community: Sengi Runners

The cheapest GitHub Actions runners in 2026: what 100,000 minutes actually cost

Sengi Runners — Sat, 07 Nov 2026 19:48:46 +0000

We run hosted GitHub Actions runners, so "what does a CI minute really cost?" is a question we answer for customers every week. Most teams asking it have just had a surprise bill: an AI agent opening pull requests all day, a test matrix that quietly doubled, or a macOS job nobody noticed.

So we priced every option the same way, from each provider's own pricing page, and put them side by side.

GitHub Actions runner pricing, side by side

To compare like with like: 100,000 minutes a month of Linux jobs on 4 vCPUs, roughly 110 ten-minute jobs a day. Prices read on November 7, 2026.

Runner	Where jobs run	Cost per minute (4 vCPU Linux)	100,000 minutes
Sengi Basic	Sengi's managed runners	$0.002	$200, with 3,000 free minutes a month
Sengi Premium	Sengi's managed runners, faster class	$0.006	$600
Blacksmith	Blacksmith's hardware	$0.008	$800, with 3,000 free minutes a month
WarpBuild	WarpBuild's cloud	$0.008	$800
Namespace	Namespace's hardware	$0.012 pay as you go ($0.008 on the $100/month Team plan)	$800 to $1,200
GitHub larger runner	GitHub	$0.012	$1,200
Depot	Depot's cloud	$0.012	$1,200, plus a plan from $20 a month
RunsOn	Your AWS account	~$0.0013 on spot	~$130 plus a €300+ yearly licence, plus running it
Actions Runner Controller	Your Kubernetes cluster	Your cluster's cost	Your cluster's share, plus running it

The pattern: managed runners cost $0.002 to $0.012 a minute, and Sengi Basic is the cheapest one you don't have to operate. At this volume it's $1,000 a month less than GitHub's larger runner for the same jobs.

At 2 vCPU the gap is the same shape: Sengi Basic is $0.001 a minute against GitHub's $0.006, so a dollar buys six times the minutes.

What actually drives a GitHub Actions bill

macOS minutes cost ten times Linux ones. Past your included minutes, GitHub charges $0.062 a minute for macOS against $0.006 for Linux. One lint job on macos-latest that should have been on Linux can cost more than the rest of the pipeline. Check the usage report for jobs that don't need a Mac.

Every matrix leg is billed separately, and each job rounds up. A 12-leg matrix where each leg runs 20 seconds bills 12 minutes, not 4. Coding agents make this worse: every push from an agent re-runs the whole matrix.

Most minutes don't need to be fast. Lint, unit tests, type checks and nightly jobs are the bulk of CI time, and nobody is watching them finish. Those belong on the cheapest runner you can find. The few jobs people actually wait on, like the Docker image or the integration suite blocking a merge, are where a faster class pays for itself.

Per-minute price is only half the sum. If a job runs twice as fast, it uses half the minutes. That's why we sell two classes: Basic for price, and Premium for speed. On a PostHog Docker build at 4 vCPU, Sengi Premium finished in 7m34s; GitHub's runner took 14m36s.

Self-hosting is cheap per minute and expensive per engineer. Running your own fleet on spot instances gets the raw minute under $0.002, but you own the images, the autoscaling, spot interruptions, disk and network costs, and the pager. For most teams that time costs more than the difference.

Which runner is cheapest for you

Most teams: Sengi Basic. The lowest per-minute price of any managed runner in the table, $0.001 at 2 vCPU, 3,000 free minutes a month, and nothing to run yourself. Put Premium on the few jobs where speed matters.
You want jobs inside your own cloud account and have someone to run it: RunsOn on AWS, or Actions Runner Controller if you already run Kubernetes.
macOS jobs: keep those on GitHub or a provider with Mac runners, and move the Linux jobs, which are usually most of the minutes.

Whichever you pick, switching is one line per job:

jobs:
  test:
    # runs-on: ubuntu-latest                 # GitHub
    runs-on: sengi-basic-2-ubuntu-2404       # Sengi Basic, $0.001/min

  image:
    runs-on: sengi-premium-4-ubuntu-2404     # Sengi Premium, for the slow Docker build

Your workflows, secrets and logs stay in GitHub. You can start without a card, and the 3,000 free minutes cover a real trial on one workflow.

Sources and more detail

The full price table, re-checked every month with a source for every number, is on our site:

The 2026 GitHub Actions runner price table
Sengi Basic vs Premium
GitHub Actions cost calculator for your own minutes

If a price here is out of date, tell us in the comments and we'll fix it.

Disclosure: this post is by the team behind Sengi.

Cheap runners for most CI jobs, fast runners for the few that matter

Sengi Runners — Sat, 07 Nov 2026 19:47:16 +0000

We build Sengi, a hosted runner service for GitHub Actions. Today we launched Sengi Basic, at $1 per 1,000 runner minutes. This post is about the idea behind it: pick the runner per job, not per company.

Most CI minutes aren't urgent

Look at a typical workflow run. Lint, unit tests, type checks, dependency audits, nightly jobs. Nobody is waiting on most of them. Then there are one or two jobs everyone is waiting on: the Docker image, the release build, the slow integration suite blocking a merge.

Paying the same per-minute rate for both makes no sense. So Sengi has two classes:

Size	Basic	Premium	GitHub-hosted Linux
2 vCPU	$0.001/min	$0.003/min	$0.006/min
4 vCPU	$0.002/min	$0.006/min	$0.012/min
8 vCPU	$0.004/min	$0.012/min	$0.022/min

Basic gives you six times the minutes per dollar of GitHub's own runners at 2 and 4 vCPU, and 5.5 times at 8 vCPU. 10,000 2-vCPU minutes cost $10 on Basic and $60 on GitHub at list price.

Premium is the fast class. On a PostHog Docker build at 4 vCPU it finished in 7m34s; GitHub's runner took 14m36s.

Mixing them in one workflow

The class is just the label:

jobs:
  lint:
    runs-on: sengi-basic-2-ubuntu-2404
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run lint

  test:
    runs-on: sengi-basic-4-ubuntu-2404
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

  image:
    needs: test
    runs-on: sengi-premium-8-ubuntu-2404
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t app .

Labels: sengi-basic-{2,4,8}-ubuntu-2404 and sengi-premium-{2,4,8}-ubuntu-2404. Workflows, secrets and logs stay in GitHub Actions.

How to decide

Move every job to Basic.
Find the jobs where someone is waiting on the result.
Run those on Premium and compare time and cost against Basic.
Keep whichever wins for that job.

Free to start

Every account gets 3,000 free Basic minutes a month. A 4-vCPU minute counts as two and an 8-vCPU minute as four.

More on Basic vs Premium: https://sengi.run/blog/sengi-basic-vs-premium

A month of GitHub Actions, worked by hand: $54 on GitHub, $11 on 5 GHz bare metal

Sengi Runners — Fri, 23 Oct 2026 18:47:36 +0000

I work on Sengi, a hosted runner service for GitHub Actions, and the Sengi rows below are ours. GitHub's figures are its published per-minute rates and included minutes, the ones in effect since January 1, 2026. Every line of arithmetic is on the page.

A GitHub Actions bill has two numbers in it: the minutes and the price per minute. Most advice goes after the minutes: cache more, skip jobs, split suites. All good. But both numbers are also set by the machine your job runs on, and that's the lever this post is about.

How to work out your bill by hand

Take last month's job-minutes.
On standard runners in private repositories, subtract your plan's included minutes: 2,000 on GitHub Free, 3,000 on Pro and Team, 50,000 on Enterprise Cloud.
Multiply what's left by the runner's rate: $0.006 a minute for Linux 2-core, $0.012 for 4-core, $0.022 for 8-core.

Larger runners skip step 2. Included minutes never apply to them, so GitHub bills a 4- or 8-core job from its first minute. Each job is rounded up to a whole minute before the rate applies. Storage is a separate meter; leave it out, because it doesn't move when compute does.

Lever one: the price per minute

Sengi's matched sizes are $0.003, $0.006 and $0.012 a minute for 2, 4 and 8 vCPU, against GitHub's $0.006, $0.012 and $0.022. That's up to half the price for the same vCPU and memory.

Lever two: the minutes themselves

A hosted runner is a slice of a cloud server CPU on network storage. Sengi runs every job in a fresh VM on an AMD Ryzen 9 7950X3D: a desktop CPU boosting past 5 GHz, with DDR5 and local NVMe, on bare metal. Against GitHub's ubuntu-latest at the same size, that gets up to 3× the multi-core CPU, 1.65× the single-core and 15× the random-read disk speed. It's also the same CPU model on every job.

That shows up as fewer minutes:

Build	GitHub-hosted	Sengi	Faster
Production Docker image (PostHog), 4 vCPU	14m36s	7m34s	1.9×
Rust + TypeScript + Docker together, 4 vCPU	20m43s	11m28s	1.8×
Node + Docker build (real CI), 2 vCPU	539 s	299 s	1.8×

Multiply the two levers together and you get the price per build. That Docker image costs $0.175 on GitHub (14m36s at $0.012) and $0.045 on Sengi (7m34s at $0.006): 74% less per build.

Three months, worked by hand

Typical CI throughout: 1.8× faster on 2 vCPU and 1.81× on 4 vCPU, the measured speed-ups above. Sengi includes 3,000 free minutes a month, counted in 2 vCPU minutes, so they cover 1,500 minutes on 4 vCPU.

Under the quota: GitHub Free, 1,500 private minutes

Line	Minutes	Rate	Cost
GitHub: inside the 2,000 included	1,500	—	$0.00
Sengi, 2 vCPU: 1,500 ÷ 1.8, inside the free 3,000	834	$0.003	$0.00

Below the quota, neither side bills compute.

Over the quota: GitHub Team, 12,000 private Linux 2-core minutes

Line	Minutes	Rate	Cost
GitHub: 12,000 − 3,000 included	9,000	$0.006	$54.00
Sengi, 2 vCPU: 12,000 ÷ 1.8 = 6,667, − 3,000 free	3,667	$0.003	$11.00
You save			$43.00 (80%)

A larger runner: GitHub Team, 6,000 minutes on Linux 4-core

Line	Minutes	Rate	Cost
GitHub: no included minutes on larger runners	6,000	$0.012	$72.00
Sengi, 4 vCPU: 6,000 ÷ 1.81 = 3,315, − 1,500 free	1,815	$0.006	$10.89
You save			$61.11 (85%)

The larger runner is where the gap is widest. GitHub bills every one of those minutes at $0.012, while Sengi finishes the same work in fewer minutes at half the rate.

To run your own numbers, the cost calculator takes your plan, minutes, runner size and job type (typical CI, Docker, Rust or TypeScript). It runs in your browser with no email gate.

Caches come along

actions/cache, the setup-* actions' caches and Docker's type=gha layer cache all work unchanged on Sengi, served from Sengi's own cache and included in the price. With a warm type=gha cache, one measured Docker build step went from 68 s to 36 s.

Switching is one line

Install the Sengi GitHub App, connect the repository, then:

jobs:
  test:
-   runs-on: ubuntu-latest
+   runs-on: sengi-standard-2-ubuntu-2404

sengi-standard-4-ubuntu-2404 and sengi-standard-8-ubuntu-2404 give you 4 and 8 vCPU. Steps, secrets, triggers and logs stay in GitHub. 2 vCPU runners are pre-booted, so jobs start in about 2 seconds, and boot and teardown are never billed. Runners are Ubuntu 24.04 on x64. If you'd rather not touch the YAML, there's a prompt for your coding agent that finds every eligible job and opens the pull request for you.

3,000 free minutes every month, no card: point your slowest job at sengi.run and compare its run time with last week's.

Check GitHub Actions runner compatibility before switching providers

Sengi Runners — Mon, 12 Oct 2026 19:34:00 +0000

Disclosure: This guide is from the Sengi team and was written with AI. Sengi is the managed runner service used in the example.

A runner change can be a small pull request, but a small diff does not mean every job will behave identically. The machine still needs the right operating system, tool versions and container environment.

Before moving a Linux job, check these assumptions. The goal is a first successful result you can compare with your existing run, not a repository-wide rewrite.

Check what the label actually selects

GitHub uses runs-on to choose a machine. An array is an intersection: the runner must match every listed label. Adding a new provider's label to an old array is not the same as replacing the target. GitHub explains label matching here.

For Sengi, a supported target is a complete label:

runs-on: sengi-standard-2-ubuntu-2404

Use the provider's documented form rather than inventing combinations. If the selection comes from a matrix, an expression or a reusable workflow, inspect where that value is defined before changing it.

Sengi currently offers Ubuntu 24.04 on x64. Leave Windows, macOS, arm64 and jobs requiring another operating-system image on their existing runners. A job on ubuntu-latest also needs an image check: switching to a fixed Ubuntu 24.04 target may change an assumption about what “latest” supplies. Sengi's migration instructions identify the supported targets.

Make tool dependencies explicit

A working build can quietly depend on software that happens to be installed on its current runner. Look for commands such as node, python, ruby, java, docker and native compilers. For each important dependency, identify how the workflow selects its version.

Prefer an existing setup step or your project's documented installation procedure over relying on whichever executable appears first in the machine's path. Keep the dependency lockfile and install command unchanged for the first comparison. Otherwise, a runner migration and a dependency upgrade become one experiment that is harder to diagnose.

If you need a diagnostic step, print only the relevant tool versions. Do not dump the whole environment: CI logs can contain sensitive information, and a version check does not require exposing secrets.

Treat containers as a separate compatibility check

A job-level container: setting changes where script steps execute. Check the image, registry access and shell assumptions as well as the host runner. GitHub's container documentation notes that the default shell inside a job container is sh, not bash; an explicit shell can override it. It also warns that Docker Hub's normal pull limits can affect self-hosted runners. Read the container behavior.

Do not remove registry authentication or alter service-container networking merely to make a migration look like a one-line change. Keep those settings intact, then inspect the first result on the chosen runner. A failure while pulling an image and a failure in your test suite need different fixes.

Separate routing trouble from a failed step

If the job never starts, inspect the exact label, repository connection and available capacity. If it starts and fails, inspect the first failing step and compare it with the previous run. Changing five unrelated settings at once usually destroys the useful comparison.

For Sengi, connect the repository to a project through Connect GitHub before merging its runner-label change. Installing the GitHub App alone is not the complete connection. The current migration guide walks through that sequence.

Keep the first trial reversible

Choose one representative build or test job. Review the pull request, let its normal trigger run, then compare the result, artifacts and required checks. Only widen the change once that job behaves as expected.

Keep the original label in the pull-request diff so rollback is a simple revert. A green first run is useful evidence; it is not proof that every job in a large matrix has the same requirements.

That is the practical benefit of keeping GitHub Actions while changing execution services: you can test the machine choice without replacing the workflow system. Start small, preserve the comparison, and expand based on actual results.

Move a Linux GitHub Actions job to Sengi without replacing your workflow

Sengi Runners — Mon, 12 Oct 2026 19:05:10 +0000

Disclosure: I work on Sengi, the runner service used in this walkthrough.

Changing your CI provider can sound like a rewrite. With GitHub Actions, there is a smaller option: keep Actions for the workflow and use another service for the machine that runs a job.

Sengi follows that model. You keep reviewing results in GitHub. For a supported job, the workflow change is its runner label. Here is how to try it on one job, see the result, and undo it if it is not a fit.

Pick a job that fits

Start with a straightforward build or test job using Ubuntu 24.04 on x64. Sengi currently offers that platform, not Windows, macOS, arm64 or older Ubuntu images.

Read the actual job before changing it. A literal runner label is straightforward. A matrix expression, a reusable workflow or a runner group needs closer inspection because the machine selection may happen somewhere else. Keep unrelated jobs unchanged for the first trial.

Connect the repository first

Create an account at Sengi, choose Connect GitHub, and select the repository you want to use. This grants the GitHub access and connects the repository to a Sengi project.

Installing the GitHub App directly is not the same as completing that connection. Confirm the repository appears in your Sengi project before merging a runner change.

Change the runner label

For a 2-vCPU runner with 8 GB of RAM, change this line in the chosen job:

runs-on: ubuntu-24.04

to:

runs-on: sengi-standard-2-ubuntu-2404

The same target can be used for compatible Linux x64 jobs currently on ubuntu-latest. It fixes the image at Ubuntu 24.04, so check any assumptions your job makes about the latest image.

Leave steps, permissions, secrets and triggers unchanged. Open a pull request and review the diff before merging. If your repository uses actionlint, declare the custom label in its configuration so the lint check recognizes it.

Prefer a coding agent? The Sengi migration prompt inventories workflow files, reports jobs it skips and asks for review before opening a pull request. The repository connection still needs your consent, and you decide what to merge.

Inspect the first result

Use the next workflow run to check whether the selected job starts, completes and produces the expected outputs. Review the GitHub logs and required checks, not just the runner label in the file.

A queue is not automatically a broken connection. Free accounts share a 12-vCPU concurrency limit. Six 2-vCPU jobs can run together; additional jobs wait for capacity to become available. Once the monthly free allowance is exhausted, new free jobs cannot start, but jobs already running may finish.

If a step behaves differently, inspect that step's dependencies and image assumptions before migrating the rest of the repository.

Understand the allowance

The 2-vCPU size costs $0.003 per execution minute after the applicable free allowance. Each job rounds up separately to a whole minute, and boot and teardown are not billed.

One account gets 3,000 standard-2-equivalent free minutes each month, without a card to start. The 4-vCPU and 8-vCPU sizes use that same pool at two and four times the rate. These are not three separate allowances. Prices checked October 11, 2026; see current pricing.

Keep the rollback small

To return that job to GitHub-hosted execution, revert the runner-label change. Test one representative job first, then decide whether to move others based on their actual behavior, time and cost.