Railway vs exe.dev

Railway is an app platform whose sandboxes are short-lived Linux VMs, destroyed when they sit idle. exe.dev rents Linux VMs with root, Docker and SSH that keep running and keep their disk until you stop them.

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.

exe.dev

exe.dev, made by Bold Software, Inc., rents Linux VMs for developers and AI agents that you reach over SSH and HTTPS.

You reserve a pool of vCPUs and memory, and your VMs share it; you can also start standalone VMs billed by the second. Each VM is KVM-isolated (they use Cloud Hypervisor), boots from a container image in about two seconds, and has root, systemd and Docker. It comes with Claude Code, Codex, Pi and exe.dev's own Shelley agent, and is aimed at developers who want a persistent dev box or a sandbox for their agents.

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 workloadRailway: price rankexe.dev: price rankbochka: price rank
Software factory
100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month
A software factory needs machines that keep their work; Railway destroys idle sandboxes and exe.dev has no snapshots, while bochka ranks 3rd with both a disk that stays and snapshots every minute.
51st of 367, with limits
$342 a month
253rd of 367, with limits
$3,701 a month
3rd cheapest of 367
$634 a month
Always-on AI employees
50 machines 24/7 · 2 vCPU / 4 GB
Always-on assistants fit on both, with exe.dev ranks 15th and Railway ranks 16th; on Railway you set the idle timeout to 0 or use a Cloud Agent.
16th cheapest of 366
$3,977 a month
15th cheapest of 366
$3,833 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 ranks 36th for short code runs because a sandbox bills for CPU used and is gone when the job ends; exe.dev pools bill whether jobs run or not.
36th cheapest of 345
$413 a month
235th of 345, with limits
$175 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
Neither fits 300 sandboxes for your users at once on the plans priced: Railway caps 100 per environment on Pro and exe.dev Personal stops at 50 VMs; bochka ranks 1st.
42nd of 361, with limits
$290 a month
257th of 361, with limits
$1,226 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
265th of 360, with limits
$5,250 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
283rd of 364, with limits
$1,050 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
CI jobs that build containers need Docker, which exe.dev and bochka document and Railway's sandbox docs do not mention.
113th cheapest of 377
$1,210 a month
288th of 377, with limits
$504 a month
4th cheapest of 377
$86 a month
24/7 dev boxes
1 machine 24/7 · 4 vCPU / 8 GB
exe.dev is the better 24/7 dev box of the two: a VM with root, SSH and a disk that lasts, where Railway's Cloud Agents are still early access.
66th cheapest of 368
$89 a month
25th cheapest of 368
$35 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
Railway sandboxes and exe.dev VMs are both headless, so computer-use agents have no screen on either; bochka streams a 60fps desktop.
77th of 369, with limits
$103 a month
240th of 369, with limits
$1,055 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
On both Railway and exe.dev you install and run a headless browser yourself; bochka gives agents a visible Chromium and browser control.
53rd of 367, with limits
$93 a month
130th of 367, with limits
$530 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
124th of 346, with limits
$278 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
166th of 338, with limits
$5,490 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
60th of 360, with limits
$263 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
Can't run itCan't run itCan't run it
macOS agents
5 at once · 4 vCPU / 8 GB · 1,000 sessions of 20 min a month
Can't run itCan't run itCan't run it

Key features

