Sandal vs Namespace
Namespace runs GitHub Actions runners on hardware it owns and adds persistent devboxes driven from a CLI. Sandal owns its racks too, bills runners by the second at a lower published rate, and answers the “devbox” need with API-created sandboxes that pause to $0, plus iOS and Android simulators on the same account.
- $ / min · Linux 2 vCPU
- 0.004Namespace0.003Sandal
- Billing granularity
- MinuteNamespaceSecondSandal
- Machines by API
- Devboxes (CLI)NamespaceSandboxes (SDK)Sandal
- Also on the account
- , NamespaceSimulators · XcodeSandal
Two good answers. Here is which one is yours.
- You want persistent development machines from a CLI as much as CI runners.
- Their build and cache tooling is already wired into your pipeline.
- Their region or hardware catalog fits a constraint we do not meet.
- You want per-second billing at a lower published rate on owned hardware.
- Machines should be created from an SDK per task, not kept alive from a CLI.
- The same team also needs iOS and Android simulators or Xcode builds.
Many teams run both. runs-on is per job and a sandbox is per task; nothing here is all or nothing.
What each one actually ships.
Documented capability as of August 2026. Where the honest answer is a qualifier rather than yes or no, the qualifier is printed. Scroll sideways on a small screen.
| Area | Namespace | Sandal | Why it matters |
|---|---|---|---|
| Runtime | |||
| Hardware | Owned racks. | Owned racks: dedicated cores on 4.5 GHz EPYC with local NVMe. | Neither is a hyperscaler reseller. |
| Machines outside CI | Devboxes: persistent development machines from a CLI. | Sandboxes: API-created machines per task, with pause to $0, snapshots and forks. | Different shape, overlapping use case. |
| Isolation | |||
| Tenancy | Ephemeral runner per job. | Single-tenant microVM per job, destroyed on exit. | A fork PR cannot touch your release job. |
| Pricing | |||
| Billing | Per minute. | Per second; queue time free. | Short jobs pay for seconds, not minutes. |
| Surfaces | |||
| Operating systems | Linux, Windows, macOS. | Linux, Windows, macOS and native ARM. | Parity on OS coverage. |
| Beyond CI | Devboxes. | Sandboxes, iOS and Android simulators, Xcode builds. | What else the account can run. |
Capabilities change and rates change. If something here is out of date, tell us and we will fix it the same week.
Same shape. Two meters.
Published rates, August 2026. Namespace bills by the minute; Sandal by the second with queue time free.
- NamespaceLinux · 2 vCPU
- 0.004$ / minute
- SandalLinux · 2 vCPU · paused = $0
- 0.003$ / minute
Five real job lengths on the published 2 vCPU Linux rates. A 71-second job bills as two minutes on a per-minute meter; times thousands of jobs a month, that is the difference.
One label changes.
Sandal registers as a self-hosted runner, so GitHub keeps orchestrating. Every action, cache, secret and reusable workflow keeps working.
- 01≈ 2 min
Install the app
Grant Actions and workflow read on the repos you want to move.
- 02≈ 5 min
Swap the label
npx sandal migrate rewrites runs-on for every job and opens a PR.
- 03≈ 1 week
Watch a week of jobs
Compare wall-clock time and the two invoices.
What we would rather you read here than find later.
A comparison page where the vendor wins every row is a brochure. These are real, and we would rather you land on the right tool than land on us and leave in a month.
- 01
Devboxes from a CLI.
If what you want is a persistent development machine you SSH into and keep, Namespace sells exactly that. Our machines are created per task from an SDK.
Questions teams ask before moving off Namespace.
For runners, yes: change the runs-on label. Devbox workflows map to Sandal sandboxes, which is a different shape, API-created machines that pause between uses.
The rest of the field in ci runners.
Run the same job twice.
Point one workload at Sandal and one at Namespace. The numbers on this page are ours; the ones that matter are yours.