Railway Runs Your Agents Now: What Cloud Agents on 24/7 VMs Cost vs a Self-Hosted Sandbox

You used to rent the server. Now you rent the loop. Railway's Cloud Agents put the coding harness itself — Claude Code, Codex, OpenCode — on always-on VMs you launch from the dashboard, switch from the terminal with railway ca, and resume from your phone, with the Railway MCP server in every session so the agent can open PRs or spin up services mid-run. It is the logical endpoint of the PaaS pitch: not just "we run your app" but "we run the thing that writes your app."

The question is what that costs, and what it locks in. An always-on 4 vCPU / 16 GB agent VM on Railway's usage rates runs about $245 a month. The same harness in a sandbox on a slice of a Hetzner box you own runs about $19. That 13x gap is real, but it is also the least interesting number in this post — because the meter, the UX, and the lock-in all pull in different directions. Let's price all three honestly.

The number: ~$245/mo per always-on agent vs ~$19 on owned iron​

Start with the meter, because Railway's is public and per-second: $0.00000772 per vCPU-second, $0.00000386 per GB-second of memory, and $0.00000006 per GB-second of storage, on top of a $20/mo Pro plan. A typical coding-agent VM — 4 vCPUs, 16 GB RAM, 10 GB disk, running 730 hours a month — works out to roughly $81 in CPU, $162 in memory, and $1.60 in disk. Call it $245 a month per always-on agent, before the plan fee it shares with your other services.

Stack that against the alternatives for the same 4/16 shape:

Two honesty notes before anyone screenshots the table. First, utilization is the whole game on Railway. The CLI docs are explicit: disconnecting leaves the VM running and billing continues, but railway ca sleep stops compute while keeping the disk. An agent that works 8 hours a day on workdays (~176 hours a month) and sleeps the rest costs roughly $60 instead of $245 — a 4x swing from one command. If you adopt Cloud Agents and don't build the sleep habit (or automate it), you are donating the difference.

Second, LLM tokens dwarf every row in this table. A full-time coding agent burns through model API spend that makes a $245 VM look like a rounding error — the sandbox industry's own rule of thumb is that compute is negligible next to tokens. Infra price decides nothing by itself; it only matters at the margin, multiplied by agents, over months. The real comparison is workflow and lock-in, which is where the rest of this post lives.

What railway ca actually gives you​

The Cloud Agents surface, pieced together from the CLI docs and the August–September changelogs, is three commands and a phone app. railway code --claude (or --codex, --opencode, --grok) spins up a fresh VM with that harness installed and connects a local client to it. railway ca manages the fleet: ssh in, name terminal sessions, sleep an agent to stop the meter, delete it to drop the VM and disk together. Saved bootstraps — configured VM images — mean a new agent starts from your toolchain, not a blank box.

Then there is the part no self-hosted setup matches today without real work: MCP-in-session. Every agent session carries the Railway MCP server, recently moved to the hosted mcp.railway.com endpoint authenticated through your existing CLI login. The tool list reads like a deploy runbook — deploy, deploy-template, environment management, variable pulls, redeploys — so the agent doesn't generate commands for you to paste; it operates the infrastructure directly, governed by whatever scoping the MCP layer enforces. September's changelog #0308 added the other half: Railway Sandboxes are GA on every plan, letting you run, checkpoint, and fork ephemeral Linux VMs next to your Railway infrastructure from an SDK — the programmatic cousin of the interactive Cloud Agent.

And the phone. Railway shipped a native iOS app in June 2026, and Cloud Agent sessions are resumable from it — the "your laptop cycles should be preserved" pitch made literal. Approve a plan from the train, check a deploy from the couch. It is easy to sneer at phone-as-terminal until you've babysat a long agent run from anywhere else.

What's genuinely ahead (and what you'd have to build)​

Credit where due: three pieces of this are ahead of what a Firecracker-on-Hetzner self-hosted sandbox offers today, and each has a concrete build cost if you want it yourself.

