Railway vs Koyeb
Both are app platforms that now sell sandboxes as VMs. A Railway sandbox is destroyed when it goes idle and keeps files only in checkpoints you take, while a Koyeb sandbox can sleep, wake on the next request and run on a GPU.
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.
Koyeb
Koyeb is a serverless cloud for apps, inference and sandboxes, and in February 2026 it agreed to join Mistral AI.
A Koyeb sandbox is a Koyeb service: a microVM started from any Docker image and driven from Python or JavaScript SDKs that run commands, read files and expose a port. It can scale to zero when idle and wake on the next request, and it can run on CPU or GPU instance types. It is built for teams that run AI agents or untrusted code next to apps they already host on Koyeb.
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 | Koyeb: price rank | bochka: price rank |
|---|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month Neither keeps a sandbox's disk by default: Railway destroys idle sandboxes and Koyeb loses local disk on redeploy, while bochka keeps the disk and saves it every minute. | 51st of 367, with limits $342 a month | 54th of 367, with limits $366 a month | 3rd cheapest of 367 $634 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB Railway fits an always-on assistant if you set the idle timeout to 0, while a Koyeb deep sleep throws away the VM and its files. | 16th cheapest of 366 $3,977 a month | 135th of 366, with limits $923 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 Both fit short code runs; Koyeb's small instances and scale to zero make it the stronger pick here, and Railway bills only for CPU used. | 36th cheapest of 345 $413 a month | 4th cheapest of 345 $66 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 Koyeb fits sandboxes for your users and wakes them on request, while Railway caps Pro at 100 sandboxes per environment. | 42nd of 361, with limits $290 a month | 6th cheapest of 361 $495 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 | 237th of 360, with limits $1,631 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 Railway can fork a running sandbox but caps how many run per environment; Koyeb fits, and bochka forks running sandboxes with up to 2,000 at once. | 108th of 364, with limits $364 a month | 19th cheapest of 364 $429 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 that builds Android apps or VM images needs /dev/kvm, which bochka exposes and neither Railway nor Koyeb documents. | 113th cheapest of 377 $1,210 a month | 142nd of 377, with limits $88 a month | 4th cheapest of 377 $86 a month |
| 24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB | 66th cheapest of 368 $89 a month | 217th of 368, with limits $37 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 Computer-use agents need a desktop; Railway and Koyeb sandboxes are headless, and bochka streams a 60fps desktop with Chromium. | 77th of 369, with limits $103 a month | 81st of 369, with limits $123 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 | 172nd of 367, with limits $123 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 | 172nd of 346, with limits $89 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 | 65th of 338, with limits $1,683 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 | 233rd of 360, with limits $299 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 Koyeb runs GPU instances from RTX 4000 cards up to H100 and H200, and neither Railway nor bochka has GPUs. | Can't run it | 3rd cheapest of 98 $628 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 | Koyeb | bochka |
|---|---|---|---|
| Isolation | Sandboxes are isolated Linux VMs; app services are containers | MicroVM per instance | Full VM with its own kernel on dedicated AMD Ryzen 9 9950X hosts |
| When the sandbox goes idle | Destroyed after the idle timeout (30 minutes by default, or never if set to 0) | Scales to zero after at least 5 idle minutes and wakes on the next request; Light Sleep wakes in about 200 ms | You stop it; the disk is kept and a stopped sandbox costs nothing |
| Files that survive | Only in disk checkpoints you take before the sandbox is destroyed | Local disk is lost on redeploy; volumes (preview, 1 to 10 GB, two regions) persist | Disk kept across stops, saved every minute and on stop |
| Fork and snapshots | Fork a running sandbox's filesystem; boot new ones from named checkpoints | SDK snapshots of the filesystem or with running processes, then new sandboxes from them (experimental) | Fork a running sandbox; named snapshots to start new ones |
| Docker and nested virtualization | Root shell on Ubuntu; the sandbox docs do not mention Docker or /dev/kvm | Starts from any Docker image; nested virtualization not documented | Docker, root, systemd and /dev/kvm on every machine |
| Reaching the sandbox | Up to 10 public HTTPS domains, set only at creation; SSH and port forwarding | One exposed HTTPS port at a time, plus an optional TCP proxy to one port | HTTPS URLs for up to 50 ports, token-protected; raw TCP; dedicated IPv6 or IPv4 |
| Outbound rules | Open internet | Block all outbound traffic, or allow only listed IPs and CIDRs | Open internet, no provider-side allowlist |
| Coding agents | Claude Code, Codex, OpenCode and Pi preinstalled; you run them headless through exec | Tutorials that run agents through the command API; an MCP server lets agents manage Koyeb | Seven agents preinstalled, with a prompt, steer and events API |
| Keeping API keys out of the sandbox | Secrets go in as environment variables or a signed-in checkpoint | Secrets are set as environment variables inside the service | AI credentials proxy for model providers and any HTTPS API; switch a credential to another account when credits run out |
| Desktop and computer use | Headless: terminal, exec and SSH only | No desktop or browser in the sandbox SDK | 60fps Linux desktop with Chromium, computer use and browser control |
| GPUs | No | RTX 4000 SFF Ada up to H100, H200 and multi-GPU | No |
| Apps and databases next to the sandbox | Postgres, Redis and services in the same project; a sandbox can join their private network | Apps and inference run as Koyeb services on the same platform | No hosted databases or app services; host your own inside a sandbox |
| Biggest machine | 8 vCPU / 8 GB on Hobby, 32 vCPU / 32 GB on Pro | Instance types up to 40 vCPU / 128 GB, and GPU types far larger | 8 vCPU / 16 GB on the $20 plan, 16 vCPU / 32 GB from $100 |
| Regions | California, Virginia, Amsterdam and Singapore | Frankfurt, Paris, Washington D.C., AWS US East, Singapore, Tokyo, plus San Francisco in preview | EU only: Germany, Finland, France |
Every feature Battleships tracks (43)
| Feature | Railway | Koyeb | bochka |
|---|---|---|---|
| Full VM (own kernel) | Yes | Yes | Yes |
| Docker inside | Not published | Yes | Yes |
| Nested virtualization | No | No | Yes |
| Root | Yes | Not published | Yes |
| Systemd | Not published | Not published | Yes |
| Desktop GUI | No | No | Yes |
| Browser | Yes | No | Yes |
| Computer-use API | No | No | Yes |
| SSH | Yes | No | Yes |
| Persistent disk | Yes | Yes | Yes |
| Pause/resume | Yes | Yes | Yes |
| Automatic snapshots | No | Yes | Yes |
| Fork/clone | Yes | Yes | Yes |
| Live fork (no pause) | Yes | Not published | Yes |
| Memory fork | No | Yes | No |
| Custom image (Docker or snapshot) | Yes | Yes | Yes |
| ≥24 h sessions | Yes | Yes | Yes |
| Idle auto-stop | Yes | Yes | No |
| Wake on request | No | Yes | No |
| HTTPS preview URLs | Yes | Yes | Yes |
| Raw TCP inbound | No | Yes | 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 | Yes | 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 | No | No |
| Scoped API keys | Not published | Not published | Yes |
| Spend limits | Yes | No | Yes |
| Usage per sandbox (API) | No | No | Yes |
| Audit logs | Yes | Yes | No |
| SSO | Yes | Yes | No |
| SOC 2 | Yes | Yes | No |
| HIPAA | Yes | No | No |
| EU data residency | Yes | Yes | Yes |
| Zero data retention | Not published | Not published | Yes |
Performance
There is no comparable measurement for Railway or Koyeb: neither was part of StarSling's hpc-sandbox-benchmarks run. bochka did 26.69 Node.js build-and-test runs per second at 4 vCPU / 8 GB in that benchmark. Koyeb publishes a CPU share of at least 0.25 dedicated vCPU per GB of memory, bursting to all cores, so its speed depends on how busy the host is.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Railway and Koyeb 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 | Koyeb, 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 | $29 · Pro | $20 · $20/mo |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $70 · Hobby · with limits | $57 · Pro | $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 | $475 · Pro | $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 | $329 · Scale | $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 | $485 · Scale · 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. The Hobby ($5) and Pro ($20) fees count toward usage, and sandbox disk has no published price, so our bills leave it out.
Koyeb: Koyeb bills each instance per second at a fixed price per instance type, and Deep Sleep costs nothing. Pro costs $29 a month with $10 of usage included and Scale $299 with $100 included; the rest of the fee is not credit.
Koyeb: Plans start at $20 a month, and the whole fee is usage credit spent per second while a sandbox runs. A stopped sandbox costs nothing and keeps its disk.
Limits in those scenarios
Railway is marked as a different kind of product in every scenario, and its bills count CPU and memory only because it does not price sandbox disk. It caps sandboxes per environment, 50 on Hobby and 100 on Pro, so 300 user sandboxes or 1,000 jobs at once need several environments. Koyeb's priced eco-xlarge shape has a 20 GiB disk with no published price for more, and eco instances guarantee only half of each vCPU, so it throttles in the 1,000-job burst. bochka's $2,000 plan queues that burst above 90 starts a minute, so none of the three fits it as priced.
| Scenario | Railway | Koyeb | bochka |
|---|---|---|---|
| One coding agent, workdays |
|
| None that bite |
| One agent that never stops |
|
| None that bite |
| 50 agents in parallel |
| None that bite | None that bite |
| Sandboxes for your users |
| None that bite | 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.
- 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.
- Bills for CPU actually used. Useful for agents that mostly wait: Railway meters sandbox CPU on what it uses, though memory keeps billing.
- SSH and a forkable running sandbox. Useful when you want to shell in and branch work: Railway offers SSH and forks a running sandbox's filesystem.
Use Koyeb when
your sandboxes need GPUs, sleep most of the time and must wake on a request, or need outbound traffic locked down.
- GPUs on the same platform. Useful when an agent or eval needs a GPU: Koyeb runs instances from RTX 4000 cards up to H100 and H200.
- Sleep when idle, wake on request. Good for sandboxes that sit idle between requests: Koyeb scales to zero and wakes on the next one.
- Outbound rules and more regions. Koyeb can block or allowlist outbound traffic by IP, and runs in Europe, the US and Asia.
Where bochka fits
Railway and Koyeb are app platforms first, and their sandboxes are built to come and go. If what you are running is agents that work for hours or days, bochka gives each one a full VM that keeps its disk, with Docker, a desktop and coding agents you drive from outside.
A disk that stays when the agent waits
A Railway sandbox is destroyed after 30 idle minutes by default, and a Koyeb deep sleep discards the VM. Keeping files means checkpoints, preview volumes or staying awake and paying; bochka keeps the disk and a stopped sandbox costs nothing.
Docker, /dev/kvm and a desktop
Neither Railway nor Koyeb documents /dev/kvm, and both are headless. An agent that boots an Android emulator or tests in a real browser needs another machine there; bochka has root, systemd, Docker, /dev/kvm and a 60fps desktop.
Agents you drive, keys kept outside
On both, you run agents through exec and parse output yourself, and API keys sit inside as environment variables the agent can read. bochka adds a prompt, steer and events API and a credentials proxy for any HTTPS API.
Use bochka when your agents do real work for hours on a machine that keeps its disk: builds, Docker, emulators, a desktop browser and preview servers, with agents and keys handled for you. Compare it one to one: bochka vs Railway and bochka vs Koyeb.
Questions people ask
Is Railway cheaper than Koyeb?
It depends on the job. Railway is lower for one agent on workdays ($16 against $29) and for sandboxes for your users ($223 against $329), but its numbers leave out disk. Koyeb is lower for one agent that never stops ($57 against $70) and for 50 agents in parallel ($475 against $739). bochka comes to $26 and $317 for those two.
Which is faster, Railway or Koyeb?
We cannot say: neither has a result in StarSling's public CPU benchmark yet. bochka did 26.69 runs per second there at 4 vCPU / 8 GB. Koyeb guarantees at least 0.25 dedicated vCPU per GB of memory and bursts above that.
What happens to an idle sandbox on Railway and on Koyeb?
Railway destroys it once the idle timeout runs out, 30 minutes by default, so you take a checkpoint first to keep files. Koyeb scales it to zero and wakes it on the next request, but a deep sleep discards the VM and its local disk. A bochka sandbox stops, keeps its disk and costs nothing while stopped.
Can Railway or Koyeb sandboxes run Docker and Android emulators?
Railway's sandbox docs do not mention Docker or /dev/kvm. Koyeb starts sandboxes from Docker images but does not document nested virtualization. bochka runs Docker inside every sandbox with root and systemd, and exposes /dev/kvm for emulators and VMs.
Does either have GPUs?
Koyeb does, from an RTX 4000 SFF Ada up to H100 and H200, billed per second. Railway sandboxes and bochka are CPU only.
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.
Try bochka
Install the CLI, then run bochka new.
Product preview