Sprites vs Railway
Sprites gives each agent a persistent Fly.io microVM that sleeps when idle and wakes on the next request. Railway is an app platform whose sandboxes are short-lived VMs, destroyed after an idle timeout, that can sit on the same private network as your apps and databases.
The companies and products
Sprites
Sprites is Fly.io's product for agents: persistent Linux computers you create by API or CLI, which sleep when idle and wake on the next request.
Each Sprite is a Firecracker microVM with 8 vCPU, memory the platform manages, and a 100 GB ext4 disk that syncs to object storage. It runs one managed Ubuntu image with Claude Code, Codex, Gemini CLI and Cursor preinstalled, gets an HTTPS URL that wakes it, and bills only for the CPU and memory it actually uses while awake. It is built for coding agents, dev environments and user code that sit idle most of the time.
- Isolation
- Firecracker microVM per Sprite
- Regions
- Not selectable for Sprites
- Free start
- $30 trial credit per organization
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. “63rd cheapest of 377” means 62 of the other 376 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 | Sprites: 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 Sprites keeps its disk between runs, while a Railway sandbox is destroyed when idle; bochka keeps the disk and adds systemd, /dev/kvm and up to 50 public ports. | 66th of 367, with limits $546 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 fits an always-on assistant if you set the idle timeout to 0, while a Sprite pauses and drops open connections unless a task holds it awake; bochka just keeps running. | 157th of 366, with limits $1,166 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 Both beat bochka here: Sprites and Railway bill CPU actually used on short runs, while bochka limits how many sandboxes start per minute and per day. | 93rd of 345, with limits $140 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 caps sandboxes at 100 per environment on Pro and Sprites does not publish a pay-as-you-go cap, so 300 at once is unconfirmed on both; bochka fits it. | 56th of 361, with limits $428 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 | 105th of 360, with limits $6,540 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 Railway can fork a running sandbox and Sprites cannot; bochka forks too, with no session cap on paid plans. | 125th of 364, with limits $545 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 Both fit CI, but Sprites has Docker with rough edges and Railway's sandbox docs do not mention Docker; bochka documents Docker and /dev/kvm on every machine. | 63rd cheapest of 377 $476 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's Cloud Agents keep a disk but are early access; a Sprite is cheap when idle but has no systemd and no direct SSH, while bochka has both. | 213th of 368, with limits $27 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 Sprites and Railway are both headless, so computer-use agents need a desktop you build yourself; bochka streams a 60fps desktop with Chromium. | 85th of 369, with limits $136 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 | 171st of 367, with limits $122 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 | 229th of 346, with limits $206 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 | 141st of 338, with limits $4,113 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 | 210th of 360, with limits $223 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 | Sprites | Railway | bochka |
|---|---|---|---|
| Kind of product | Fly.io's product for agents: persistent Linux computers made by API or CLI | App platform for services and databases, with sandboxes added in 2026 | Sandboxes for agents: a full Linux VM per sandbox |
| Isolation | Firecracker microVM with its own kernel | Sandboxes are isolated Linux VMs; app services are containers | Full VM with its own kernel on dedicated AMD Ryzen 9 9950X hosts |
| When it goes idle | Pauses about 30 seconds after work stops and wakes on the next request, disk kept | Destroyed after the idle timeout (30 minutes by default); files survive only in checkpoints you take | Runs until you stop it; disk saved every minute and on stop, and a stopped sandbox costs nothing |
| Inside the machine | Root and Docker, with rough edges users report; no systemd, and no /dev/kvm in the docs | Root shell on Ubuntu; the sandbox docs do not mention Docker or /dev/kvm | Root, Docker, systemd and /dev/kvm for emulators and VMs |
| Machine size | Fixed 8 vCPU and 100 GB disk; memory set and scaled by the platform | Up to 8 vCPU / 8 GB on Hobby, 32 vCPU / 32 GB on Pro | You choose: 8 vCPU / 16 GB on the $20 plan, 16 vCPU / 32 GB from $100 |
| Fork | No fork in the public API or CLI; checkpoints restore in place | Fork a running sandbox's filesystem; boot new ones from named checkpoints | Fork a running sandbox; named snapshots to start new ones |
| Reaching the sandbox | One HTTPS URL to one HTTP port; other ports and SSH only through the sprite proxy CLI | 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 IP; SSH |
| Coding agents | Claude Code, Codex, Gemini CLI and Cursor preinstalled, run through exec or a console | Claude Code, Codex, OpenCode and Pi preinstalled, run headless through exec | Seven agents preinstalled, with a prompt, steer and events API to drive them from outside |
| Keeping keys out of the sandbox | Connectors gateway holds the token for any HTTP API, with path allow and block lists | Secrets go into the sandbox as environment variables, or are saved in a checkpoint | Credentials proxy for model providers and any HTTPS API; switch a credential to another account when credits run out |
| Outbound rules | Optional DNS-based domain allowlist set from outside; private IPs always blocked | No sandbox egress allowlist; static outbound IPs for services on Pro | Open internet, no provider-side allowlist |
| Desktop and browser | Headless; no desktop or browser product | Headless: terminal, exec and SSH only | 60fps desktop and Chromium, computer use and browser control, embeddable stream |
| Apps and databases nearby | Sits next to Fly Machines and Managed Postgres in one Fly.io account | Postgres, Redis and services in the same project; a sandbox can join their private network | No hosted databases or app services; host your own inside a sandbox |
| Sandboxes at once | Not published on pay as you go; optional plans list running caps from 20 to 2,000 | 50 per environment on Hobby, 100 on Pro; Enterprise can ask for more | 100 to 2,000 by plan, with no session cap on paid plans |
| Regions | Not selectable | US West, US East, Amsterdam and Singapore, picked per sandbox | EU only (Germany, Finland, France), with EU data residency |
Every feature Battleships tracks (43)
| Feature | Sprites | 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 | No | Not published | Yes |
| Desktop GUI | No | No | Yes |
| Browser | No | Yes | Yes |
| Computer-use API | No | No | Yes |
| SSH | No | Yes | Yes |
| Persistent disk | Yes | Yes | Yes |
| Pause/resume | Yes | Yes | Yes |
| Automatic snapshots | Yes | No | Yes |
| Fork/clone | No | Yes | Yes |
| Live fork (no pause) | No | 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 | No | Yes | Yes |
| MCP server | Yes | Yes | No |
| GPU | No | No | No |
| Windows | No | No | No |
| Arm64 | No | No | No |
| Self-hosting | No | No | No |
| BYOC | No | Yes | No |
| Open source | No | No | No |
| Scoped API keys | Not published | 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 | Yes | Yes | No |
| EU data residency | No | Yes | Yes |
| Zero data retention | Not published | Not published | Yes |
Performance
There is no comparable measurement for Sprites or Railway: neither is in the StarSling hpc-sandbox-benchmarks results we use. bochka did 26.69 Node.js build-and-test runs per second at 4 vCPU / 8 GB, on dedicated AMD Ryzen 9 9950X hosts. So we cannot say whether Sprites or Railway is faster.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Sprites and Railway 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 | Sprites, 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 | $23 · Pay-as-you-go | $16 · Hobby · with limits | $20 · $20/mo |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $92 · Pay-as-you-go | $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 | $1,120 · Pay-as-you-go | $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 | $314 · Pay-as-you-go · with limits | $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 | $1,134 · Pay-as-you-go · with limits | $781 · Pro · with limits | $2,000 · $2000/mo · with limits |
Sprites: Sprites bills CPU time at $0.0385 per CPU-hour and actual memory at $0.021875 per GB-hour, only while the Sprite is awake, plus storage on the bytes you write. Optional plans buy fixed CPU, memory and storage allowances that are not credit.
Railway: Railway bills sandboxes per second at $50 per vCPU-month on CPU 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 Railway publishes no sandbox disk price.
Railway: Plans start at $20 a month, and all of it is 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 does not price sandbox disk, so its bills count CPU and memory only; its cap of 100 sandboxes per environment on Pro also blocks 300 sandboxes for your users and 1,000 jobs at once. Sprites does not publish a pay-as-you-go cap on running Sprites, so those two scenarios are unconfirmed there, while 50 agents in parallel are probably fine. For the 50-agent fleet, Docker inside a Railway sandbox is not confirmed. 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 | Sprites | Railway | bochka |
|---|---|---|---|
| One coding agent, workdays | None that bite |
| None that bite |
| One agent that never stops | None that bite |
| 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 Sprites when
your agents or apps sit idle most of the day and should wake on a request, or when you want a domain allowlist and per-path API rules for what an agent can reach.
- Sleeps when idle, wakes on request. For agents that sit idle most of the day: a Sprite stops billing compute, keeps its disk and wakes on the next request.
- Egress allowlist and API connectors. For teams that want to fence an agent in: limit which domains it reaches and which API paths a stored token can call.
- Plugs into agent platforms. For teams on Claude Managed Agents or Cursor Cloud Agents: Sprites can be the machine behind them, with a remote MCP server.
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. For apps already on Railway: sandboxes can join the same private network as your Postgres, Redis and services.
- Regions in the US and Asia. For users or data in the US or Asia: pick California, Virginia, Amsterdam or Singapore per sandbox.
- Big sandboxes and forks. For heavy or branching jobs: Pro sandboxes go up to 32 vCPU / 32 GB, and you can fork a running sandbox.
Where bochka fits
If your agents work for hours or days on one machine, both Sprites and Railway make you work around their idle rules, and both are headless. bochka gives each agent a full VM that keeps running and keeps its disk, with systemd, Docker, /dev/kvm, a desktop, forks and coding agents you drive from outside.
A machine that stays up and keeps its disk
A Sprite pauses about 30 seconds after work stops and drops open connections, unless a task holds it awake for an hour at a time. A Railway sandbox is destroyed after 30 idle minutes, or bills memory until destroyed if you turn that off.
systemd, Docker and /dev/kvm
Sprites does not run systemd, and users report docker exec failing for containers like Postgres and Redis. Railway's sandbox docs do not mention Docker or /dev/kvm. On bochka, services, docker compose and Android emulators work as on any Linux server.
A desktop and agents you drive from outside
Both are headless and both run agents through exec, so you parse their output and build any screen yourself. bochka streams a 60fps desktop with Chromium and lets your code prompt, steer and watch each agent through an API.
Use bochka when your agents work for hours on one machine and need systemd, Docker, /dev/kvm, many ports, a desktop and browser, forks, and an API to drive the agents inside from outside. Compare it one to one: bochka vs Sprites and bochka vs Railway.
Questions people ask
Is Sprites cheaper than Railway?
In our five scenarios Railway comes out lower: $16 against $23 for one agent on workdays, $70 against $92 for one that never stops, and $739 against $1,120 for 50 agents in parallel. Railway's numbers leave out disk, which it does not price, and Sprites bills real CPU use, so a mostly idle Sprite can cost less. On bochka the same three come to $20, $26 and $317.
Which is faster, Sprites or Railway?
We do not know yet. Neither Sprites nor Railway has a result in the benchmark we use. bochka did 26.69 Node.js build-and-test runs per second at 4 vCPU / 8 GB.
Can Sprites and Railway run Docker?
Users run Docker on Sprites, but a community report shows docker exec failing for containers whose main process is not root, such as Postgres and Redis. Railway's sandbox docs do not mention Docker. bochka runs Docker, systemd and /dev/kvm in every sandbox.
What happens when a sandbox goes idle?
A Sprite pauses about 30 seconds after work stops, keeps its disk, and wakes on the next request. A Railway sandbox is destroyed after its idle timeout, 30 minutes by default, so you take a checkpoint first to keep files. A bochka sandbox runs until you stop it and keeps its disk while stopped.
Can I SSH into Sprites or Railway?
Railway sandboxes support SSH and port forwarding. On Sprites you install an SSH server yourself and tunnel it through the sprite proxy CLI. bochka sandboxes have SSH, raw TCP and a dedicated IP.
Where do Sprites and Railway run?
Sprites does not let you choose a region. Railway has regions in California, Virginia, Amsterdam and Singapore. bochka runs only in the EU, in Germany, Finland and France, with EU data residency.
Try bochka
Install the CLI, then run bochka new.
Product preview