Blaxel vs Railway
Blaxel is built only for agent sandboxes: each one is a Firecracker microVM that sleeps seconds after the last connection and wakes in under 25 ms with its memory intact. Railway is an app platform that added sandbox VMs in 2026, which live next to your apps and databases and are destroyed when they go idle.
The companies and products
Blaxel
Blaxel is a San Francisco company that runs cloud infrastructure for AI agents, and since September 2026 it is part of Baseten.
You get sandboxes, batch jobs, MCP server hosting and a model gateway. Each sandbox is a Firecracker microVM with its own kernel that drops to standby when nothing is connected and resumes in under 25 ms with its memory and running processes. It is built for agent products that start many sandboxes and want them asleep most of the time.
- Headquarters
- San Francisco, founded 2024
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. “10th cheapest of 367” means 9 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 | Blaxel: 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 Blaxel fits a software factory fully, while Railway is a compromise because its sandboxes are destroyed when idle; bochka ranks 3rd with a real disk and /dev/kvm. | 10th cheapest of 367 $2,373 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 Both fit: Blaxel sleeps idle assistants and wakes them on request, while Railway needs the idle timeout set to 0 or a Cloud Agent, and memory bills the whole time. | 12th cheapest of 366 $2,832 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 Blaxel ranks 14th and Railway 36th here, since short runs that sleep at once and wake in milliseconds are what Blaxel is built for; bochka limits starts per minute. | 14th cheapest of 345 $144 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 Blaxel's public tiers stop at 200 sandboxes at once and Railway's Pro at 100 per environment, while bochka fits 300 users at once on a self-serve plan. | 101st of 361, with limits $926 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 | 77th of 360, with limits $4,378 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 | 136th of 364, with limits $704 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 CI jobs that build containers need Docker, which Blaxel offers through a Docker-in-sandbox image and Railway's sandbox docs do not mention. | 57th cheapest of 377 $431 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 fits a dev box fully with an always-on service or a Cloud Agent, while Blaxel has no native SSH; bochka ranks 18th as a plain machine you SSH into. | 265th of 368, with limits $114 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 Blaxel runs a desktop and a browser, while Railway sandboxes are headless; bochka streams a 60fps desktop you can embed in your app. | 14th cheapest of 369 $634 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 | 16th cheapest of 367 $317 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 | 16th cheapest of 346 $215 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 | 147th of 338, with limits $4,292 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 Blaxel ranks 3rd with domain-level egress rules on the provider side, Railway is a compromise, and bochka ranks 2nd with root, raw TCP and nftables. | 3rd cheapest of 360 $217 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 | Blaxel | Railway | bochka |
|---|---|---|---|
| Isolation | Firecracker microVM, own kernel | Sandboxes are isolated Linux VMs; app services are containers | Full VM, own kernel, on dedicated AMD Ryzen 9 9950X hosts |
| When the sandbox goes idle | Standby a few seconds after the last connection; wakes in under 25 ms with memory and processes | Destroyed after the idle timeout (30 minutes by default); files survive only in checkpoints you take | You stop it; the disk is kept and a stopped sandbox costs nothing; resume boots the VM again |
| Disk | Files live in memory (about half the RAM); one block volume can be attached at creation | Sandbox disk size and price not published; save files with checkpoints | A real disk that stays, snapshotted every minute and on stop |
| Docker and nested virtualization | Docker with a Docker-in-sandbox image; no /dev/kvm | Root shell on Ubuntu; the sandbox docs do not mention Docker or /dev/kvm | Docker, root, systemd and /dev/kvm on every machine |
| SSH | Terminal through the bl connect command, no native SSH | SSH and port forwarding | Real SSH, root and systemd |
| Fork | Fork with memory and running processes (private preview) | Fork a running sandbox's filesystem; named checkpoints to boot new ones | Fork a running sandbox (disk); named snapshots to start new ones |
| Reaching the sandbox | Preview URL per port, public or token-protected; no raw TCP or public IP | Up to 10 public HTTPS domains, set only at creation | HTTPS URLs for up to 50 ports, token-protected; raw TCP; dedicated IPv6 or IPv4 |
| Outbound rules | Domain allow and deny lists, method and path rules, static egress IPs | No domain allowlist; static outbound IPs for services on Pro | Open internet; filter inside the VM with nftables |
| Keeping keys out of the sandbox | Proxy fills secrets into outbound HTTPS requests (public preview) | Secrets go into the sandbox as environment variables, or are saved in a checkpoint | AI credentials proxy for model providers and any HTTPS API you register; switch to another account when credits run out |
| Coding agents | Claude Code image you drive from its terminal or your own harness | Claude Code, Codex, OpenCode and Pi preinstalled; you run them headless through exec | Claude Code, Codex, OpenCode and more, driven by a prompt, steer and events API |
| Desktop and computer use | Desktop, browser and computer use | Headless: terminal, exec and SSH only | 60fps desktop and Chromium, computer use and browser control, embeddable stream |
| Apps and databases next to the sandbox | Batch jobs, MCP server hosting and a model gateway | Deploy 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 | 10, 50 or 200 on self-serve tiers, standby sandboxes included | 50 per environment on Hobby, 100 on Pro | 100 to 2,000 by plan |
| Regions | Oregon, North Virginia, London, Frankfurt | California, Virginia, Amsterdam, Singapore | EU only: Germany, Finland, France |
Every feature Battleships tracks (43)
| Feature | Blaxel | 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 | Yes | No | Yes |
| Browser | Yes | Yes | Yes |
| Computer-use API | Yes | No | Yes |
| SSH | No | Yes | Yes |
| Persistent disk | Yes | Yes | Yes |
| Pause/resume | Yes | Yes | Yes |
| Automatic snapshots | Yes | No | Yes |
| Fork/clone | Yes | Yes | Yes |
| Live fork (no pause) | Yes | Yes | Yes |
| Memory fork | Yes | 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 | Yes | Yes | No |
| Open source | No | No | No |
| Scoped API keys | Yes | Not published | Yes |
| Spend limits | No | Yes | Yes |
| Usage per sandbox (API) | Yes | No | Yes |
| Audit logs | Not published | Yes | No |
| SSO | Yes | Yes | No |
| SOC 2 | Yes | Yes | No |
| HIPAA | Yes | Yes | No |
| EU data residency | Yes | Yes | Yes |
| Zero data retention | Yes | Not published | Yes |
Performance
In the same StarSling Node.js build-and-test run at 4 vCPU and 8 GB on September 29, 2026, bochka did 26.69 runs per second and Blaxel 19.48, so bochka got through about 1.4 times the work in the same time. Railway has no result in that benchmark yet, so we cannot say how it compares to either.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Blaxel measured on: Sandbox (active time, RAM-only pricing, CPU bundled). 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 | Blaxel, 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 | $33 · Pay-as-you-go Tier 1 | $16 · Hobby · with limits | $20 · $20/mo |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $120 · Pay-as-you-go Tier 1 | $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,489 · Pay-as-you-go Tier 1 | $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 | $396 · Pay-as-you-go Tier 2 · 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 | $876 · Pay-as-you-go Tier 2 · with limits | $781 · Pro · with limits | $2,000 · $2000/mo · with limits |
Blaxel: Blaxel charges for allocated RAM per second while a sandbox is active, meaning it has an open connection, with CPU included. In standby you pay only snapshot storage, and volumes bill on their full size.
Railway: Railway bills sandboxes per second on CPU actually used and on memory in use, and memory keeps billing while a sandbox waits until it is destroyed. The Hobby ($5) and Pro ($20) fees count toward usage, and sandbox disk has no published price, so our bills leave it out.
Railway: Your plan payment, from $20 a month, is all usage credit spent per second while a machine runs. 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. Blaxel's self-serve tiers stop at 200 sandboxes at once, standby ones included, and Railway's at 100 per environment on Pro, so 300 sandboxes for your users or 1,000 jobs at once need a sales tier or several environments. On Blaxel's lower tiers sandboxes are deleted after 7 or 30 days, and on Railway an always-on agent needs the idle timeout set to 0. bochka fits 300 users at once, but queues a 1,000-job burst above 90 starts a minute.
| Scenario | Blaxel | 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 |
| None that bite |
| Sandboxes for your users |
|
| None that bite |
| 1,000 short jobs at once |
|
|
|
Which one should you use?
Use Blaxel when
your sandboxes sit idle most of the time and must wake in milliseconds with their memory, or you need domain-level outbound rules.
- Sleeps in seconds, wakes in milliseconds. Useful if sandboxes sit idle most of the time: one sleeps seconds after the last connection and wakes in under 25 ms.
- Memory kept through sleep and fork. Useful if an agent must pick up mid-task: standby keeps running processes, and a fork can copy them (private preview).
- Network rules on the provider side. Useful if you must fence agents in: Blaxel limits a sandbox to chosen domains, methods and paths, with static egress IPs.
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 a region in 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.
- Regions in the US and Asia. Useful if your users are in Asia: Railway runs in California, Virginia, Amsterdam and Singapore.
- Plain SSH and CPU billed on use. Useful for quick jobs and hands-on debugging: you SSH in, and CPU bills only for what the sandbox actually uses.
Where bochka fits
If your agents do real work for hours, like installs, builds, tests, Docker and emulators, look at bochka. Each sandbox is a whole Linux machine with a disk that stays, coding agents you drive from outside, and a CPU that ran 26.69 runs per second against Blaxel's 19.48 in the same benchmark.
A whole Linux machine
Without /dev/kvm an Android emulator or a VM does not start, and neither Blaxel nor Railway offers it. Blaxel also has no native SSH, and Railway's sandbox docs do not mention Docker, so you install and check it yourself.
A disk that stays
Blaxel keeps files in memory, about half the RAM, unless you attach a volume at creation. Railway destroys a sandbox after 30 idle minutes; setting the timeout to 0 keeps it, but memory bills until you destroy it.
Agents driven from outside, keys kept outside
On Blaxel you build the agent harness yourself. On Railway you run each agent through exec, parse its output, and its API key sits in the VM where code the agent runs can read it.
Use bochka when your agents work for hours or days: a full VM with /dev/kvm, Docker and a disk that stays, a desktop, and coding agents you drive by API while their keys stay outside. Compare it one to one: bochka vs Blaxel and bochka vs Railway.
Questions people ask
Is Blaxel cheaper than Railway?
In our scenarios Railway comes out lower: one agent that never stops is $70 on Railway against $120 on Blaxel, and 50 agents in parallel are $739 against $1,489. But Railway's bills leave out disk, which it does not price, and Blaxel bills only while a connection is open, so a workload that disconnects often pays less. bochka is $26 and $317 for those two.
Which is faster, Blaxel or Railway?
We cannot say: Blaxel did 19.48 runs per second in StarSling's Node.js benchmark at 4 vCPU and 8 GB, and Railway has no result there yet. bochka did 26.69 in the same run.
Are Blaxel and Railway sandboxes real VMs?
Yes. Each Blaxel sandbox is a Firecracker microVM with its own kernel, and Railway's docs call each sandbox an isolated Linux VM, while its app services are containers. bochka is a full VM with systemd and /dev/kvm.
Can Blaxel or Railway run Docker?
Blaxel runs Docker with its Docker-in-sandbox image. Railway's sandbox docs do not mention Docker. Neither gives /dev/kvm, so Android emulators do not run, while bochka has Docker and /dev/kvm on every machine.
What happens when a sandbox goes idle?
Blaxel puts it in standby a few seconds after the last connection and wakes it in under 25 ms with memory and processes. Railway destroys it after the idle timeout, 30 minutes by default, so you take checkpoints to keep files. bochka stops it, keeps the disk and charges nothing while stopped.
Where do Blaxel and Railway run?
Blaxel runs in Oregon, North Virginia, London and Frankfurt. Railway runs 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