Session continuity across devices. Railway's agent abstraction — named VMs, named terminal sessions, --resume to pick up the last Claude conversation after a sleep — means "my agent" survives laptop closes, network changes, and device switches. Self-hosted equivalent: tmux-over-Tailscale gets you 70% there in an afternoon; the last 30% (sleep/wake billing semantics, conversation resume across restarts) is weeks of fiddly state management.

The deploy loop closed inside the session. An agent that can deploy to the same platform mid-run collapses write→ship into one loop with no human paste step. Self-hosted equivalent: expose your own deploy API as MCP tools — very buildable (a weekend for deploy/logs/redeploy over an existing API), but you now maintain a tool catalog with auth scoping instead of consuming one, and every new capability is your roadmap.

One-command reproducible images. Bootstraps make "fresh agent with my stack" a saved artifact rather than a setup script you hope still works. Self-hosted equivalent: Nix images or versioned VM snapshots — arguably better engineering, but you own the image pipeline, the registry, and the garbage collection.

None of this is magic; all of it is maintenance. Railway's edge is that the maintenance is someone else's. And that company just raised $100M to be the "AI-native cloud," undercutting hyperscalers by roughly half on raw usage — the agent bet is the strategy, not a side quest.

The lock-in shape: agent, state, and target on one vendor's VMs​

Here is the part to name plainly. With Cloud Agents, the agent, its session state, and the deploy target all live on one vendor's VMs. Your conversation history, your terminal sessions, your bootstrap images, and the MCP tool surface that can touch production are Railway-scoped artifacts. The MCP tools deploy to Railway projects. The bootstraps boot Railway VMs. The sleep/wake semantics bill on Railway's meter.

Exiting means re-homing all four at once: export or abandon session state, rebuild images as Dockerfiles or Nix expressions, rewire deploy tools against a new API, and move the workloads themselves. No single piece is technically hard — that's what makes this lock-in shape sneaky. Each exit is a weekend; all four at once, under time pressure, with agents mid-flight, is a migration project. Contrast the self-hosted shape: your harness config is a repo, your images are OCI artifacts in a registry you chose, your deploy tools speak your API. The switching cost is distributed instead of concentrated.

This isn't an argument that Railway will abuse the position — it's an argument that the position exists and should be priced. The 13x infra multiple is the visible cost. The concentrated exit is the hidden one. Teams that adopt Cloud Agents should do it the way they'd adopt any platform with state gravity: keep workload definitions portable (Railway's own railway.json/railway.toml travel better than dashboard clicks), keep the deploy path reproducible outside the agent, and know which bootstrap contents you'd need to reconstruct on day one elsewhere.

Rent the loop vs own the sandbox: a decision rule​

So who should do what? Three cases cover most teams:

• Solo dev or small team, agents as accelerators. Rent the loop. A slept-when-idle Cloud Agent at ~$60/mo plus token spend is cheaper than your time building session continuity, bootstrap pipelines, and MCP tooling — and the phone-resume UX genuinely changes how you supervise long runs. Just automate ca sleep.
• Team already running a fleet on owned hardware. Own the sandbox. If you have Hetzner capacity and someone who can run Firecracker or gVisor sandboxes, the marginal cost per agent is ~$19/mo and the state stays in your registry, your images, your API. Spend the savings on the one genuinely hard piece: governed deploy tools for your agents.
• Regulated, air-gapped, or agent-state-is-sensitive. Own the sandbox, no contest. Conversation history containing proprietary code and production credentials should not transit a third party's session infrastructure when you have the option — and auditors will ask exactly where agent state rests.

The deeper trend is bigger than one vendor: the PaaS boundary is moving up the stack from "your app" to "your builder." Railway got there with Cloud Agents and Sandboxes; others will follow. Whoever hosts your agent loop holds your sessions, your images, and your deploy path — so pick that host the way you'd pick any foundation: price the meter, test the exit, and keep the portable parts portable.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. If your agent loop is going to live somewhere, it might as well live on infrastructure you can inspect. Star the repo on GitHub or deploy your first app today.