Migrate from Namespace Runners Without a Cold Cache

DEV Community

Migrate from Namespace runners without a cold cache

Teams that migrate from Namespace runners are almost never leaving because of the hardware, which is good, and almost always underestimate the same thing: Namespace is not only a label, it is a set of drop-in actions and a cache that behaves unlike any other cache in this market. The label change takes a minute and the cache change decides whether the migration reads as neutral or as a regression. The cache behaviour that changes on the way out, and why a new feature branch starts cold afterwards. Behaviour read from both vendors documentation on 2026-09-21. Start with what moves and what does not. The label moves: runs-on is one line and every destination has a size that matches. The workflow steps mostly move untouched, because they are ordinary steps. Three things do not move, and each one is a real edit. The nscloud- actions have to be swapped back for the standard ones. The cache changes scope, from shared to branch-isolated, which is a behavior change with no error attached. And the remote Docker builders that were on by default stop existing, so a workflow that deleted its buildx setup has to get it back. What a runner profile was carrying Namespace attaches its features to a runner profile rather than to individual steps, which is why the label looks so short and the migration is longer than it looks. A job that reads runs-on: namespace-profile-default may be getting a cache volume, a git mirror, a container image cache and a remote Docker builder without any of those appearing in the workflow file. The undo list below is therefore a list of things to look for in the profile as well as in the YAML. Work through it before you change the label, because after you change it the symptoms are all the same symptom: the job is slower and nothing failed. Namespace surface What it did Standard replacement What changes namespace-profile- label Selected the profile and everything attached to it A size label, for example latchkey-small Features attached to the profile stop being implicit nscloud-checkout-action A faster checkout using a git mirror actions/checkout Clone time returns to an ordinary shallow clone nscloud-cache-action A cache volume, shared across branches actions/cache with explicit keys You now write keys, and restores obey branch scope Remote Docker builders, on by default A warm BuildKit builder beside the runner docker/setup-buildx-action plus cache export Layer cache is exported and imported per build Unit-minute billing Charged at max(vCPU, RAM divided by 2) per minute A fixed per-size rate Memory stops costing extra when cores sit idle Namespace surfaces read from its GitHub Actions documentation on 2026-09-21. The unit-minute model, its platform multipliers and the prepaid against overage split are worked through separately in Namespace alternatives; this page assumes you have already decided to leave and is only about the cutover. The cache is the migration This is the change most likely to make a migrated pipeline slower with nothing in the log to explain it. Namespace documents that its cache action does not support manual partitioning: entries are shared across everything using that runner profile, which includes the default branch and every feature branch at once. actions/cache is the opposite by design, restorable only from the branch that wrote the entry or from the default branch. So a workflow that never thought about cache keys was quietly getting cross-branch hits, and on the other side it will not. The fix is not exotic, it is a prefix key and a restore-keys fallback, but it has to be written before the first run rather than discovered from a timing graph a week later. Write the keys so a new branch falls back to the default branch entry, and accept that the first run on a new dependency set is cold. - uses: actions/cache@v4
with:
path: ~/.npm
key: npm-${{ runner.os }}-${{ hashFiles('/package-lock.json') }}
restore-keys: |
npm-${{ runner.os ...

Powered by Readybot.io*