Railway vs Namespace
Railway hosts apps and databases and added Linux sandbox VMs that are destroyed when they go idle. Namespace is a CI and dev platform whose Devboxes keep their files but are shut down after 4 to 24 hours, even while you work.
The companies and products
Railway
Railway is a cloud platform for deploying web apps, servers and databases, which now also sells sandboxes and cloud agents.
Railway's main product is app hosting: you deploy services and databases as containers on its own hardware. In 2026 it added Sandboxes, isolated Linux VMs you create from the CLI or a TypeScript SDK, run commands in and destroy, and Cloud Agents, a personal VM for running a coding agent, in early access. It suits teams already hosting on Railway who want throwaway machines next to their apps.
Namespace
Namespace is a dev platform for fast builds, tests and coding environments: CI runners, build caches and Devboxes, on its own hardware.
Most of Namespace is CI: a faster drop-in for GitHub Actions runners, with Docker, Bazel, Turborepo and Nix caching. Its Devboxes are remote Linux and macOS machines with persistent storage, made for people and AI coding agents, and they also host sessions for Claude Managed Agents, Cursor Cloud Agents and Devin. It is a different kind of product from bochka, so this page compares the part where they overlap: a machine an agent works on.
- Products
- GitHub Actions runners, Docker, Bazel, Turborepo and Nix caching, Devboxes, and a compute API
- Hardware
- Its own hardware in its own racks: AMD EPYC for Linux and Windows, Apple M4 Pro or M5 Max for macOS
- Linux Devboxes
- Run from a container image you choose and include Docker; the docs do not say whether each one has its own kernel
- Funding
- Announced a $42M Series B
- Compliance
- Trust center lists SOC 2 Type II
Which use cases each one fits
For each use case, Battleships prices every sandbox provider on the same workload and sorts them from the cheapest monthly bill up. “16th cheapest of 366” means 15 of the other 365 providers run that workload, with every feature it needs, for less. “With limits” means the provider runs it but misses something, so it is listed after every full match. Open a use case for its whole ranking and what each provider misses.
| Use case and its workload | Railway: price rank | Namespace: price rank | bochka: price rank |
|---|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month | 51st of 367, with limits $342 a month | 39th of 367, with limits $3,495 a month | 3rd cheapest of 367 $634 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB Railway fits an assistant that never stops if you set the idle timeout to 0, while a Namespace Devbox is shut down after at most 24 hours; bochka has no session cap on paid plans. | 16th cheapest of 366 $3,977 a month | 303rd of 366, with limits $6,645 a month | 5th cheapest of 366 $657 a month |
| Code interpreter bursts 100 at once · 1 vCPU / 2 GB · 200,000 sessions of 1 min a month Railway fits short code runs best of the three: it bills for CPU used, destroys the sandbox when the job ends, and publishes no starts-per-minute limit. | 36th cheapest of 345 $413 a month | 247th of 345, with limits $250 a month | 186th of 345, with limits $2,000 a month |
| Sandboxes for your users 300 at once · 2 vCPU / 4 GB · 30,000 sessions of 23 min a month Railway caps sandboxes at 100 per environment on Pro and Namespace publishes no Devbox concurrency limit, so both are a compromise for 300 user sandboxes at once; bochka fits. | 42nd of 361, with limits $290 a month | 284th of 361, with limits $2,068 a month | Cheapest of 361 $209 a month |
| RL rollouts 1,000 at once · 2 vCPU / 4 GB · 1,000,000 sessions of 3 min a month | 78th of 360, with limits $4,450 a month | 356th of 360, with limits $9,012 a month | 34th of 360, with limits $2,000 a month |
| Agent evals 250 at once · 4 vCPU / 8 GB · 15,000 sessions of 20 min a month | 108th of 364, with limits $364 a month | 282nd of 364, with limits $1,043 a month | 10th cheapest of 364 $200 a month |
| CI runners 40 at once · 8 vCPU / 16 GB · 6,000 sessions of 12 min a month Both fit: CI runners with build caches are Namespace's main product, and Railway can run jobs too, though its sandbox docs do not mention Docker; bochka runs CI on full VMs with Docker and /dev/kvm. | 113th cheapest of 377 $1,210 a month | 80th cheapest of 377 $765 a month | 4th cheapest of 377 $86 a month |
| 24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB Railway sandboxes can run with no idle timeout, while a Namespace Devbox stops when idle and is shut down after at most 24 hours; a bochka machine stays up as long as you want. | 66th cheapest of 368 $89 a month | 126th of 368, with limits $168 a month | 18th cheapest of 368 $26 a month |
| Computer-use agents 50 at once · 4 vCPU / 8 GB · 20,000 sessions of 15 min a month Both are a compromise: Railway sandboxes are headless, and Namespace's screenshot and click API works on macOS Devboxes only; bochka streams a 60fps Linux desktop. | 77th of 369, with limits $103 a month | 67th of 369, with limits $982 a month | 6th cheapest of 369 $200 a month |
| Browser-use agents 50 at once · 2 vCPU / 4 GB · 30,000 sessions of 10 min a month | 53rd of 367, with limits $93 a month | 285th of 367, with limits $789 a month | 7th cheapest of 367 $200 a month |
| Scraping & bots (startup scale) 50 at once · 1 vCPU / 2 GB · 100,000 sessions of 3 min a month | 60th cheapest of 346 $570 a month | 259th of 346, with limits $332 a month | 6th cheapest of 346 $90 a month |
| Mass scraping & bots (undetectable) 1,000 at once · 1 vCPU / 2 GB · 3,000,000 sessions of 2 min a month | 109th of 338, with limits $2,988 a month | 226th of 338, with limits $9,012 a month | 71st of 338, with limits $1,800 a month |
| Parallel red teaming 200 at once · 2 vCPU / 4 GB · 5,000 sessions of 30 min a month | 43rd of 360, with limits $574 a month | 242nd of 360, with limits $339 a month | 2nd cheapest of 360 $200 a month |
| GPU eval jobs 10 at once · 8 vCPU / 32 GB · 500 sessions of 30 min a month None of the three fits: all of them sell CPU machines only. | Can't run it | Can't run it | Can't run it |
| macOS agents 5 at once · 4 vCPU / 8 GB · 1,000 sessions of 20 min a month Only Namespace fits: it runs macOS Devboxes on Apple Silicon, and neither Railway nor bochka has macOS. | Can't run it | 6th cheapest of 36 $1,205 a month | Can't run it |
Key features
| Feature | Railway | Namespace | bochka |
|---|---|---|---|
| CPU speed (Node.js build-and-test, 4 vCPU / 8 GB) | Not measured yet | 21.79 runs/s | 26.69 runs/s |
| Isolation | Sandboxes are isolated Linux VMs; app services are containers | Linux Devboxes run from a container image on Namespace's own hardware; the docs do not say if each has its own kernel | Every sandbox is a full VM with its own kernel |
| When the machine goes idle | Destroyed after the idle timeout (30 minutes by default); files survive only in checkpoints you take | Devbox stops after an idle timeout (15 minutes to 8 hours), keeps its storage at $0.20 per GB-month, and starts when you connect | You stop it; the disk is kept, with snapshots every minute and on stop, and a stopped sandbox costs nothing |
| How long a session can run | No documented maximum; set the idle timeout to 0 and it runs until you destroy it | Devboxes stop after 4, 5 or 24 hours by plan, raisable to 24 at most | No session cap on paid plans |
| Docker and nested virtualization | Root shell on Ubuntu; the sandbox docs do not mention Docker or /dev/kvm | Docker in Linux Devboxes; /dev/kvm on Linux compute instances | Docker, root, systemd and /dev/kvm on every machine |
| Fork and checkpoints | Fork a running sandbox's filesystem; named disk checkpoints to boot new ones | No fork; compute instances can suspend and resume with RAM kept | Fork a running sandbox; named snapshots to start new ones |
| Desktop and computer use | Headless: terminal, exec and SSH only | Screenshot and click API on macOS Devboxes only; VNC and RDP for compute instances | 60fps Linux desktop and Chromium, computer use and browser control, embeddable stream |
| Coding agents | Claude Code, Codex, OpenCode and Pi preinstalled; you run them headless through exec | Hosts Claude Managed Agents, Cursor and Devin sessions run by those partners; an MCP server lets your agent create Devboxes | Claude Code, Codex, OpenCode and more preinstalled, with a prompt, steer and events API |
| Keeping keys out of the sandbox | Secrets go into the sandbox as environment variables, or are saved in a checkpoint | Egress rules inject a header from Namespace Vault, resolved outside the workload | AI credentials proxy for model providers and any HTTPS API you register; switch a credential to another account when credits run out |
| Reaching the machine | Up to 10 public HTTPS domains, set only at creation; SSH and port forwarding | HTTPS URLs that need a Namespace login, TCP through a CLI port-forward; no public IP | HTTPS URLs for up to 50 ports, token-protected; raw TCP; dedicated IPv6 or IPv4 |
| Outbound internet rules | Open internet; no egress allowlist | Egress policies per Devbox blueprint, runner or instance: block, advisory or allow by domain | Open internet on every plan; no provider-side allowlist |
| Operating systems | Linux only | Linux, macOS on Apple Silicon, and Windows on Team plans and up | Linux only; Wine for Windows apps |
| Beyond sandboxes | Hosts web services, Postgres and Redis; a sandbox can join the project's private network | GitHub Actions runners with Docker, Bazel, Turborepo and Nix caching | Sandboxes only; host your own services inside a VM |
| Regions | US West, US East, Amsterdam and Singapore, picked per sandbox | Several regions; ask support for a preferred one, and keeping all work in one region needs Enterprise | EU only: Germany, Finland, France |
Every feature Battleships tracks (43)
| Feature | Railway | Namespace | bochka |
|---|---|---|---|
| Full VM (own kernel) | Yes | Yes | Yes |
| Docker inside | Not published | Yes | Yes |
| Nested virtualization | No | Yes | Yes |
| Root | Yes | Yes | Yes |
| Systemd | Not published | Not published | Yes |
| Desktop GUI | No | Yes | Yes |
| Browser | Yes | No | Yes |
| Computer-use API | No | Yes | Yes |
| SSH | Yes | Yes | Yes |
| Persistent disk | Yes | Yes | Yes |
| Pause/resume | Yes | Yes | Yes |
| Automatic snapshots | No | Yes | Yes |
| Fork/clone | Yes | No | Yes |
| Live fork (no pause) | Yes | No | Yes |
| Memory fork | No | No | No |
| Custom image (Docker or snapshot) | Yes | Yes | Yes |
| ≥24 h sessions | Yes | Yes | Yes |
| Idle auto-stop | Yes | Yes | No |
| Wake on request | No | Yes | No |
| HTTPS preview URLs | Yes | Yes | Yes |
| Raw TCP inbound | No | Yes | Yes |
| Public IPv4 | No | No | No |
| Egress allowlist | No | Yes | No |
| Secret proxy | No | Yes | Yes |
| Secret proxy for any API | No | Yes | Yes |
| Preinstalled agents | Yes | Yes | Yes |
| Agent harness API | Yes | No | Yes |
| MCP server | Yes | Yes | No |
| GPU | No | No | No |
| Windows | No | Yes | No |
| Arm64 | No | Yes | No |
| Self-hosting | No | No | No |
| BYOC | Yes | No | No |
| Open source | No | No | No |
| Scoped API keys | Not published | Not published | Yes |
| Spend limits | Yes | Yes | Yes |
| Usage per sandbox (API) | No | No | Yes |
| Audit logs | Yes | Yes | No |
| SSO | Yes | Yes | No |
| SOC 2 | Yes | Yes | No |
| HIPAA | Yes | No | No |
| EU data residency | Yes | Yes | Yes |
| Zero data retention | Not published | Not published | Yes |
Performance
In StarSling's public run of 2026-09-29, at 4 vCPU / 8 GB, bochka did 26.69 Node.js build-and-test runs per second and Namespace did 21.79, so the same build takes about a fifth longer on Namespace. Railway has no result in that benchmark yet, so we cannot say how it compares.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Namespace measured on: Linux compute instance (unit-minutes, PAYG/overage $0.0015). Railway has no published run in this suite yet, so there is no like-for-like number to compare.
Pricing in five scenarios
Each bill is priced from the providers' public price lists by the open Battleships engine, with the cheapest plan that runs the scenario.
| Scenario | Railway, a month | Namespace, a month | bochka, a month |
|---|---|---|---|
| One coding agent, workdays 4 vCPU / 8 GB, 50 GB disk, 8 hours a day, 22 days a month, files kept between days | $16 · Hobby · with limits | $50 · Devbox (pay as you go) | $20 · $20/mo |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $70 · Hobby · with limits | $176 · Devbox (pay as you go) · with limits | $26 · $20/mo |
| 50 agents in parallel 50 machines of 4 vCPU / 8 GB at once, 8-hour sessions, 1,100 sessions a month, Docker inside | $739 · Hobby · with limits | $2,198 · Devbox (pay as you go) | $317 · $20/mo × 3 seats |
| Sandboxes for your users 2 vCPU / 4 GB, 30,000 sessions of 10 minutes a month, up to 300 at once | $223 · Pro · with limits | $1,214 · Devbox (pay as you go) | $200 · $100/mo × 2 seats |
| 1,000 short jobs at once 2 vCPU / 4 GB, 1,000 at once, 3 minutes each, 200,000 jobs a month | $781 · Pro · with limits | $3,237 · Devbox (pay as you go) | $2,000 · $2000/mo · with limits |
Railway: Railway bills sandboxes per second at $50 per vCPU-month on CPU actually used and $50 per GB-month on memory in use, plus $0.05 per GB out, and memory keeps billing while a sandbox waits. The Hobby ($5) and Pro ($20) fees count toward usage, and sandbox disk has no published price, so our bills leave it out.
Namespace: Devboxes are billed in Devbox Minutes at $0.004 each, pay as you go on every plan: a 4 vCPU / 8 GB Devbox uses one a minute. The minutes in the Team ($100) and Business ($250) plans cover runners and instances, not Devboxes, and stored files cost $0.20 per GB-month.
Namespace: You pick a monthly plan from $20, and all of it becomes usage credit spent per second on running sandboxes. A stopped sandbox costs nothing and keeps its disk.
Limits in those scenarios
Railway is marked as not a clean fit in every scenario because it is an app platform first and does not price sandbox disk, and it caps sandboxes per environment at 50 on Hobby and 100 on Pro, so 300 user sandboxes or 1,000 jobs at once need several environments. On Namespace the limit is time: a Devbox is shut down after 4, 5 or 24 hours by plan, so the agent that never stops restarts at least once a day, and Namespace publishes no egress price. On bochka, the 1,000-job burst is queued above 90 starts a minute and needs more starts per day than the $2,000 plan allows.
| Scenario | Railway | Namespace | bochka |
|---|---|---|---|
| One coding agent, workdays |
|
| None that bite |
| One agent that never stops |
|
| None that bite |
| 50 agents in parallel |
|
| None that bite |
| Sandboxes for your users |
|
| None that bite |
| 1,000 short jobs at once |
|
|
|
Which one should you use?
Use Railway when
your app and databases already live on Railway and you want short-lived sandboxes on the same private network, or you need US or Asia regions.
- Apps and databases next door. Useful if your app already runs on Railway: sandboxes can join the same private network as your Postgres and services.
- No clock on a running sandbox. Useful for agents that run past a day: with the idle timeout set to 0, a Railway sandbox runs until you destroy it.
- Short jobs billed for CPU used. Useful for many quick code runs: Railway bills sandbox CPU on what is used and the VM is gone when the job ends.
Use Namespace when
you need macOS or Windows machines, faster GitHub Actions runners with build caches, or Devboxes for people that stop when idle.
- macOS and Windows. Useful if your agents build iOS or Mac apps or test on Windows: Namespace runs macOS on Apple Silicon and Windows machines.
- CI runners and build caches. Useful if you want faster GitHub Actions: Namespace is a drop-in runner with Docker, Bazel and Turborepo caching.
- Egress rules and idle stop. Useful if agents must reach only chosen domains, or boxes should stop when nobody uses them and start on connect.
Where bochka fits
If what you are really running is AI agents that work for hours or days, both Railway and Namespace make you work around their lifecycle: Railway destroys idle sandboxes and Namespace cuts Devboxes off after 24 hours at most. bochka gives each agent a full VM that keeps its disk, with Docker, a desktop, and coding agents you drive from outside.
A disk that stays, with no clock
A Railway sandbox is destroyed after 30 idle minutes unless you checkpoint it or keep memory billing, and a Namespace Devbox is shut down at 24 hours mid-task. A bochka sandbox stops, keeps its disk and runs as long as the work does.
A desktop, Docker and KVM
Railway sandboxes are headless and their docs do not mention Docker, and Namespace's screenshot API works on macOS Devboxes only. On bochka every machine has a 60fps Linux desktop with Chromium, plus Docker, systemd and /dev/kvm.
Agents you drive, keys kept outside
On Railway you shell each agent through exec with its API key inside the VM; on Namespace you sign up for a partner's agent service or write the glue yourself. bochka adds a prompt, steer and events API and a credentials proxy.
Use bochka when your agents work on Linux for hours or days: a full VM that keeps its disk, with no session cap, Docker and /dev/kvm, a 60fps desktop, and coding agents you drive from outside. Compare it one to one: bochka vs Railway and bochka vs Namespace.
Questions people ask
Is Railway cheaper than Namespace?
In the scenarios we priced, Railway's bill is lower, but it leaves out disk, which Railway does not price. One agent running all month comes to $70 on Railway against $176 on Namespace, and 50 agents in parallel to $739 against $2,198. bochka comes to $26 and $317 for the same two jobs.
Which is faster, Railway or Namespace?
We cannot say yet, because Railway has no result in StarSling's public benchmark. Namespace did 21.79 Node.js build-and-test runs per second at 4 vCPU / 8 GB and bochka did 26.69.
Can Railway or Namespace run Docker?
Namespace's Linux Devboxes include Docker, and its Linux compute instances have /dev/kvm. Railway's sandboxes give you a root shell on Ubuntu, but its sandbox docs do not mention Docker or nested virtualization. bochka has Docker, systemd and /dev/kvm on every machine.
How long can a sandbox run on Railway or Namespace?
A Railway sandbox runs until its idle timeout fires, 30 minutes of no activity by default, or until you destroy it if the timeout is 0. A Namespace Devbox is shut down after 4, 5 or 24 hours by plan, even while you work in it. bochka has no session cap on paid plans.
Does Railway or Namespace run macOS?
Only Namespace: it runs macOS Devboxes on Apple M4 Pro and M5 Max chips, and Windows machines on Team plans and up. Railway and bochka run Linux only, and bochka has Wine docs for Windows apps.
Is bochka SOC 2 compliant?
SOC 2 is in progress. We're open about where we stand: live status at status.bochka.xyz and our data retention policy at docs.bochka.xyz/data-retention. Railway's docs say it is SOC 2 Type II certified, and Namespace's trust center lists SOC 2 Type II.
Try bochka
Install the CLI, then run bochka new.
Product preview