Tensorlake vs Railway
Tensorlake is built for agents: microVMs that can freeze their memory, wake up warm and copy into many clones. Railway is an app platform for services and databases that added Linux VM sandboxes, which are destroyed when they go idle.
The companies and products
Tensorlake
Tensorlake is a San Francisco company that sells infrastructure for AI agents, with sandboxes as its main product.
Tensorlake Sandboxes are microVMs, backed by Firecracker and Cloud Hypervisor, that you create through an API and that boot in a few hundred milliseconds. Named sandboxes suspend when idle and keep their memory and running processes, and you can copy a running sandbox into several warm clones. Around them Tensorlake sells versioned file systems, hosted Git, an orchestration layer and a bring-your-own-cloud option, aimed at teams running coding agents, evals and RL rollouts.
- Headquarters
- San Francisco
- Investors shown
- Redpoint and Amplify Partners
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. “5th cheapest of 367” means 4 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 | Tensorlake: 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 Tensorlake fits a software factory fully and Railway only as a compromise, since its sandboxes are destroyed when idle; bochka adds Docker, /dev/kvm and coding agents you drive by API. | 5th cheapest of 367 $1,010 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 All three fit an always-on agent; Tensorlake suspends it with memory, Railway needs the idle timeout set to 0, and bochka keeps the machine on with no session cap. | 9th cheapest of 366 $1,381 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 Tensorlake and Railway both fit short code runs well, and bochka's start-rate limits make big bursts of new machines a compromise. | 24th cheapest of 345 $250 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, while Tensorlake Pro allows 1,000 at once; bochka also gives each user sandbox HTTPS URLs and raw TCP. | 5th cheapest of 361 $471 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 Tensorlake ranks 1st for RL rollouts, with warm clones from one memory snapshot; Railway's per-environment cap makes it a compromise. | Cheapest of 360 $5,637 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 | 24th cheapest of 364 $506 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 Tensorlake documents on its systemd image and Railway's sandbox docs do not mention. | 54th cheapest of 377 $424 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 box that stays on all day better than Tensorlake, whose model is built around suspending idle sandboxes; bochka keeps its disk and stops for free. | 185th of 368, with limits $250 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 Tensorlake has an XFCE desktop over VNC and Railway sandboxes are headless; bochka streams a 60fps desktop with computer use. | 9th cheapest of 369 $294 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 | 13th cheapest of 367 $250 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 | 22nd cheapest of 346 $250 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 | 121st of 338, with limits $3,484 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 | 4th cheapest of 360 $250 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 | Tensorlake | Railway | bochka |
|---|---|---|---|
| Isolation | Firecracker and Cloud Hypervisor microVMs with their own kernel; GPU sandboxes use gVisor | Sandboxes are isolated Linux VMs; app services are containers | Full VM with its own kernel on dedicated AMD Ryzen 9 9950X hosts |
| When the sandbox goes idle | Idle timeout (600 s by default), then named sandboxes suspend with memory and ephemeral ones end | Destroyed after the idle timeout (30 minutes by default); files survive only in checkpoints you take | Stops; the disk is kept with snapshots every minute and on stop, and a stopped sandbox costs nothing |
| Memory snapshots | Yes: suspend and memory snapshots keep running processes and restore warm | No: checkpoints save the disk only | No: the disk is kept, and resume reboots the machine |
| Fork a running sandbox | Copy a running or suspended sandbox into N warm clones with memory | Fork a running sandbox's filesystem | Fork a running sandbox (disk) |
| Docker inside | Yes, on the tensorlake/ubuntu-systemd image | Root shell on Ubuntu; the sandbox docs do not mention Docker | Yes, with root and systemd on every machine |
| Nested virtualization | No: sandboxes set SANDBOX_KVM_AVAILABLE=0 | Not mentioned in the sandbox docs | Yes, /dev/kvm inside, so Android emulators and VMs run |
| Desktop and computer use | XFCE desktop with Firefox over VNC, with screenshot, mouse and keyboard calls | Headless: terminal, exec and SSH only | 60fps desktop and Chromium, computer use and browser control, embeddable stream |
| Coding agents | You bring and run your own agent; managed images are plain OS bases | Claude Code, Codex, OpenCode and Pi preinstalled; you run them headless through exec | Claude Code, Codex, OpenCode and more preinstalled, with a prompt, steer and events API |
| API keys | Stored secrets are injected into the sandbox | Secrets go into the sandbox as environment variables, or are saved in a checkpoint | Credentials proxy for AI providers and any HTTPS API: real keys never enter the sandbox |
| Reaching the sandbox | HTTP, WebSocket and gRPC through an authenticated proxy on exposed ports | Up to 10 public HTTPS domains, set only at creation; SSH and port forwarding | HTTPS URLs for up to 50 ports, token-protected, plus raw TCP and a dedicated IP |
| Outbound rules | allow_out and deny_out lists by domain, IP or CIDR, or no internet at all | No sandbox outbound allowlist documented | No provider-side allowlist; you set your own firewall as root |
| Apps and databases next to the sandbox | Sandboxes, versioned file systems and hosted Git; no app hosting described | 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 | 1,000 on Pro, up to 10 on prepaid credits | 50 per environment on Hobby, 100 on Pro; Enterprise can ask for more | 100 to 2,000 by plan, with limits on starts per minute and per day |
| GPUs and regions | GPU sandboxes by request; US and EU, or your own cloud through BYOC | No GPU sandboxes; US West, US East, Amsterdam and Singapore | No GPUs; EU only: Germany, Finland, France |
Every feature Battleships tracks (43)
| Feature | Tensorlake | 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 | Yes | Not published | Yes |
| Desktop GUI | Yes | No | Yes |
| Browser | Yes | Yes | Yes |
| Computer-use API | Yes | No | Yes |
| SSH | Yes | 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 | No | No | Yes |
| Secret proxy for any API | No | No | Yes |
| Preinstalled agents | No | Yes | Yes |
| Agent harness API | No | Yes | Yes |
| MCP server | No | Yes | No |
| GPU | Yes | 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 | 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 | Yes | Yes | Yes |
| Zero data retention | Yes | Not published | Yes |
Performance
There is no comparable measurement between Tensorlake and Railway: neither has a result in StarSling's public hpc-sandbox-benchmarks. bochka did 26.69 Node.js build-and-test runs per second at 4 vCPU / 8 GB there, the fastest result measured, but we cannot say how much faster it is than either. Tensorlake's docs say its default image starts in a few hundred milliseconds.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Tensorlake 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 | Tensorlake, 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 | $250 · Pro | $16 · Hobby · with limits | $20 · $20/mo |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $250 · Pro | $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,030 · Pro | $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 | $293 · Pro | $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,127 · Pro | $781 · Pro · with limits | $2,000 · $2000/mo · with limits |
Tensorlake: Pro is $250 per billing cycle, which includes $250 of usage, then $0.01 per CU. CPU bills only while active, RAM and disk bill on what you allocate while the sandbox runs, and a suspended sandbox pays snapshot storage; small users can buy prepaid packs from $5 instead.
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 numbers leave it out.
Railway: 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 not a clean fit in any of the five scenarios, because it is an app platform first and publishes no sandbox disk price, so its bills count CPU and memory only. Its Pro cap of 100 sandboxes per environment means 300 sandboxes for your users or 1,000 jobs at once need several environments or an Enterprise limit. Tensorlake Pro fits all five, with 1,000 at once, but every bill starts at the $250 Pro fee. 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 | Tensorlake | 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 |
| None that bite |
| 1,000 short jobs at once | None that bite |
|
|
Which one should you use?
Use Tensorlake when
you fan out hundreds of short rollouts or evals from one warm state, need memory snapshots, outbound rules, GPUs or sandboxes in your own cloud account.
- Memory snapshots and warm clones. Useful when an agent must pick up mid-process: Tensorlake saves a sandbox's memory and copies it into warm clones.
- Big fan-outs from one state. Useful for RL rollouts and evals: Tensorlake Pro runs 1,000 sandboxes at once, where Railway caps Pro at 100 per environment.
- Outbound rules, GPUs and your own cloud. Tensorlake can allow or deny outbound traffic per sandbox, offers GPUs by request and can run in your own cloud account.
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.
- Coding agents in the image. Useful if you just want to run an agent headless: Railway's default image ships Claude Code, Codex, OpenCode and Pi.
Where bochka fits
Tensorlake is strongest at short, wide fan-outs from a warm state, and Railway at sandboxes that sit next to apps you already host. If your agents instead work for hours on one machine, with Docker, emulators, a desktop and servers others must reach, bochka gives each one a full VM that keeps its disk. Its coding agents are driven from outside while their keys stay outside the machine.
A disk that stays, with no session cap
A Tensorlake ephemeral sandbox ends after 10 idle minutes and a Railway sandbox is destroyed after 30, unless you keep it awake and pay for its memory. A bochka sandbox stops, saves its disk every minute and costs nothing while stopped.
Emulators, Docker and a real desktop
Tensorlake sandboxes have no /dev/kvm, so Android emulators and VMs do not start, and Railway's docs mention neither Docker nor /dev/kvm and give no screen at all. bochka has Docker, systemd, /dev/kvm and a 60fps desktop on every machine.
Agents driven from outside, keys kept out
On Tensorlake you install the agent yourself, and on Railway you shell it through exec and parse its output. Both put API keys inside the sandbox, where code the agent runs can read them. bochka's proxy keeps them outside.
Use bochka when your agents work for hours or days: a full VM that keeps its disk, with Docker, /dev/kvm, a desktop, and coding agents you drive from outside while their keys stay outside. Compare it one to one: bochka vs Tensorlake and bochka vs Railway.
Questions people ask
Is Tensorlake cheaper than Railway?
In our five scenarios Railway comes out lower: one agent running all month is $70 on Railway and $250 on Tensorlake Pro, and 50 agents in parallel are $739 against $1,030. But Railway's numbers leave out disk, which it does not price, and its 100-per-environment cap means it does not cleanly fit the bigger jobs. On bochka the same always-on agent is $26 a month.
Which is faster, Tensorlake or Railway?
We cannot say: neither has a result on the CPU benchmark we use. bochka scores 26.69 runs per second there, the fastest measured. Tensorlake says its sandboxes boot in a few hundred milliseconds.
Can Tensorlake or Railway run Docker?
Tensorlake runs Docker on its tensorlake/ubuntu-systemd image. Railway's sandbox docs give a root shell on Ubuntu but do not mention Docker. bochka has Docker, root and systemd on every machine.
What happens when a sandbox goes idle?
On Tensorlake, after 600 seconds by default a named sandbox suspends with its memory and an ephemeral one ends. Railway destroys the sandbox after 30 minutes by default, and only checkpoints you took survive. A bochka sandbox stops, keeps its disk and costs nothing while stopped.
Which has a desktop for computer-use agents?
Tensorlake has an XFCE desktop with Firefox over VNC, with screenshot, mouse and keyboard calls. Railway sandboxes are headless. bochka streams a 60fps desktop with Chromium, computer use and browser control.
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