FeatureRailwayexe.devbochka
Kind of productApp platform for services and databases, with sandbox VMs added in 2026Linux VMs for developers and AI agents, reached over SSH and HTTPSVM sandboxes built for AI agents
IsolationSandboxes are isolated Linux VMs; app services are containersKVM VMs using Cloud Hypervisor; you can't choose the kernelFull VM with its own kernel on dedicated AMD Ryzen 9 9950X hosts
When the machine goes idleDestroyed after the idle timeout (30 minutes by default); files survive only in checkpoints you takeKeeps running until you stop it; the disk persists and is streamed to a second serverYou stop it; the disk is kept, and a stopped sandbox costs nothing
Snapshots and forkFork a running sandbox's filesystem; named disk checkpoints to boot new onesNo snapshots; cp copies a VM's disk and config into a new VMSnapshots every minute and on stop; fork a running sandbox; named snapshots as templates
Docker and nested virtualizationRoot shell on Ubuntu; the sandbox docs do not mention Docker or /dev/kvmRoot, systemd and Docker; nested virtualization on Enterprise onlyDocker, root, systemd and /dev/kvm on every machine
Custom imagesTemplates built from ordered steps (apt packages, env, commands) and cachedBoot each VM from your own Docker imageTemplates from named snapshots; no Dockerfile or OCI images
Coding agentsClaude Code, Codex, OpenCode and Pi preinstalled; you run them headless through execClaude Code, Codex, Pi and Shelley; only Shelley takes prompts through the APISeven agents preinstalled, with one API to prompt, steer and stream events, plus TypeScript and Python SDKs
Keeping keys out of the machineSecrets go into the sandbox as environment variables, or are saved in a checkpointIntegrations inject secrets at the network edge for any HTTP hostCredentials proxy for model providers and any HTTPS API; switch to another account when credits run out
Reaching the machineUp to 10 public HTTPS domains, set only at creation; SSH and port forwardingHTTPS proxy for ports 3000 to 9999, one of them public; SSH; no public IP or raw TCPHTTPS URLs for up to 50 ports, token-protected; raw TCP; dedicated IPv6 or IPv4
Desktop and computer useHeadless: terminal, exec and SSH onlyHeadless; no desktop or screen streaming60fps desktop and Chromium, computer use and browser control, embeddable stream
Apps and databases next to itDeploy Postgres, Redis and services in the same project; a sandbox can join their private networkVMs only; you run your own services inside a VMNo hosted databases or app services; host your own inside a sandbox
Biggest machine8 vCPU / 8 GB on Hobby, 32 vCPU / 32 GB on ProPersonal pools up to 16 vCPU; standalone VMs capped at 2 GiB of memory per vCPU8 vCPU / 16 GB on the $20 plan, 16 vCPU / 32 GB from $100
Machines at once50 per environment on Hobby, 100 on Pro; Enterprise can ask for more50 VMs on Personal, plus up to 50 standalone VMs100 to 2,000 by plan
RegionsUS West, US East, Amsterdam and Singapore9 regions in the US, Europe, Asia and AustraliaEU only: Germany, Finland, France
Every feature Battleships tracks (43)
FeatureRailwayexe.devbochka
Full VM (own kernel)YesYesYes
Docker insideNot publishedYesYes
Nested virtualizationNoYesYes
RootYesYesYes
SystemdNot publishedYesYes
Desktop GUINoNoYes
BrowserYesYesYes
Computer-use APINoNoYes
SSHYesYesYes
Persistent diskYesYesYes
Pause/resumeYesYesYes
Automatic snapshotsNoNoYes
Fork/cloneYesYesYes
Live fork (no pause)YesYesYes
Memory forkNoNoNo
Custom image (Docker or snapshot)YesYesYes
≥24 h sessionsYesYesYes
Idle auto-stopYesNoNo
Wake on requestNoNoNo
HTTPS preview URLsYesYesYes
Raw TCP inboundNoNoYes
Public IPv4NoNoNo
Egress allowlistNoNoNo
Secret proxyNoYesYes
Secret proxy for any APINoYesYes
Preinstalled agentsYesYesYes
Agent harness APIYesYesYes
MCP serverYesYesNo
GPUNoNoNo
WindowsNoNoNo
Arm64NoNoNo
Self-hostingNoNoNo
BYOCYesYesNo
Open sourceNoNoNo
Scoped API keysNot publishedYesYes
Spend limitsYesNot publishedYes
Usage per sandbox (API)NoYesYes
Audit logsYesNot publishedNo
SSOYesYesNo
SOC 2YesNoNo
HIPAAYesNoNo
EU data residencyYesYesYes
Zero data retentionNot publishedNot publishedYes

Performance

RailwayNot measured
exe.devNot measured
bochka26.69 runs/s

Neither Railway nor exe.dev is in the hpc-sandbox-benchmarks run, so there is no comparable CPU measurement for either of them. bochka did 26.69 Node.js build-and-test runs per second at 4 vCPU / 8 GB in StarSling's public benchmark. We don't guess how the other two would score.

Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Railway and exe.dev have 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.

ScenarioRailway, a monthexe.dev, a monthbochka, 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$35 · Personal$20 · $20/mo
One agent that never stops
4 vCPU / 8 GB, 50 GB disk, running 24/7 all month
$70 · Hobby · with limits$35 · Personal$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$1,848 · Personal$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$530 · Personal · with limits$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$1,050 · Personal · with limits$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, which keeps billing while a sandbox waits, plus $0.05 per GB out. The Hobby ($5) and Pro ($20) fees count toward usage, and Railway does not publish a price for sandbox disk, so our bills leave disk out.

exe.dev: exe.dev Personal is a flat pool paid monthly, from $15 for 2 vCPU / 4 GB to $155 for 16 vCPU, and it bills the same whether VMs are busy or idle. Standalone VMs bill per second at $0.105 per 2 vCPU / 4 GiB hour, and Work is $75 a month for a whole team plus extra capacity by the hour.

exe.dev: 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 marks every scenario as not a clean fit because it is an app platform first and does not price sandbox disk, and it caps sandboxes at 50 per environment on Hobby and 100 on Pro. exe.dev Personal allows one pool of up to 16 vCPU and 50 VMs, plus up to 50 standalone VMs. So neither fits 300 sandboxes for your users or 1,000 short jobs at once on the plans priced. On bochka, the 1,000-job burst is queued above 90 starts a minute and needs more starts per day than the top plan allows.

ScenarioRailwayexe.devbochka
One coding agent, workdays
  • different kind of product: app platform
  • disk beyond 0 GiB: price unknown
  • flat pool: the tier is billed whether used or not
