Railway vs Islo
Railway is an app platform that added sandbox VMs, which are destroyed when they go idle and sit next to your apps and databases. Islo is built only for agents: each one gets a microVM that can pause with its memory, behind a gateway that controls and logs every outbound call.
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.
Islo
Islo is an agent sandbox from Incredibuild: each coding agent gets its own microVM, with network rules and credentials handled at a gateway.
An Islo sandbox is a Linux microVM with its own kernel, built from a container image, with Claude Code, Cursor CLI and Codex preinstalled. Outbound traffic can pass through a gateway that allows or blocks hosts, injects credentials and logs every request. It is built for teams that run coding agents, evals and RL rollouts in the background, on Islo's cloud or in their own cloud account.
- Launched
- May 4, 2026
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 | Islo: price rank | bochka: price rank |
|---|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month Islo keeps a sandbox and runs Docker inside it, while a Railway sandbox is destroyed when idle; neither documents /dev/kvm or a desktop, which bochka has on every machine. | 51st of 367, with limits $342 a month | 326th of 367, with limits $7,402 a month | 3rd cheapest of 367 $634 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB All three fit: Railway needs the idle timeout set to 0 or a Cloud Agent, Islo can pause an idle assistant with its memory, and bochka keeps a full VM running with no session cap. | 16th cheapest of 366 $3,977 a month | 30th cheapest of 366 $9,928 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 fits short code runs best of the three: it bills for CPU used, destroys the sandbox when the job ends and publishes no limit on starts per minute. | 36th cheapest of 345 $413 a month | 153rd of 345, with limits $503 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 300 sandboxes for your users is more than Railway's 100 per environment on Pro and Islo's reported 50 on Team, while bochka allows up to 2,000 by plan. | 42nd of 361, with limits $290 a month | 171st of 361, with limits $3,160 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 | 167th of 360, with limits $15,265 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 Islo has a built-in Harbor integration and gateway rules that stop trials from looking up answers; Railway can fork a running sandbox; bochka runs evals on more sandboxes at once. | 108th of 364, with limits $364 a month | 198th of 364, with limits $2,456 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 Islo documents Docker inside its microVMs and Railway's sandbox docs do not mention it, so container builds are a known fit on Islo and on bochka. | 113th cheapest of 377 $1,210 a month | 119th cheapest of 377 $1,507 a month | 4th cheapest of 377 $86 a month |
| 24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB Railway's Cloud Agents keep a disk but are early access and fixed at 4 vCPU / 4 GB on Pro; Islo and bochka keep any sandbox running as long as you want. | 66th cheapest of 368 $89 a month | 112th cheapest of 368 $402 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 and Islo sandboxes are both headless, with no desktop or computer-use API, while bochka streams a 60fps desktop with Chromium that agents can see and click. | 77th of 369, with limits $103 a month | 310th of 369, with limits $2,210 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 | 113th of 367, with limits $1,105 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 | 66th cheapest of 346 $748 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 | 265th of 338, with limits $14,966 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 | 47th of 360, with limits $746 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 | Railway | Islo | bochka |
|---|---|---|---|
| Kind of product | App platform for web apps and databases, with sandboxes added in 2026 | Agent sandbox from Incredibuild, launched May 2026 | Sandboxes for agents: full VMs with a desktop and coding agents built in |
| Isolation | Sandboxes are isolated Linux VMs; app services are containers | Every sandbox is a microVM with its own kernel | Every sandbox is a full VM with its own kernel |
| When the sandbox goes idle | Destroyed after the idle timeout (30 minutes by default); files survive only in checkpoints you take | Can pause after a set idle time, keeping files, processes and memory, and resume on the next exec, file access or webhook | You stop it; the disk is kept, with snapshots every minute and on stop, and a stopped sandbox costs nothing |
| Docker and nested virtualization | Root shell on Ubuntu; the sandbox docs do not mention Docker or /dev/kvm | Docker inside and sudo; no /dev/kvm or nested virtualization documented | Docker, root, systemd and /dev/kvm on every machine |
| Desktop and computer use | Headless: terminal, exec and SSH only | A browser inside the sandbox for testing; no desktop or computer-use API | 60fps desktop and Chromium, computer use and browser control, embeddable stream |
| Fork and snapshots | Fork a running sandbox's filesystem; named disk checkpoints to boot new ones | Snapshot a running sandbox's files, then start new sandboxes from it | Fork a running sandbox; named snapshots to start new ones |
| Reaching the sandbox | Up to 10 public HTTPS domains, set only at creation; SSH and port forwarding | HTTPS share links anyone with the URL can open, expiring after 24 hours by default; SSH and port-forward through the CLI | HTTPS URLs for up to 50 ports, token-protected; raw TCP; its own IP |
| Outbound internet rules | Open internet; no provider-side egress allowlist | Gateway profiles allow or deny by host, path and HTTP method, with default deny, rate limits and per-request logs | Open internet on every plan; no provider-side allowlist |
| Keeping keys out of the sandbox | Secrets are baked into the sandbox as environment variables, or signed in and saved in a checkpoint | Gateway injects stored credentials into outbound requests for any host; credentials never reach the sandbox | AI credentials proxy for model providers and any HTTPS API you register; switch a credential to another account when credits run out |
| Coding agents | Claude Code, Codex, OpenCode and Pi preinstalled; you run them headless through exec | Claude Code, Cursor CLI and Codex preinstalled; factory lines run agent steps with events, steer and follow-ups | Claude Code, Codex, OpenCode and more preinstalled, with a prompt, steer and events API |
| Apps and databases next to the sandbox | Deploy Postgres, Redis and services in the same project; a sandbox can join their private network | Sandboxes only; no hosted databases or app services | No hosted databases or app services; host your own inside a sandbox |
| Sandboxes at once | 50 per environment on Hobby, 100 on Pro; Enterprise can ask for more | Free 5 and Team 50 running sandboxes per launch coverage; paused ones do not count | 100 to 2,000 running sandboxes by plan, raised by adding seats |
| Where it runs | US West, US East, Amsterdam and Singapore; new sandboxes start in US West | US West, or inside your own cloud account with BYOC | EU only: Germany, Finland, France; EU data residency and zero data retention |
| How it bills | Per second, on CPU actually used and memory in use; no published sandbox disk price | Per hour, on the cores, memory and disk you give a sandbox while it runs; no published egress price | Monthly plan from $20, all of it usage credit spent per second; a stopped sandbox costs nothing |
Every feature Battleships tracks (43)
| Feature | Railway | Islo | bochka |
|---|---|---|---|
| Full VM (own kernel) | Yes | Yes | Yes |
| Docker inside | Not published | Yes | Yes |
| Nested virtualization | No | No | Yes |
| Root | Yes | Yes | Yes |
| Systemd | Not published | Not published | Yes |
| Desktop GUI | No | No | Yes |
| Browser | Yes | Yes | Yes |
| Computer-use API | No | No | Yes |
| SSH | Yes | Yes | 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 | 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 | No | Yes | 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 | Yes | Yes |
| Secret proxy for any API | No | Yes | Yes |
| Preinstalled agents | Yes | Yes | Yes |
| Agent harness API | Yes | Yes | Yes |
| MCP server | Yes | No | No |
| GPU | No | No | No |
| Windows | No | No | No |
| Arm64 | No | No | No |
| Self-hosting | No | No | No |
| BYOC | Yes | Yes | No |
| Open source | No | No | No |
| Scoped API keys | Not published | Not published | Yes |
| Spend limits | Yes | Not published | Yes |
| Usage per sandbox (API) | No | Yes | Yes |
| Audit logs | Yes | Yes | No |
| SSO | Yes | Yes | No |
| SOC 2 | Yes | Not published | No |
| HIPAA | Yes | Not published | No |
| EU data residency | Yes | No | Yes |
| Zero data retention | Not published | Not published | Yes |
Performance
There is no comparable measurement for either: neither Railway nor Islo has a result in StarSling's public sandbox benchmark, so we cannot say which of the two is faster. In StarSling's run of 2026-09-29, bochka did 26.69 Node.js build-and-test runs per second at 4 vCPU / 8 GB on dedicated AMD Ryzen 9 9950X hosts.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Railway and Islo 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 | Islo, 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 | $101 · Free | $20 · $20/mo |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $70 · Hobby · with limits | $420 · Free | $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 | $4,863 · 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 | $1,382 · Team · 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 | $3,053 · Team · 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, 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 there is no published price for sandbox disk, so our bills leave disk out.
Islo: Islo bills each CPU core and each GB of memory and disk you give a sandbox while it runs, billed per hour, with no plan fee. An idle sandbox keeps billing until a pause-after-idle timer fires, which can only be set at creation, and egress has no published price.
Islo: 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 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. Its cap is 100 sandboxes per environment on Pro, and Islo's Team plan is reported at 50 running at once, so 300 sandboxes for your users and 1,000 short jobs at once fit neither without custom limits. An always-on agent on Railway also needs the idle timeout set to 0, or it is destroyed 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 | Railway | Islo | 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 short-lived sandboxes on the same private network, quick jobs billed on CPU used, or regions in the US and Asia.
- 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 it uses and is gone when the job ends.
- Regions in the US, EU and Asia. Useful if your users are spread out: Railway runs in California, Virginia, Amsterdam and Singapore.
Use Islo when
your agents must stay behind per-host egress rules with a log of every outbound call, should pause with memory and wake on request, or must run in your own cloud account.
- Egress rules and request logs. Useful if you must control what agents reach: Islo allows or blocks each host, path and method, and logs every call.
- Pause with memory, wake on request. Useful for agents that sit idle between tasks: Islo pauses them with memory kept and resumes on the next request.
- Docker inside and keys at the gateway. Useful for coding agents that build containers: Islo runs Docker in its microVMs and keeps credentials outside them.
Where bochka fits
Railway and Islo both give agents a headless Linux VM. If your agents need a screen, nested virtualization, ports you can host on, or hundreds of sandboxes at once, look at bochka: every sandbox is a full VM that keeps its disk across stops, with a desktop and coding agents you drive from outside.
A desktop agents can see and use
Railway sandboxes and Islo sandboxes are both headless, with no desktop or computer-use API. An agent that checks a UI or fills a form in a real app needs a screen, so on either you install a VNC stack and a control layer in every image yourself.
Docker, systemd and /dev/kvm
Railway's sandbox docs do not mention Docker, and neither Railway nor Islo documents /dev/kvm. Android emulators, Firecracker or a VM of the agent's own stop at the first boot, and software emulation runs many times slower.
Ports and scale for real work
Railway sets at most 10 HTTPS domains at creation and Islo share links expire after 24 hours by default, with no raw TCP on either. bochka serves 50 token-protected ports plus raw TCP, and runs up to 2,000 sandboxes against their 100 and 50.
Use bochka when your agents need more than a shell: a full VM that keeps its disk, a 60fps desktop for computer use, Docker and /dev/kvm, ports you can host on, and up to 2,000 sandboxes at once in the EU. Compare it one to one: bochka vs Railway and bochka vs Islo.
Questions people ask
Is Railway cheaper than Islo?
In our scenarios, yes, though Railway's totals leave out disk, which it does not price. One agent running all month comes to $70 on Railway and $420 on Islo, and 50 agents in parallel come to $739 versus $4,863. bochka comes to $26 and $317 for the same two jobs.
Which is faster, Railway or Islo?
We cannot say: neither has a result in StarSling's public sandbox benchmark. bochka did 26.69 Node.js build-and-test runs per second at 4 vCPU / 8 GB in that benchmark.
Can Railway or Islo sandboxes run Docker?
Islo documents Docker inside its microVMs. Railway's sandbox docs give you a root shell on Ubuntu but do not mention Docker. bochka has 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 keeps only the checkpoints you took. Islo can pause it with files, processes and memory kept and wake it on the next request. bochka stops it, keeps the disk and charges nothing while it is stopped.
Do Railway or Islo have a desktop for computer use?
No. Both are headless: Railway gives you a terminal, exec and SSH, and Islo has a browser for testing but no screen or computer-use API. bochka streams a 60fps desktop with Chromium and has a computer-use API on every sandbox.
Where do Railway and Islo run?
Railway has regions in California, Virginia, Amsterdam and Singapore. Islo runs in US West, or inside your own cloud account with BYOC. bochka runs only in the EU (Germany, Finland and France), with EU data residency.
Try bochka
Install the CLI, then run bochka new.
Product preview