Migrating from Namespace to Latchkey: Honest Comparison + Steps

By Kaveh Alemi·Latchkey

Namespace and Latchkey both give you drop-in GitHub Actions runners reached by a runs-on swap. The honest difference is emphasis: Namespace optimizes for raw build speed and a broad cache/build platform; Latchkey optimizes for self-healing reliability and per-minute cost.

According to Namespace's docs, Namespace provides drop-in GitHub Actions runners that you adopt by changing the runs-on label (for example nscloud-ubuntu-22.04-amd64-8x16 or a namespace-profile-<name>), with Cache Volumes and broad toolchain caching to accelerate builds. Latchkey also attaches managed runners with a one-line runs-on swap, but its focus is self-healing CI: transient and mechanical failures (out-of-memory kills, disk-full errors, registry timeouts) are detected, fixed, and retried automatically. This page is a fair comparison and a practical migration path if reliability and cost are your priority.

Namespace vs Latchkey at a glance

Capability	Namespace	Latchkey
Drop-in via runs-on swap	Yes (nscloud-* or namespace-profile-*)	Yes (one-line runs-on swap)
Cheaper than GitHub-hosted	Yes (per Namespace pricing)	Yes (up to 70% lower per minute)
Built-in caching	Yes (Cache Volumes, broad toolchain caches)	Yes (dependency + Docker layer)
macOS / arm64 runners	Yes (per Namespace docs)	Check current Latchkey docs
Self-healing CI (auto-fix + retry transient failures)	No	Yes
Best known for	Fast runners + broad build/cache platform	Self-healing reliability + low cost

What Namespace is genuinely good at

According to Namespace's own pages, Namespace markets drop-in runners that make workflows "2x-10x faster," backed by Cache Volumes (high-throughput NVMe caching with guaranteed locality) and built-in caching for popular toolchains like Bazel, Nix, Turbo, Gradle, Pants, and sccache. Their docs also list Linux amd64/arm64, Windows, and macOS runner shapes. If your priority is raw build acceleration and a broad cache/build platform, that is a real strength.

What Latchkey emphasizes instead

Latchkey is built around self-healing CI. On its managed runners, transient and mechanical failures are detected, diagnosed, and retried automatically, so flaky builds stop failing your pipeline and you stop paying for manual re-runs. It pairs that with AI build optimization, zero queue time, and up to 70% lower per-minute cost than GitHub-hosted. The differentiation is reliability and cost, not a claim to be the fastest raw runner.

Migration steps (Namespace to Latchkey)

Inventory where you currently use Namespace labels: search your workflows for runs-on values starting with nscloud- or namespace-profile-.
Connect Latchkey to your GitHub org and pick a runner size that matches the Namespace shape you were using (for example an 8 vCPU / 16 GB shape).
Swap the runs-on label on one non-critical workflow to the Latchkey label, leaving the rest on Namespace.
If you relied on Namespace Cache Volumes or the nscloud-cache-action, map those to Latchkey's built-in caching, or keep GitHub Actions Cache which needs no changes.
Run the pipeline a few times, compare wall-clock time, per-minute cost, and how flaky steps behave, then roll out gradually.

What to keep on Namespace

If a specific workflow depends on a Namespace-specific feature (for example a tuned Bazel or Nix Cache Volume, macOS Apple-Silicon shapes, or Devboxes), there is no need to move it just to move it. Both use standard runs-on labels, so you can run them side by side and migrate only the workflows where self-healing and cost matter most.

The verdict

If you want the fastest raw runners plus a broad cache/build platform, Namespace is a strong choice and worth keeping for those workloads. If your real pain is flaky re-runs and per-minute cost, Latchkey adds self-healing on managed runners at up to 70% lower cost than GitHub-hosted, with the same one-line runs-on swap. Verify current Namespace pricing on namespace.so/pricing, then pilot Latchkey on one workflow and compare against your real builds.

Switching costs you one line

Latchkey runners are a drop-in replacement: change runs-on: and the rest of the workflow is untouched. Self-healing is on by default, so transient failures are fixed and retried instead of failing the build.

.github/workflows/ci.yml

# before
    runs-on: ubuntu-latest

# after
    runs-on: latchkey-medium

Start free - 30-day trial, no credit card required, or estimate your savings first.

Frequently asked questions

Is switching from Namespace to Latchkey disruptive?

Both attach managed runners through a runs-on label change, so you can migrate one workflow at a time and run them side by side. Your workflow YAML, actions, and steps stay the same.

Will I lose Namespace caching if I move?

According to Namespace's docs, Cache Volumes and the nscloud-cache-action are Namespace-specific. Latchkey provides its own built-in dependency and Docker layer caching, and GitHub Actions Cache works on either. Map the caches you rely on before migrating a heavy workflow.

Where do these Namespace facts come from, and is the pricing current?

The Namespace details on this page are drawn from Namespace's own public pages, reviewed 2026-07-02: the product site (namespace.so), pricing (namespace.so/pricing), the GitHub Actions getting-started and runner-configuration docs (namespace.so/docs/solutions/github-actions and namespace.so/docs/reference/github-actions/runner-configuration), and the caching docs (namespace.so/docs/solutions/github-actions/caching). Vendor pricing and features change, so verify current Namespace pricing and shapes on namespace.so/pricing before you decide.

References

GitHub Actions documentation