# What Namespace runners are, and how unit minutes work

> How namespace runners work on GitHub Actions: profiles and labels, machine shapes, unit-minute billing, cache volumes, and the published ceilings.

Source: https://latchkey.dev/learn/runners/namespace-runners-explained  
Updated: 2026-09-20

Namespace runners are GitHub Actions runners sold by the compute unit rather than the wall-clock minute, where one unit is 1 vCPU plus 2 GB of RAM for a minute, multiplied by 1 on Linux, 2 on Windows and 10 on macOS. You select one either by creating a profile in the dashboard and naming it in `runs-on`, or by spelling the whole machine out in a label.

Namespace Cloud sells compute for CI and development: these GitHub Actions runners, Devboxes, remote Docker builders, and caches for Bazel, Turborepo and the container registry underneath them. The runners are a drop-in replacement, adopted by connecting your GitHub organization and changing one line.

Everything below was read from namespace.so on 20 September 2026, including its machine-readable pricing page, and is dated here. For the head-to-heads, [Namespace against GitHub-hosted runners](/learn/runners/namespace-vs-github-hosted-runners) and [Namespace against Blacksmith](/learn/runners/namespace-vs-blacksmith) carry the comparison tables.

## Two ways to ask for a machine

The first is a profile. You create it in the dashboard, pick the OS, architecture and shape, name it, and reference that name: `runs-on: namespace-profile-big-apple`. Caching options, runner controls and other settings live on the profile, so the workflow stays short and the configuration is centralized.

The second puts everything in the label, which keeps the machine under version control with the workflow that needs it. The grammar is `nscloud-{os}-{arch}-{shape}`, with optional `-with-cache`, `-with-features` and `-with-builders` suffixes and companion labels underneath. One rule matters more than the rest: only one `nscloud` label is allowed, and a job with two of them, or with an invalid one, is never scheduled at all.

```.github/workflows/ci.yml
jobs:
   tests:
-    runs-on: ubuntu-latest
+    runs-on:
+      - nscloud-ubuntu-24.04-amd64-8x16-with-cache
+      - nscloud-cache-tag-my-repo-e2e
+      - nscloud-cache-size-50gb
```

## The shapes, and what a unit minute is

A shape is written vCPU by memory: `4x8` is 4 vCPU with 8 GB. Standard Linux and Windows shapes are multiples of 1 vCPU and 2 GB, and a shape with a different ratio is counted as the larger of its vCPU count and half its gigabytes, so 8 vCPU with 32 GB counts as 16 units a minute rather than 8. Ubuntu runs 20.04 through 26.04 on amd64 and arm64, Windows Server 2022 on amd64, and macOS from Sonoma to Tahoe on Apple M5 Max or M4 Pro.

Usage is then accounted in unit minutes: vCPU count times minutes times the platform multiplier. Namespace prices those two ways, prepaid through a plan or as overage, and the difference is exactly 50%.

| Shape | Units per minute | Prepaid | Overage | Minutes the $100 Team plan buys |
| --- | --- | --- | --- | --- |
| Linux 2 vCPU, 4 GB | 2 | $0.002 | $0.003 | 50,000 |
| Linux 2 vCPU, 8 GB | 4 | $0.004 | $0.006 | 25,000 |
| Linux 4 vCPU, 16 GB | 8 | $0.008 | $0.012 | 12,500 |
| Linux 8 vCPU, 32 GB | 16 | $0.016 | $0.024 | 6,250 |
| Windows 2 vCPU, 4 GB | 4 | $0.004 | $0.006 | 25,000 |
| macOS 6 vCPU, 14 GB | 60 | $0.06 | $0.09 | 1,667 |

Two readings of that table decide whether Namespace is cheap for you. The shape that matches a standard GitHub-hosted Linux runner, 2 vCPU with 8 GB, is $0.004 a minute prepaid, a third below GitHub's $0.006. The shape one row above it is half that, and it is also half the memory, which is the comparison Namespace's own rate card invites and the one to be careful with.

The plans are the prepaid rate rather than a fee on top of it: Team is $100 a month for 100,000 unit minutes, Business is $250 for 250,000, and the Developer tier is pay as you go with no allowance. Rounding is published too, and it rounds down more often than GitHub does: there is a one-minute minimum, and the next 15 seconds are dropped, so 30 seconds bills as 1 minute and 70 seconds also bills as 1.

## Cache volumes, which are the real feature

A cache volume is a block device that persists between runs and mounts at `/cache`. You attach one by adding `-with-cache` to the machine label and a `nscloud-cache-tag-{tag}` companion label; Namespace attaches the most recently used volume carrying that tag. The default size is 20 GB, and the maximum depends on the plan: 50 GB on Team and 100 GB on Business.

Because volumes are addressed by tag rather than by key, any job with the same tag shares the volume, including jobs on different shapes and in other repositories. That is the strength and the sharp edge in one sentence. The `nscloud-cache-action` used to populate it has no manual partitioning and no cache keys, so uses are shared across everyone on that profile, including branch runs. The documented protections are label-based: `nscloud-cache-allow-commit-from-{branch}` restricts which branches may update a volume, and `nscloud-cache-exp-do-not-commit` marks a job as read-only against it.

