Namespace vs GitHub-Hosted Runners: Unit Pricing Explained
Namespace does not publish a per-minute runner price. It bills unit-minutes, where one unit is 1 vCPU plus 2 GB of RAM. That makes it genuinely cheap on small shapes and hard to compare against anything else.
Namespace is a managed runner provider for GitHub Actions with a pricing model that is different enough to be worth explaining before comparing. Where GitHub-hosted and most alternatives publish a price per runner-minute for a fixed machine shape, Namespace publishes a price per unit-minute, where one unit is 1 vCPU plus 2 GB of RAM. Your cost is vCPU count multiplied by minutes multiplied by a platform factor.
The consequence is that Namespace has no single number you can put next to $0.006. A 2 vCPU Linux runner costs 2 unit-minutes per minute; a 4 vCPU runner costs 4. That is genuinely cheaper than most competitors at small shapes, and it scales linearly in a way per-size rate cards do not.
As with every runner comparison, the public-repository caveat comes first: standard GitHub-hosted runners are free and unlimited on public repositories, at 4 vCPU and 16 GB. Nothing paid beats that. The comparison below assumes a private repository. Figures verified 2026-08-20.
Namespace vs GitHub-hosted, private repository
| GitHub-hosted | Namespace | |
|---|---|---|
| Pricing unit | Per runner-minute, per size | Per unit-minute (1 vCPU + 2 GB) |
| Linux rate | $0.006/min (2-core) | $0.001/unit-min prepaid, $0.0015 overage |
| Linux, 2 vCPU equivalent | $0.006/min | $0.002/min prepaid |
| Linux, 4 vCPU equivalent | $0.012/min | $0.004/min prepaid |
| Platform multipliers | Separate rate per OS | Linux 1x, Windows 2x, macOS 10x, Linux on Apple silicon 7x |
| Plans | Included in GitHub plan | Developer $0 pay-as-you-go, Team $100/mo, Business $250/mo |
| Included compute | 2,000-50,000 min by plan | 100,000 unit-min (Team), 250,000 (Business) |
| Cache | 10 GB per repository | Volume snapshots at $0.002/GB-hr, 5,000-15,000 GB-hr free by tier |
| Automatic failure recovery | No | No |
How to actually compute a Namespace bill
The formula Namespace publishes is vCPU count multiplied by minutes multiplied by the platform multiplier. Their own worked example: 4 vCPU for 5 minutes on Linux is 4 x 5 x 1 = 20 unit-minutes.
| Shape | Unit-min per minute | Prepaid $/min | GitHub-hosted equivalent |
|---|---|---|---|
| Linux 2 vCPU | 2 | $0.002 | $0.006 (2-core) |
| Linux 4 vCPU | 4 | $0.004 | $0.012 (4-core larger) |
| Linux 8 vCPU | 8 | $0.008 | $0.022 (8-core larger) |
| Windows 4 vCPU | 8 (2x multiplier) | $0.008 | $0.022 (4-core larger) |
| macOS 4 vCPU | 40 (10x multiplier) | $0.040 | $0.062 |
Where the unit model bites
Tying RAM to vCPU at a fixed 2 GB ratio is the model choice you need to check against your workload, because it is the one place the cheap headline rate stops applying.
- A job needing 8 GB of RAM but only 2 cores has to buy a 4 vCPU shape to get the memory, so you pay for cores you will not use.
- Java, Gradle, and large Node or Webpack builds are frequently memory-bound rather than CPU-bound, and this is exactly where the ratio costs you.
- The macOS multiplier of 10x and the Linux-on-Apple-silicon multiplier of 7x mean the cheap Linux rate tells you nothing about your macOS bill.
- Cache is billed by GB-hour rather than included, so a large persistent cache is a separate line item to model.
What GitHub-hosted still wins on
- Free and unlimited on public repositories, at a larger 4 vCPU / 16 GB shape than the private-repo default.
- One vendor, one bill, one status page, and the reference runner images every action is tested against.
- No plan commitment to reach the best rate. Namespace prepaid pricing assumes you have bought a tier.
- Predictable arithmetic. Per-minute-per-size is easier to forecast than a unit model with platform multipliers.
Switching is a label change
Like every managed provider in this category, adoption and reversal are the same one-line edit, so a single-job trial is the cheap way to get real numbers instead of modelled ones.
jobs:
test:
# GitHub-hosted
runs-on: ubuntu-latest
# Namespace
runs-on: namespace-profile-default
# Latchkey
runs-on: latchkey-smallNeither one recovers a flaky job
Namespace competes on compute economics. It does not change what happens when a job fails for a reason that has nothing to do with your code. A registry timeout, a browser binary that failed to install, a transient resolution error: on GitHub-hosted and on Namespace the job fails, the failed minutes bill, the re-run bills again, and the merge waits for a human to notice.
Decide with your own repository
- Both tools in a mature category can do the job. What differs is behaviour on your codebase, which takes an afternoon to measure and beats any feature table.
- Benchmark the cold path with no cache. Warm local runs favour whatever you already have cached, which is the one condition CI never has.
- Price the switching cost honestly: lockfile or config format, stricter resolution surfacing latent bugs, and every developer plus every runner having to move together.
The verdict
Public repository: stay on GitHub-hosted. Free and unlimited beats every rate on this page.
Private repository with CPU-proportional memory needs: Namespace is genuinely the cheapest published Linux compute here at equal vCPU count, and the linear unit model is easy to reason about once you internalise it. Confirm the 2 GB-per-vCPU ratio suits your jobs and model the cache GB-hours before committing to a tier.
Private repository with memory-heavy or macOS-heavy pipelines: check the multipliers carefully. The headline Linux rate does not describe what you will pay, and a fixed-shape per-minute provider may end up cheaper for the same work.