None that bite
One agent that never stops
  • different kind of product: app platform
  • disk beyond 0 GiB: price unknown
  • flat pool: the tier is billed whether used or not
None that bite
50 agents in parallel
  • not confirmed: Docker inside
  • different kind of product: app platform
  • disk beyond 0 GiB: price unknown
None that biteNone that bite
Sandboxes for your users
  • Pro: max 100 concurrent
  • different kind of product: app platform
  • disk beyond 0 GiB: price unknown
  • Personal: max 50 concurrent
None that bite
1,000 short jobs at once
  • Pro: max 100 concurrent
  • different kind of product: app platform
  • disk beyond 0 GiB: price unknown
  • Personal: max 50 concurrent
  • max 2,400 starts/day (needs ~6,667)
  • max 600 starts/hour (needs ~1,000)
  • bursts above 90 starts/min are queued (a burst of 333 takes ~4 min to start)

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, billed for the CPU they use.

  • Your apps and databases in one place. Useful if your app already runs on Railway: sandboxes can join the same private network as your Postgres and services.
  • Short jobs that bill for CPU used. Useful for many quick code runs: a Railway sandbox bills for CPU actually used and is gone when the job ends.
  • Bigger machines. Useful for heavy jobs: Railway Pro sandboxes go up to 32 vCPU / 32 GB.

Use exe.dev when

you want a Linux VM that stays up like a dev box, booted from your own Docker image, in a region near you.

  • A VM that stays. Useful for a long-lived dev box: an exe.dev VM keeps running with root, systemd and Docker until you stop it.
  • Regions around the world. Useful if your users are far from Europe: exe.dev runs in nine regions across the US, Europe, Asia and Australia.
  • Your own Docker image. Useful if your setup lives in a Dockerfile: exe.dev can boot each VM straight from your own image.

Where bochka fits

If what you are really running is AI agents that work for hours, both choices leave gaps: Railway throws idle machines away, and exe.dev keeps them but has no snapshots or screen. bochka gives each agent a full VM that keeps its disk, saves it every minute, shows a desktop, and lets your app drive agents inside from outside.

A disk that stays and rolls back

Railway destroys a sandbox after 30 idle minutes by default, and turning that off means memory bills until you destroy it. exe.dev keeps the disk but has no snapshots, so one bad agent step can cost a session's work.

A screen your agents can use

Railway sandboxes and exe.dev VMs are both headless, so an agent that must check a UI or click through a web app has nothing to look at unless you set up and stream a desktop yourself.

Drive agents inside from outside

On Railway you run each agent through exec, parse its output and leave its key in an environment variable. On exe.dev only Shelley takes prompts by API, so Claude Code or Codex means scripting shell sessions.

Use bochka when your agents work for hours or days: a full VM that keeps its disk with a snapshot every minute, Docker and /dev/kvm, a desktop, and one API to drive agents inside from outside. Compare it one to one: bochka vs Railway and bochka vs exe.dev.

Questions people ask

Is Railway cheaper than exe.dev?

In our scenarios Railway is lower for most loads: one agent on workdays is $16 against $35, and 50 agents in parallel are $739 against $1,848 on exe.dev. exe.dev is lower for one agent that never stops, $35 against $70. Railway's bills leave out disk, which it does not price, and bochka comes to $20, $317 and $26 for those three.

Which is faster, Railway or exe.dev?

We can't say. Neither is in the hpc-sandbox-benchmarks run, so there is no comparable CPU measurement. bochka scored 26.69 Node.js build-and-test runs per second at 4 vCPU / 8 GB in that benchmark.

Can Railway or exe.dev run Docker?

exe.dev VMs come with root, systemd and Docker, and nested virtualization on Enterprise. Railway's sandbox docs give a root shell on Ubuntu but do not mention Docker or /dev/kvm. bochka has Docker and /dev/kvm on every machine.

Do my files survive when the machine is idle?

On Railway, no: an idle sandbox is destroyed after its timeout, 30 minutes by default, and only checkpoints you took survive. On exe.dev, yes: a VM keeps its disk until you delete it, though there are no snapshots. bochka keeps the disk and snapshots it every minute and on stop.

Do Railway and exe.dev have coding agents?

Both preinstall Claude Code, Codex and Pi. Railway adds OpenCode and runs them headless through exec; exe.dev adds its own Shelley agent, the only one that takes prompts by API. bochka preinstalls seven agents and lets you prompt, steer and watch any of them through one API.

Where do Railway and exe.dev run?

Railway runs in California, Virginia, Amsterdam and Singapore. exe.dev has nine regions across the US, Europe, Asia and Australia. bochka runs only in the EU, in Germany, Finland and France, with EU data residency.

Try bochka

Install the CLI, then run bochka new.

Product preview

More comparisons

Bochka product preview · Pricing, benchmarks and commands are illustrative. Sandbox provisioning is not connected.