Three more caches ride on the same mechanism and each is one label: `nscloud-container-image-cache` keeps pulled images, `nscloud-git-mirror-{n}gb` keeps a git mirror per repository so checkouts are incremental, and `nscloud-runner-tool-cache-{n}gb` keeps the toolchains `setup-go` and friends download every run. Storage is billed separately at $0.002 per GB-hour for snapshots and $0.0048 per GB-day for storage, with allowances on the paid plans.

## Docker builds happen somewhere else

Remote Builders are on by default, which means a Docker build in a Namespace job is executed on a separate builder rather than on the runner. The migration note that saves an afternoon: remove `docker/setup-buildx-action` from the workflow, because it overrides the configuration Namespace put there. If you would rather keep the build on the runner, `nscloud-in-runner-builder` does that, and `nscloud-no-remote-builders` turns the feature off.

Docker builds are metered as builds rather than minutes: $0.05 a build on Developer, 1,000 builds included on Team and 2,500 on Business, with more at $10 per 1,000. That is a genuinely different pricing shape from every other vendor in this area, and it favors pipelines with many short builds.

## The published ceilings

- Concurrency is denominated in vCPU, not jobs: 32 vCPU on Developer, 64 on Team, 160 on Business. A single 32-vCPU job therefore fills a Developer account.
- macOS concurrency is separate and smaller: 12, 24 and 48 vCPU on the same three plans.
- Maximum instance duration is 3 hours on Developer, 5 on Team and up to 24 on Business and Enterprise, against GitHub's 6-hour job limit.
- Windows runners and Linux on Apple silicon need Team or above; larger shapes need Business; high-memory instances are Enterprise only.
- Cache volume size is capped by plan at 50 GB on Team and 100 GB on Business, and support can unlock shapes up to 512 GB of RAM.

## What it is best at, and where it falls short

Best at: teams whose bill is dominated by dependency restore and container pulls, because the cache volumes attack exactly that, and teams who want one vendor for Linux, Windows, macOS and arm64 including Linux on Apple silicon. The unit-minute model is also the most honest in the category, in the sense that memory is priced rather than bundled, so a memory-hungry job costs what it costs instead of being unavailable.

Where it falls short: the same unit-minute model makes a bill hard to predict before you run it, since the number you are charged is neither minutes nor jobs. Concurrency in vCPU surprises people the first time a wide matrix stalls. The cheapest published Linux shape carries 4 GB against GitHub's 8 GB, so a rate comparison that ignores memory flatters it. And `nscloud-cache-action` has no cache keys, which is a change in habit for anyone who has spent years tuning `actions/cache` keys.

## What a Latchkey user would notice

Namespace sells platforms we do not: Windows, macOS, arm64 and Linux on Apple silicon. It also prices memory directly, and publishes concurrency and job-duration ceilings by plan; ours are 20 busy runners per workspace and a 4-hour job limit, documented in [limits and concurrency](/documentation/runner-limits).

Against that, a matched machine, 2 vCPU with 8 GB, is $0.004 a minute prepaid on Namespace and $0.0025 on Latchkey, and Namespace's figure needs the $100 plan to hold. The difference neither rate card prices is the retry: a transient failure is diagnosed and retried inside the job on a Latchkey runner, and on Namespace it fails the job and bills the re-run.

## FAQ

### How do I attach a cache volume to a Namespace runner?

Add `-with-cache` to the machine label and a `nscloud-cache-tag-{tag}` label beside it; the volume mounts at `/cache`, which is not configurable. `nscloud-cache-size-{n}gb` sets the size, with a 20 GB default and a plan-dependent maximum of 50 GB on Team and 100 GB on Business. Jobs that carry the same tag share one volume, even across repositories.

### Does Namespace round CI minutes up?

Partly. It publishes a one-minute minimum and then rounds the next 15 seconds down, so 30 seconds bills as 1 minute and 70 seconds also bills as 1, where GitHub would bill 2. The rounding applies to wall-clock minutes, which are then multiplied by the shape and platform to get unit minutes.

### Which Namespace plan do I need for Windows runners?

Team or above. Its pricing page lists Windows runners and Linux on Apple silicon as unavailable on the Developer tier, and its FAQ says Windows runners are included in the current Team, Business and Business+ plans. Windows also consumes unit minutes at twice the Linux rate for the same shape.

### What hardware do Namespace runners use?

Linux and Windows amd64 workloads run on AMD EPYC CPUs. Linux arm64 runs on AmpereOne or on Apple silicon, specifically M4 Pro and M5 Max. macOS runs mostly on Apple M5 Max with some capacity on M4 Pro. Namespace publishes this on its pricing page and in its GitHub Actions guide rather than leaving it to inference.

## References

- [Namespace pricing: plans, shapes, unit minutes, rounding and concurrency](https://namespace.so/pricing)
- [Namespace runner labels: the grammar, cache volumes and builder controls](https://namespace.so/docs/reference/github-actions/runner-configuration)
- [Namespace GitHub Actions guide: profiles, caching and Remote Builders](https://namespace.so/docs/solutions/github-actions)
- [GitHub Actions runner pricing, for the rates compared here](https://docs.github.com/en/billing/reference/actions-runner-pricing)
- [Latchkey runner sizes, rates and plans](https://latchkey.dev/pricing)

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt