bochka vs Railway
Railway is a platform for deploying apps and databases, and its sandboxes are Linux VMs that are destroyed when they go idle. bochka gives each agent a full VM that stops instead of disappearing, saves its disk every minute, and comes with a desktop and coding agents you drive from outside.
Where bochka stands out
A disk that stays
A bochka sandbox stops instead of disappearing. Its disk is saved every minute and on stop, and a stopped sandbox costs nothing until you resume it. A Railway sandbox is destroyed when its idle timeout runs out, and only the checkpoints you took by hand survive.
Coding agents you drive from outside
Both put Claude Code and Codex in the image. bochka adds a prompt, steer and events API, so your app can start an agent, correct it mid-task and stream what it does. Its credentials proxy keeps real AI keys outside the sandbox and can switch to another account when one runs out of credits.
A desktop, Docker and KVM
Every bochka sandbox has a 60fps desktop with Chromium and computer use, plus root, systemd, Docker and /dev/kvm. Railway sandboxes are headless, and their docs do not mention Docker or nested virtualization.
The companies and products
bochka
bochka.xyz runs sandboxes for AI agents: each one is a full Linux VM with its own kernel.
You start a machine with one command or one API call, then SSH in, run Docker, open a desktop, or let a built-in agent (Claude Code, Codex, OpenCode and others) work in it. The disk stays between sessions, and a stopped sandbox costs nothing.
- Isolation
- Full VM per sandbox, own kernel
- Regions
- EU: Germany, Finland, France
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. “3rd cheapest of 367” means 2 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 | bochka: price rank | Railway: 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 between runs; Railway sandboxes are destroyed when idle, so you save state yourself with checkpoints. | 3rd cheapest of 367 $634 a month | 51st of 367, with limits $342 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB Both fit; on Railway an always-on assistant means setting the idle timeout to 0 or using a Cloud Agent, and memory bills the whole time either way. | 5th cheapest of 366 $657 a month | 16th cheapest of 366 $3,977 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 better: a sandbox bills for CPU used, is destroyed when the job ends, and has no published starts-per-minute limit. | 186th of 345, with limits $2,000 a month | 36th cheapest of 345 $413 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 sandboxes for your users mean several environments or an Enterprise limit. | Cheapest of 361 $209 a month | 42nd of 361, with limits $290 a month |
| RL rollouts 1,000 at once · 2 vCPU / 4 GB · 1,000,000 sessions of 3 min a month | 34th of 360, with limits $2,000 a month | 78th of 360, with limits $4,450 a month |
| Agent evals 250 at once · 4 vCPU / 8 GB · 15,000 sessions of 20 min a month Railway can fork a running sandbox and boot many from one checkpoint, but each environment caps how many run at once. | 10th cheapest of 364 $200 a month | 108th of 364, with limits $364 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 bochka documents on every machine and Railway's sandbox docs do not mention. | 4th cheapest of 377 $86 a month | 113th cheapest of 377 $1,210 a month |
| 24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB Railway's Cloud Agents keep a disk and can sleep and wake, but they are early access and fixed at 4 vCPU / 4 GB on Pro. | 18th cheapest of 368 $26 a month | 66th cheapest of 368 $89 a month |
| Computer-use agents 50 at once · 4 vCPU / 8 GB · 20,000 sessions of 15 min a month Railway sandboxes are headless, with no desktop to stream or drive, so computer-use agents fit only as a compromise there. | 6th cheapest of 369 $200 a month | 77th of 369, with limits $103 a month |
| Browser-use agents 50 at once · 2 vCPU / 4 GB · 30,000 sessions of 10 min a month | 7th cheapest of 367 $200 a month | 53rd of 367, with limits $93 a month |
| Scraping & bots (startup scale) 50 at once · 1 vCPU / 2 GB · 100,000 sessions of 3 min a month | 6th cheapest of 346 $90 a month | 60th cheapest of 346 $570 a month |
| Mass scraping & bots (undetectable) 1,000 at once · 1 vCPU / 2 GB · 3,000,000 sessions of 2 min a month | 71st of 338, with limits $1,800 a month | 109th of 338, with limits $2,988 a month |
| Parallel red teaming 200 at once · 2 vCPU / 4 GB · 5,000 sessions of 30 min a month | 2nd cheapest of 360 $200 a month | 43rd of 360, with limits $574 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 |
| 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 |
Key features
| Feature | bochka | Railway |
|---|---|---|
| Isolation | Every sandbox is a full VM with its own kernel | Sandboxes are isolated Linux VMs; app services are containers |
| When the sandbox goes idle | You stop it; the disk is kept, with snapshots every minute and on stop, and a stopped sandbox costs nothing | Destroyed after the idle timeout (30 minutes by default); files survive only in checkpoints you take |
| Docker and nested virtualization | Docker, root, systemd and /dev/kvm on every machine | Root shell on Ubuntu; the sandbox docs do not mention Docker or /dev/kvm |
| Fork and checkpoints | Fork a running sandbox; named snapshots to start new ones (disk only, no memory) | Fork a running sandbox's filesystem; named disk checkpoints to boot new ones (no memory) |
| Base images | Named snapshots (templates), shareable by code | Templates built from ordered steps (apt packages, env, commands) and cached |
| Reaching the sandbox | HTTPS URLs for up to 50 ports, token-protected; raw TCP; dedicated IPv6 or IPv4 | Up to 10 public HTTPS domains, set only at creation; SSH and port forwarding |
| Coding agents | Claude Code, Codex, OpenCode and more preinstalled, with a prompt, steer and events API | Claude Code, Codex, OpenCode and Pi preinstalled; you run them headless through exec |
| Keeping keys out of the sandbox | AI credentials proxy for model providers and any HTTPS API you register; switch a credential to another account when credits run out | Secrets are baked into the sandbox as environment variables, or signed in and saved in a checkpoint |
| Desktop and computer use | 60fps desktop and Chromium, computer use and browser control, embeddable stream | Headless: terminal, exec and SSH only |
| Long-lived dev machine | Any sandbox can run for weeks and stop or resume with its disk | Cloud Agents keep a disk and sleep or wake; early access, fixed at 4 vCPU / 4 GB on Pro, 25 created per user per day |
| Apps and databases next to the sandbox | No hosted databases or app services; host your own inside a sandbox | Deploy Postgres, Redis and services in the same project; a sandbox can join their private network |
| Biggest sandbox | 8 vCPU / 16 GB on the $20 plan, 16 vCPU / 32 GB from $100 | 8 vCPU / 8 GB on Hobby, 32 vCPU / 32 GB on Pro |
| Sandboxes at once | 100 to 2,000 by plan | 50 per environment on Hobby, 100 on Pro; Enterprise can ask for more |
| Regions | EU only: Germany, Finland, France | US West, US East, Amsterdam and Singapore; new sandboxes start in US West unless you pick a region |
| Compliance and transparency | SOC 2 is in progress. We're open about where we stand: live status and data retention policy. | SOC 2 |
Every feature Battleships tracks (43)
| Feature | bochka | Railway |
|---|---|---|
| Full VM (own kernel) | Yes | Yes |
| Docker inside | Yes | Not published |
| Nested virtualization | Yes | No |
| Root | Yes | Yes |
| Systemd | Yes | Not published |
| Desktop GUI | Yes | No |
| Browser | Yes | Yes |
| Computer-use API | Yes | No |
| SSH | Yes | Yes |
| Persistent disk | Yes | Yes |
| Pause/resume | Yes | Yes |
| Automatic snapshots | Yes | No |
| Fork/clone | Yes | Yes |
| Live fork (no pause) | Yes | Yes |
| Memory fork | No | No |
| Custom image (Docker or snapshot) | Yes | Yes |
| ≥24 h sessions | Yes | Yes |
| Idle auto-stop | No | Yes |
| Wake on request | No | No |
| HTTPS preview URLs | Yes | Yes |
| Raw TCP inbound | Yes | No |
| Public IPv4 | No | No |
| Egress allowlist | No | No |
| Secret proxy | Yes | No |
| Secret proxy for any API | Yes | No |
| Preinstalled agents | Yes | Yes |
| Agent harness API | Yes | Yes |
| MCP server | No | Yes |
| GPU | No | No |
| Windows | No | No |
| Arm64 | No | No |
| Self-hosting | No | No |
| BYOC | No | Yes |
| Open source | No | No |
| Scoped API keys | Yes | Not published |
| Spend limits | Yes | Yes |
| Usage per sandbox (API) | Yes | No |
| Audit logs | No | Yes |
| SSO | No | Yes |
| SOC 2 | No | Yes |
| HIPAA | No | Yes |
| EU data residency | Yes | Yes |
| Zero data retention | Yes | Not published |
Performance
There is no comparable measurement. bochka did 26.69 Node.js build-and-test runs per second at 4 vCPU / 8 GB in StarSling's public benchmark, but Railway has no result in that benchmark yet, so we cannot say which is faster.
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 | bochka, a month | Railway, 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 | $20 · $20/mo | $16 · Hobby · with limits |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $26 · $20/mo | $70 · Hobby · with limits |
| 50 agents in parallel 50 machines of 4 vCPU / 8 GB at once, 8-hour sessions, 1,100 sessions a month, Docker inside | $317 · $20/mo × 3 seats | $739 · Hobby · with limits |
| Sandboxes for your users 2 vCPU / 4 GB, 30,000 sessions of 10 minutes a month, up to 300 at once | $200 · $100/mo × 2 seats | $223 · Pro · with limits |
| 1,000 short jobs at once 2 vCPU / 4 GB, 1,000 at once, 3 minutes each, 200,000 jobs a month | $2,000 · $2000/mo · with limits | $781 · Pro · with limits |
bochka: 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.
Railway: Railway bills sandboxes per second at $50 per vCPU-month on CPU actually used and $50 per GB-month on memory in use, including the operating system and file cache, plus $0.05 per GB out. Memory keeps billing while a sandbox waits, until it is destroyed. The Hobby ($5) and Pro ($20 per workspace) fees count toward usage, and Railway does not publish a price for sandbox disk or checkpoints, so our bills leave disk out.
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, so its bills here count CPU and memory only. Its cap is per environment: 50 sandboxes on Hobby and 100 on Pro, so 300 sandboxes for your users or 1,000 jobs at once need several environments or an Enterprise limit. An always-on agent also needs the idle timeout set to 0, or Railway destroys it after 30 minutes without activity. 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 | bochka | Railway |
|---|---|---|
| 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.
- 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.
- 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.
- Short jobs that bill for CPU used. Useful for many quick code runs: a Railway sandbox bills for CPU used and is gone when the job ends.
Use bochka when
your agents work for hours or days: a full VM that keeps its disk, with Docker, a desktop, and coding agents you drive by API while their keys stay outside.
- A disk that stays. An agent that waits on a slow review past Railway's 30 minute default loses its installs and half-done work. Turning the timeout off keeps it, but memory then bills until you destroy it.
- Coding agents you drive from outside. On Railway you shell each agent through exec and parse its output yourself, and its API key sits inside the VM as an environment variable, where code the agent runs can read it.
- A desktop, Docker and KVM. An agent that tests a web app in a real browser, runs docker compose or boots an Android emulator needs those pieces. On Railway you would have to install and verify them yourself, with no screen to watch.
Questions people ask
Is bochka cheaper than Railway?
It depends on the job. One agent running all month comes to $26 on bochka and $70 on Railway, 50 agents in parallel come to $317 versus $739, and sandboxes for your users come to $200 versus $223. Railway is lower for one agent on workdays ($16 against $20) and for 1,000 short jobs at once ($781 against $2,000), and its numbers leave out disk, which it does not price.
Are Railway sandboxes VMs or containers?
Railway's docs call each sandbox a fully isolated virtual machine on an Ubuntu base. Its regular app services are non-privileged containers. On bochka, every sandbox is a full VM too.
What happens to a Railway sandbox when it goes idle?
Railway destroys it once the idle timeout runs out, 30 minutes by default on Hobby and Pro (1 to 120 minutes, or 0 for never), and 5 minutes at most on Trial and Free. To keep files you take a checkpoint first and boot a new sandbox from it. A bochka sandbox stops instead, keeps its disk and costs nothing while stopped.
Do Railway sandboxes have coding agents?
Yes. The default image includes Claude Code, Codex, OpenCode and Pi, and you run them in headless mode through exec. Railway's Cloud Agents, in early access, add terminal sessions you reattach to. bochka also preinstalls coding agents and lets you prompt, steer and watch them through an API.
Where does my data run?
bochka runs only in the EU (Germany, Finland and France), with EU data residency and a zero data retention option. Railway has regions in California, Virginia, Amsterdam and Singapore, and new sandboxes start in US West unless you choose a region in the SDK or API.
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 and SOC 3 certified.
Start a sandbox
Install the CLI, then run bochka new.
Product preview
More comparisons
- bochka vs E2B
- bochka vs Daytona
- bochka vs Modal
- bochka vs Vercel Sandbox
- bochka vs Blaxel
- bochka vs Runloop
- bochka vs Tensorlake
- bochka vs Cloudflare Sandbox
- bochka vs exe.dev
- bochka vs Agent 37
- bochka vs Oracle Cloud
- bochka vs IONOS Cloud
- E2B vs Railway
- Daytona vs Railway
- Modal vs Railway
- Vercel Sandbox vs Railway
- Cloudflare Sandbox vs Railway
- Blaxel vs Railway
- Runloop vs Railway
- Tensorlake vs Railway