What Namespace runners are, and how unit minutes work

By Daniel Zoghalchali·Latchkey

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 and Namespace against 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.

 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%.

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.

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.

Key takeaways

• Select a runner with a dashboard profile name or the nscloud-{os}-{arch}-{shape} label grammar, never two nscloud labels at once.
• Billing is unit minutes: vCPU times minutes times 1 on Linux, 2 on Windows and 10 on macOS, prepaid or 50% more as overage.
• The $100 Team plan is 100,000 unit minutes, which is 25,000 minutes of a GitHub-matched 2 vCPU, 8 GB runner.
• Cache volumes mount at /cache, are shared by tag rather than key, and are capped at 50 GB on Team and 100 GB on Business.
• Concurrency is measured in vCPU (32, 64, 160) and job duration is capped at 3, 5 or 24 hours by plan.

Frequently asked questions

Related guides

References

• Namespace pricing: plans, shapes, unit minutes, rounding and concurrency
• Namespace runner labels: the grammar, cache volumes and builder controls
• Namespace GitHub Actions guide: profiles, caching and Remote Builders
• GitHub Actions runner pricing, for the rates compared here
• Latchkey runner sizes, rates and plans
• GitHub Actions documentation