Runloop vs Railway
Runloop is built for AI coding agents, with devboxes that can suspend, wake on a request and lock down their network. Railway is a platform for apps and databases, and its sandboxes are VMs that are destroyed when they go idle.
The companies and products
Runloop
Runloop is a US platform of sandboxes, called devboxes, for building, running and testing AI coding agents.
You get Linux devboxes built from Dockerfile-style blueprints, disk snapshots, HTTPS tunnels, agent gateways that hide API keys, and Axons, event streams that drive agents such as Claude Code. Each devbox runs in a micro-VM on Runloop's own bare-metal hypervisor, with a container layer inside. It is built for teams shipping coding agents, plus evaluation and RL fine-tuning work on the Enterprise plan.
- Compliance
- SOC 2 Type 2
- Architectures
- x86_64 and arm64 base blueprints
- Own-cloud deploy
- Deploy to VPC on AWS, GCP and Azure (Enterprise)
- Regions
- Not documented or selectable
- Company
- Runloop AI, Inc.
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.
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. “20th cheapest of 367” means 19 of the other 366 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 | Runloop: price rank | Railway: price rank | bochka: price rank |
|---|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month Runloop fits a software factory fully, while Railway is a compromise because its sandboxes are destroyed when idle; bochka ranks 3rd and keeps the disk on every plan. | 20th cheapest of 367 $8,152 a month | 51st of 367, with limits $342 a month | 3rd cheapest of 367 $634 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB Railway ranks above Runloop for always-on assistants, with the idle timeout set to 0 or a Cloud Agent, and bochka ranks 5th. | 32nd cheapest of 366 $10,194 a month | 16th cheapest of 366 $3,977 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 a little above Runloop for short code runs because it bills for CPU used, and both rank above bochka, whose start limits queue very large bursts. | 44th cheapest of 345 $525 a month | 36th cheapest of 345 $413 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 allows 100 sandboxes per environment on Pro, so 300 at once means several environments; Runloop fits fully, and bochka ranks 1st. | 26th cheapest of 361 $3,301 a month | 42nd of 361, with limits $290 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 Runloop ranks 4th for RL rollouts, starting large waves with no published start limits, while Railway's per-environment caps make it a compromise. | 4th cheapest of 360 $15,922 a month | 78th of 360, with limits $4,450 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 | 81st cheapest of 364 $2,562 a month | 108th of 364, with limits $364 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 Runloop documents on its Docker-in-Docker blueprints and Railway's sandbox docs do not mention; bochka ranks 4th. | 121st cheapest of 377 $1,554 a month | 113th cheapest of 377 $1,210 a month | 4th cheapest of 377 $86 a month |
| 24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB Railway ranks above Runloop for 24/7 dev boxes, though its Cloud Agents are early access, and Runloop has no public IP or raw TCP. | 113th cheapest of 368 $410 a month | 66th cheapest of 368 $89 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 Runloop ships a desktop and a browser your agent can control, while Railway sandboxes are headless; bochka streams its desktop at 60fps. | 39th cheapest of 369 $2,306 a month | 77th of 369, with limits $103 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 | 40th cheapest of 367 $1,153 a month | 53rd of 367, with limits $93 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 | 68th cheapest of 346 $781 a month | 60th cheapest of 346 $570 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 | 266th of 338, with limits $15,611 a month | 109th of 338, with limits $2,988 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 | 10th cheapest of 360 $770 a month | 43rd of 360, with limits $574 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 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 | Can't run it | Can't run it | Can't run it |
Key features
| Feature | Runloop | Railway | bochka |
|---|---|---|---|
| Kind of product | Sandboxes for AI coding agents, called devboxes | App platform for services and databases, with sandboxes added in 2026 | Sandboxes for AI agents, each a full Linux VM |
| Isolation | Micro-VM on a custom bare-metal hypervisor, plus a container layer | Sandboxes are isolated Linux VMs; app services are containers | Full VM with its own kernel on dedicated AMD Ryzen 9 9950X hosts |
| Docker and nested virtualization | Docker on the Docker-in-Docker blueprints, as root; nested virtualization not documented | Root shell on Ubuntu; the sandbox docs do not mention Docker or /dev/kvm | Docker, root, systemd and /dev/kvm on every machine |
| When the sandbox goes idle | Suspend after idle and wake on an HTTP request (Pro), or shut down, which ends the devbox | Destroyed after the idle timeout, 30 minutes by default, or never if set to 0 | You stop it; the disk is kept and a stopped sandbox costs nothing |
| Keeping files | Disk kept through suspend (Pro) or disk snapshots you take | Files survive only in checkpoints you take | Snapshot every minute and on stop, on every plan; resume with the same disk |
| Long runs | Lifetime 1 hour by default, 48 hours max; an idle policy replaces that cap | No documented maximum lifetime while the sandbox is active | No session cap on paid plans; default TTL 1 hour, changeable |
| Images | Blueprints built from Dockerfiles, plus disk snapshots; x86_64 and arm64 | Templates built from ordered steps (apt packages, env, commands) and cached | Templates from named snapshots; x86_64 only |
| Reaching the sandbox | One HTTPS tunnel per devbox; SSH through a TLS proxy; no public IP | Up to 10 public HTTPS domains, set only at creation; SSH and port forwarding | HTTPS URLs for up to 50 ports, token-protected; raw TCP; dedicated IPv6 or IPv4 |
| Egress rules | Hostname allowlist with wildcards, or block all | No egress allowlist for sandboxes documented | Open internet, no provider-side allowlist |
| Keeping keys out of the sandbox | Agent gateways for any API endpoint with bearer, header or basic auth | Secrets go in as environment variables, or are signed in and saved in a checkpoint | Credentials proxy for model providers and any HTTPS API; switch a credential to another account when credits run out |
| Coding agents | Claude Code, Codex, OpenCode, Gemini CLI, DeepAgents, driven through Axons and Broker | Claude Code, Codex, OpenCode and Pi preinstalled; you run them headless through exec | Claude Code, Codex, OpenCode and more, with a prompt, steer and events API |
| Desktop and computer use | Desktop and browser your agent can control | Headless: terminal, exec and SSH only | 60fps desktop and Chromium, computer use and browser control, embeddable stream |
| Where it runs | Regions not documented; deploy into your own AWS, GCP or Azure (Enterprise) | US West, US East, Amsterdam and Singapore | EU only (Germany, Finland, France), EU data residency |
Every feature Battleships tracks (43)
| Feature | Runloop | Railway | bochka |
|---|---|---|---|
| Full VM (own kernel) | Yes | Yes | Yes |
| Docker inside | Yes | Not published | Yes |
| Nested virtualization | No | No | Yes |
| Root | Yes | Yes | Yes |
| Systemd | Not published | Not published | Yes |
| Desktop GUI | Yes | No | Yes |
| Browser | Yes | Yes | Yes |
| Computer-use API | Yes | No | Yes |
| SSH | Yes | Yes | Yes |
| Persistent disk | Yes | Yes | Yes |
| Pause/resume | Yes | Yes | Yes |
| Automatic snapshots | Yes | No | Yes |
| Fork/clone | Yes | Yes | Yes |
| Live fork (no pause) | Yes | Yes | 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 | Yes | No | No |
| HTTPS preview URLs | Yes | Yes | Yes |
| Raw TCP inbound | No | No | Yes |
| Public IPv4 | No | No | No |
| Egress allowlist | Yes | No | No |
| Secret proxy | Yes | No | Yes |
| Secret proxy for any API | Yes | No | Yes |
| Preinstalled agents | Yes | Yes | Yes |
| Agent harness API | Yes | Yes | Yes |
| MCP server | Yes | Yes | No |
| GPU | No | No | No |
| Windows | No | No | No |
| Arm64 | Yes | No | No |
| Self-hosting | No | No | No |
| BYOC | Yes | Yes | No |
| Open source | No | No | No |
| Scoped API keys | Yes | Not published | Yes |
| Spend limits | Not published | Yes | Yes |
| Usage per sandbox (API) | No | No | Yes |
| Audit logs | Not published | Yes | No |
| SSO | Yes | Yes | No |
| SOC 2 | Yes | Yes | No |
| HIPAA | Not published | Yes | No |
| EU data residency | No | Yes | Yes |
| Zero data retention | Not published | Not published | Yes |
Performance
On the StarSling hpc-sandbox-benchmarks Node.js build-and-test loop at 4 vCPU / 8 GB (run 36498291449, 2026-09-29), bochka scored 26.69 runs a second and Runloop 8.29, about 3.2 times apart. Railway has no result in that benchmark, so there is no comparable measurement for it. The test measures CPU work only, not start time or network speed.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. 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 | Runloop, a month | Railway, 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 | $113 · Basic | $16 · Hobby · with limits | $20 · $20/mo |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $429 · Basic | $70 · Hobby · 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 | $5,268 · Basic | $739 · Hobby · with limits | $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 | $1,441 · Basic | $223 · Pro · 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 | $3,184 · Basic | $781 · Pro · with limits | $2,000 · $2000/mo · with limits |
Runloop: Runloop bills per second for the CPU and memory you allocate, including while a devbox starts, suspends or resumes, and bills its disk for the devbox's whole life. Basic has no plan fee; Pro adds $250 a month that is not usage credit and unlocks suspend and resume.
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 Railway publishes no price for sandbox disk or checkpoints.
Limits in those scenarios
Railway is marked as not a clean fit in every scenario, because it is an app platform first and publishes no sandbox disk price, so its bills count CPU and memory only. It caps sandboxes per environment, 50 on Hobby and 100 on Pro, which 300 user sandboxes or 1,000 jobs at once go past. Runloop fits every scenario but publishes no egress price, and its fixed lifetime tops out at 48 hours unless an idle policy replaces it. bochka's 1,000-job burst does not fit: even the $2,000 plan queues bursts above 90 starts a minute.
| Scenario | Runloop | Railway | 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 Runloop when
you ship coding agents and want devboxes that can sleep and wake, hostname allowlists, arm64, or very large waves of short jobs.
- Built around coding agents. Useful if you ship coding agents: devboxes come with agent gateways that hide API keys and Axons that drive agents.
- Lock down the network. Useful if a sandbox must only reach a fixed list of hosts: Runloop allows listed hostnames, with wildcards, or blocks everything.
- Sleep, wake and arm64. Useful for idle devboxes and arm64 builds: Runloop can suspend and wake on a request (Pro), and builds images from Dockerfiles.
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.
- 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.
- Regions in the US and Asia. Useful if your users or data are in the US or Asia: Railway runs in California, Virginia, Amsterdam and Singapore.
Where bochka fits
If your agents work for hours, installing, building and testing, look at bochka. Each sandbox is a full VM that keeps its disk when it stops, with Docker, /dev/kvm and a desktop, on CPUs that ran about three times faster than Runloop's in the same benchmark.
A disk that stays when work pauses
A Railway sandbox is destroyed after 30 idle minutes by default, and a Runloop devbox is gone once it shuts down. Keeping work means checkpoints you take by hand, or Runloop's $250-a-month Pro plan for suspend.
A fuller machine to work in
Without /dev/kvm an Android emulator or a VM does not start on either. Railway's sandbox docs do not mention Docker, and neither gives a public IP or raw TCP, so a server that speaks raw TCP has no way in.
Faster CPUs and agents you drive from outside
Runloop ran 8.29 build-and-test loops a second against bochka's 26.69, so every wait takes about three times as long. On Railway you shell each agent through exec and its API key sits inside the VM.
Use bochka when your agents work for hours or days: a full VM that keeps its disk, with Docker, /dev/kvm, a desktop and CPUs about three times faster than Runloop's. Compare it one to one: bochka vs Runloop and bochka vs Railway.
Questions people ask
Is Runloop cheaper than Railway?
No, Railway's bills are lower in every one of our scenarios: one agent running all month is $70 on Railway and $429 on Runloop, and 50 agents in parallel are $739 versus $5,268. But Railway's numbers leave out disk, which it does not price. On bochka the same two cost $26 and $317.
Which is faster, Runloop or Railway?
We cannot say. Runloop scored 8.29 runs a second on the StarSling Node.js build-and-test benchmark at 4 vCPU / 8 GB, but Railway has no result in it. bochka scored 26.69 on the same test.
Can Runloop or Railway run Docker?
Runloop documents Docker-in-Docker blueprints that run as root. Railway's sandbox docs do not mention Docker, so it is not confirmed there. bochka runs Docker, systemd and /dev/kvm on every machine.
What happens to my files when the sandbox goes idle?
Railway destroys an idle sandbox after 30 minutes by default, so files survive only in checkpoints you take. Runloop keeps the disk if the devbox suspends, which needs the Pro plan, or in disk snapshots. A bochka sandbox stops, keeps its disk and costs nothing while stopped.
Do Runloop or Railway have a desktop for computer use?
Runloop ships a desktop and a browser your agent can control. Railway sandboxes are headless, with only a terminal, exec and SSH. bochka streams a 60fps desktop that you can embed in your app.
Where do Runloop and Railway run?
Railway has regions in California, Virginia, Amsterdam and Singapore. Runloop does not document its regions, but its Enterprise plan deploys into your own AWS, GCP or Azure account. bochka runs only in the EU, in Germany, Finland and France.
Try bochka
Install the CLI, then run bochka new.
Product preview