Railway vs Beam
Railway is an app platform whose sandboxes are Linux VMs that can join the private network of your apps and databases, and that are destroyed when they go idle. Beam is a serverless GPU cloud whose sandboxes are gVisor containers by default, with GPUs, memory snapshots and a separate line of CPU VMs.
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.
Beam
Beam is a serverless cloud for GPU inference, sandboxes and background jobs, built on its open-source runtime Beta9.
Beam runs functions, REST endpoints, task queues, pods, sandboxes and VMs on CPUs and GPUs, all from a Python or TypeScript SDK. A sandbox is a container isolated with gVisor that starts in a second or two, lives until you terminate it or its time to live runs out, and can be saved as a filesystem image or a memory snapshot. Beam VMs are a separate CPU product: a microVM with its own kernel, systemd and a root disk that stays when it stops. Much of Beam is a GPU serverless platform for AI teams.
- Bring your own cloud
- Management fee per vCPU and GB of RAM, on top of your own cloud bill
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 | Beam: 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 | 69th of 367, with limits $551 a month | 3rd cheapest of 367 $634 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB Railway ranks 16th and fits fully, since an always-on assistant can run with the idle timeout set to 0 or as a Cloud Agent; Beam is only a compromise here, and bochka ranks 5th. | 16th cheapest of 366 $3,977 a month | 115th of 366, with limits $651 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 Beam ranks 8th: its sandboxes start in a second or two, bill per second and go away when their timer ends, while Railway ranks 36th. | 36th cheapest of 345 $413 a month | 8th cheapest of 345 $117 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 Beam ranks 3rd and bochka ranks 1st; Railway caps sandboxes per environment, 100 on Pro, so 300 user sandboxes at once need several environments. | 42nd of 361, with limits $290 a month | 3rd cheapest of 361 $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 | 78th of 360, with limits $4,450 a month | 341st of 360, with limits $939 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 Beam ranks 13th and bochka ranks 10th; Railway can fork running sandboxes for evals, but its per-environment cap keeps it a compromise. | 108th of 364, with limits $364 a month | 13th cheapest of 364 $251 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 Beam ranks 12th, with Docker inside sandboxes through docker_enabled, while Railway's sandbox docs do not mention Docker; bochka ranks 4th with Docker and /dev/kvm on every machine. | 113th cheapest of 377 $1,210 a month | 12th cheapest of 377 $171 a month | 4th cheapest of 377 $86 a month |
| 24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB Beam ranks 13th thanks to its CPU VMs that keep a 50 GiB root disk while stopped; Railway's Cloud Agents also keep a disk but are early access. | 66th cheapest of 368 $89 a month | 13th cheapest of 368 $21 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 Neither has a desktop: Railway sandboxes are headless and Beam has no browser or computer-use product, while bochka ranks 6th with a 60fps desktop. | 77th of 369, with limits $103 a month | 111th of 369, with limits $237 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 | 195th of 367, with limits $176 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 | 200th of 346, with limits $131 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 | 42nd of 338, with limits $923 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 | 175th of 360, with limits $155 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 Beam ranks 1st with GPUs from RTX 4090 to H100 and B200; Railway and bochka are CPU only. | Can't run it | Cheapest of 98 $458 a month | 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 | Railway | Beam | bochka |
|---|---|---|---|
| Isolation | Sandboxes are isolated Linux VMs; app services are containers | Sandboxes are gVisor containers by default; separate Beam VMs are CPU microVMs with their own kernel | Every sandbox is a full VM with its own kernel, on dedicated AMD Ryzen 9 9950X hosts |
| Nested virtualization | The sandbox docs do not mention /dev/kvm | Not documented | Yes, /dev/kvm for Android emulators and VMs |
| Docker and systemd | Root shell on Ubuntu; the sandbox docs do not mention Docker | Docker inside sandboxes with docker_enabled; systemd only in Beam VMs | Docker, systemd and root, like a normal Ubuntu server |
| When the sandbox goes idle | Destroyed after the idle timeout, 30 minutes by default, or never if set to 0 | Ends when its time to live runs out, 10 minutes by default, or never if set to -1 | No session cap on paid plans; you stop it, and a stopped sandbox costs nothing |
| Disk between runs | Files survive only in checkpoints you take | Save an image or use a volume; a Beam VM keeps a 50 GiB root disk while stopped | Disk saved every minute and on stop, and kept while stopped |
| Fork and snapshots | Fork a running sandbox's filesystem; disk checkpoints, no memory | Memory snapshot of a running sandbox with its processes, restored into new sandboxes | Fork a running sandbox with its disk; named snapshots to start new ones |
| GPUs | No | GPU sandboxes and serverless GPUs up to H100, H200 and B200 | No, CPU only |
| Desktop and computer use | Headless: terminal, exec and SSH only | No desktop or browser product | 60fps desktop with Chromium, computer use and browser control |
| Reaching the sandbox | Up to 10 public HTTPS domains, set only at creation; SSH and port forwarding | A public HTTPS URL per exposed port with no built-in auth; no raw TCP | HTTPS URLs for up to 50 ports, token-protected; raw TCP; dedicated IPv4 or IPv6 |
| Coding agents | Claude Code, Codex, OpenCode and Pi preinstalled; you run them headless through exec | None preinstalled; you install and run them through process exec | Claude Code, Codex and five more preinstalled, with a prompt, steer and events API |
| Keeping keys out of the sandbox | Secrets sit in the sandbox as environment variables, or in a checkpoint | Secrets are exposed as environment variables inside the sandbox | Credentials proxy for model providers and any HTTPS API; switch to another account when credits run out |
| Sandboxes at once | 50 per environment on Hobby, 100 on Pro | 30 CPU containers on Developer, 1,000 on Team | 100 to 2,000 by plan |
| Regions | US West, US East, Amsterdam and Singapore | US only; no other region is listed | EU only: Germany, Finland, France |
| Self-hosting | No | Beta9 runtime is AGPL-3.0 and free to self-host; bring your own cloud for a fee | No |
Every feature Battleships tracks (43)
| Feature | Railway | Beam | bochka |
|---|---|---|---|
| Full VM (own kernel) | Yes | No | Yes |
| Docker inside | Not published | Yes | Yes |
| Nested virtualization | No | No | Yes |
| Root | Yes | Yes | Yes |
| Systemd | Not published | No | Yes |
| Desktop GUI | No | No | Yes |
| Browser | Yes | No | Yes |
| Computer-use API | No | No | Yes |
| SSH | Yes | Yes | Yes |
| Persistent disk | Yes | Yes | Yes |
| Pause/resume | Yes | No | Yes |
| Automatic snapshots | No | No | Yes |
| Fork/clone | Yes | Yes | Yes |
| Live fork (no pause) | Yes | Yes | Yes |
| Memory fork | No | Yes | No |
| Custom image (Docker or snapshot) | Yes | Yes | Yes |
| ≥24 h sessions | Yes | Yes | Yes |
| Idle auto-stop | Yes | No | No |
| Wake on request | No | No | No |
| HTTPS preview URLs | Yes | Yes | Yes |
| Raw TCP inbound | No | No | Yes |
| Public IPv4 | No | No | No |
| Egress allowlist | No | Yes | No |
| Secret proxy | No | No | Yes |
| Secret proxy for any API | No | No | Yes |
| Preinstalled agents | Yes | No | Yes |
| Agent harness API | Yes | No | Yes |
| MCP server | Yes | Yes | No |
| GPU | No | Yes | No |
| Windows | No | No | No |
| Arm64 | No | No | No |
| Self-hosting | No | Yes | No |
| BYOC | Yes | Yes | No |
| Open source | No | Yes | No |
| Scoped API keys | Not published | Not published | Yes |
| Spend limits | Yes | Not published | Yes |
| Usage per sandbox (API) | No | No | Yes |
| Audit logs | Yes | Not published | No |
| SSO | Yes | No | No |
| SOC 2 | Yes | Yes | No |
| HIPAA | Yes | Yes | No |
| EU data residency | Yes | Not published | Yes |
| Zero data retention | Not published | Not published | Yes |
Performance
There is no comparable measurement for either: Railway and Beam have no result in StarSling's hpc-sandbox-benchmarks CPU test, so we cannot say which is faster. bochka did 26.69 Node.js build-and-test runs per second on that test at 4 vCPU / 8 GB. Beam's own guide says its sandboxes cold-boot in 1 to 3 seconds.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Railway and Beam 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.
| Scenario | Railway, a month | Beam, 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 | $5 · Developer | $20 · $20/mo |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $70 · Hobby · with limits | $22 · Developer | $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 | $410 · Team | $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 | $191 · Team | $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 | $259 · Team | $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.
Beam: Beam sandboxes bill per second for each CPU core (two vCPU) and GiB of RAM you request, until you terminate them or their time to live ends, with no egress fees. Developer has no fee; Team costs $89 a month plus usage, and the fee is not credit.
Beam: Plans start at $20 a month, and the whole fee is 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 publish a sandbox disk price; its cap of 100 sandboxes per environment on Pro means 300 user sandboxes or 1,000 jobs at once need several environments. Beam fits all five scenarios, but its Developer plan allows only 30 CPU containers at once, so 50 parallel agents need the Team plan. Neither publishes a disk price for sandboxes, so the bills here count no disk. 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 | Beam | 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 VM sandboxes on the same private network, with coding agents preinstalled, or you need regions in the US, EU or Asia.
- Sandboxes next to your apps. If your app already runs on Railway, a sandbox can join the same private network as your Postgres, Redis and services.
- Coding agents in the image. Railway sandboxes come with Claude Code, Codex, OpenCode and Pi preinstalled, while on Beam you install agents yourself.
- Regions in the US, EU and Asia. Railway runs in California, Virginia, Amsterdam and Singapore, while Beam lists only the United States.
Use Beam when
your work needs GPUs, when you want quick sandboxes that start in seconds with memory snapshots, when US hosting suits you, or when you must self-host.
- GPUs in the same platform. For work that needs a GPU, Beam offers GPU sandboxes and serverless GPUs from RTX 4090 up to H100, H200 and B200.
- Memory snapshots. Beam can snapshot a running sandbox with its processes and restore it into new sandboxes; Railway checkpoints hold the disk only.
- Open source and self-hosting. Beam's Beta9 runtime is AGPL-3.0 and free to self-host, and Beam can also run in your own cloud for a fee.
Where bochka fits
Railway and Beam both treat a sandbox as something that ends: Railway destroys it when idle, and a Beam sandbox ends with its time to live. If your agents work for hours or days, install tools, run Docker or an emulator, and need a browser, look at bochka. Each sandbox is a full VM that stops instead of disappearing and keeps its disk.
A disk that stays
A Railway sandbox is destroyed after 30 idle minutes by default, and a Beam sandbox ends after 10 minutes unless you change it. Turning that off keeps the machine, but memory or compute then bills until you destroy it.
Docker, /dev/kvm and a desktop
Railway's sandbox docs do not mention Docker or /dev/kvm, and Beam sandboxes have Docker but no systemd and no /dev/kvm. Neither has a desktop, so an agent that tests in a real browser or boots an Android emulator has nowhere to run.
Agents you drive from outside
Railway runs its preinstalled agents headless through exec, and Beam has none, so you parse output yourself. On both, API keys sit inside the sandbox as environment variables, where code the agent runs can read them.
Use bochka when your agents work for hours or days: a full VM that keeps its disk, with Docker, /dev/kvm, a desktop, hosting on 50 ports and coding agents you drive by API while their keys stay outside. Compare it one to one: bochka vs Railway and bochka vs Beam.
Questions people ask
Is Railway cheaper than Beam?
Not in these scenarios. Beam comes in lower in all five, such as $22 a month on Beam against $70 on Railway for one agent that never stops, and $410 on Beam against $739 on Railway for 50 agents in parallel. Neither price counts disk, which neither publishes for sandboxes.
Which is faster, Railway or Beam?
We cannot say. Neither has a result in StarSling's hpc-sandbox-benchmarks CPU test, where bochka did 26.69 runs per second at 4 vCPU / 8 GB. Beam's guide says its sandboxes cold-boot in 1 to 3 seconds.
Are Railway and Beam sandboxes VMs or containers?
Railway's docs call each sandbox an isolated Linux VM. Beam sandboxes are containers using runc and gVisor by default, with an opt-in microVM mode for CPU sandboxes and separate Beam VMs. Every bochka sandbox is a full VM with its own kernel.
Can Railway or Beam run Docker?
Beam supports Docker inside a sandbox with docker_enabled. Railway's sandbox docs give you a root shell on Ubuntu but do not mention Docker. bochka runs Docker, systemd and /dev/kvm on every machine.
What happens when a sandbox goes idle?
Railway destroys it after the idle timeout, 30 minutes by default, and only checkpoints you took survive. A Beam sandbox ends when its time to live runs out, 10 minutes by default, unless you saved an image or used a volume. A bochka sandbox stops instead and keeps its disk.
Do Railway or Beam have GPUs?
Beam does, with GPU sandboxes and serverless GPUs up to H100, H200 and B200. Railway sandboxes are CPU only, and so is bochka.
Try bochka
Install the CLI, then run bochka new.
Product preview