Railway vs Google Agent Runtime
Railway is an app platform whose sandboxes are Linux VMs with a root shell, destroyed when they go idle. Google Agent Runtime, once called Vertex AI Agent Engine, hosts your agent code on Google Cloud and runs its sandboxes as an unprivileged user in a locked container.
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.
Google Agent Runtime
Google Agent Runtime is the agent hosting part of Gemini Enterprise Agent Platform on Google Cloud, renamed from Vertex AI Agent Engine in April 2026.
It is a hyperscaler service, not a sandbox company. Agent Runtime deploys agents you build with ADK, LangGraph, LangChain, AG2 or LlamaIndex and bills them only while they work on a turn. Next to it, Agent Sandbox gives those agents a place to run code: a Code Execution sandbox, a shell or custom container sandbox, and a Computer Use browser. All of them run as secure containers inside your Google Cloud project.
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 | Google Agent Runtime: price rank | bochka: price rank |
|---|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month Railway gives a root shell but destroys idle sandboxes, and Google has no root or Docker, so both are a compromise here; bochka keeps the disk and runs Docker on every VM. | 51st of 367, with limits $342 a month | 295th of 367, with limits $5,801 a month | 3rd cheapest of 367 $634 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB Both fit: Railway needs the idle timeout set to 0 or a Cloud Agent, and a Google sandbox must be recreated when its 7-day TTL ends; a bochka VM has no session cap on paid plans. | 16th cheapest of 366 $3,977 a month | 28th cheapest of 366 $7,519 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 is a full fit for short code runs because it bills for CPU used, while Google's Code Execution sandbox is a ready Python interpreter with no network. | 36th cheapest of 345 $413 a month | 254th of 345, with limits $275 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 per environment (100 on Pro) and Google gives users no public URL; on bochka each sandbox can serve HTTPS on up to 50 ports. | 42nd of 361, with limits $290 a month | 280th of 361, with limits $1,916 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 | 128th of 360, with limits $8,240 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 Google can start many sandboxes from one snapshot with memory, and Railway can fork a running sandbox's files but caps how many run per environment. | 108th of 364, with limits $364 a month | 79th cheapest of 364 $2,060 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 Railway's sandbox docs do not mention and Google's unprivileged sandboxes do not offer; bochka runs Docker on every VM. | 113th cheapest of 377 $1,210 a month | 98th cheapest of 377 $989 a month | 4th cheapest of 377 $86 a month |
| 24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB Railway sandboxes have SSH, and its Cloud Agents keep a disk in early access; Google has no SSH and runs each command in a new shell. | 66th cheapest of 368 $89 a month | 311th of 368, with limits $241 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 sandboxes are headless and Google offers only a browser with a VNC view, so both are a compromise; bochka streams a full 60fps desktop. | 77th of 369, with limits $103 a month | 283rd of 369, with limits $1,648 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 | 102nd of 367, with limits $824 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 | 53rd cheapest of 346 $515 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 | 210th of 338, with limits $8,240 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 | 260th of 360, with limits $412 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 | Google Agent Runtime | bochka |
|---|---|---|---|
| Isolation | Sandboxes are isolated Linux VMs; app services are containers | Secure container sandboxing inside your Google Cloud project | Every sandbox is a full VM with its own kernel |
| Root, Docker and nested virtualization | Root shell on Ubuntu; the sandbox docs do not mention Docker or /dev/kvm | Runs as appuser with no sudo; images must not need root; no Docker or /dev/kvm documented | Root, systemd, Docker and /dev/kvm on every machine |
| Shell access | SSH and port forwarding, plus exec from the CLI or SDK | execute_bash() API calls; each command runs in a new shell; no SSH | SSH, plus an API for commands |
| When the sandbox goes idle | Destroyed after the idle timeout (30 minutes by default); files survive only in checkpoints you take | Lives until its TTL ends (7 days at most for a custom container); pause keeps files and costs less | You stop it; the disk is kept, with snapshots every minute and on stop, and a stopped sandbox costs nothing |
| Snapshots and branching | Fork a running sandbox's filesystem; named disk checkpoints to boot new ones (no memory) | Snapshots keep memory and files; start many sandboxes from one snapshot | Fork a running sandbox; named snapshots to start new ones (disk only, no memory) |
| Reaching the sandbox | Up to 10 public HTTPS domains, set only at creation | Through Google's API, or a private endpoint in your own VPC; no public URL documented | HTTPS URLs for up to 50 ports, token-protected; raw TCP; dedicated IPv6 or IPv4 |
| Outbound internet | Open internet from the sandbox | Off unless the template turns it on; can route through your VPC with Cloud NAT, a static IP or Cloud NGFW | Open internet on every plan; no provider-side allowlist |
| Desktop and computer use | Headless: terminal, exec and SSH only | A browser in a container with a VNC live view, a click, type and screenshot API, and CDP | 60fps desktop and Chromium, computer use and browser control, embeddable stream |
| Coding agents | Claude Code, Codex, OpenCode and Pi preinstalled; you run them headless through exec | Managed Agents API (Preview) runs Google's Antigravity harness; no other coding harness named | Claude Code, Codex, OpenCode and more preinstalled, with a prompt, steer and events API |
| Keeping keys out of the sandbox | Secrets go into the sandbox as environment variables, or are saved in a checkpoint | You provision and scope the credentials the agent uses | AI credentials proxy for model providers and any HTTPS API you register; switch a credential to another account when credits run out |
| What else it hosts | Web services, Postgres and Redis in the same project; a sandbox can join their private network | Agent Runtime deploys ADK, LangGraph, LangChain, AG2 and LlamaIndex agents; idle time between turns is not billed | Sandboxes only; you host your own services or agent loop inside a sandbox |
| Biggest sandbox | 8 vCPU / 8 GB on Hobby, 32 vCPU / 32 GB on Pro | Sandbox maximum not published; changing a sandbox's size means deleting it | 8 vCPU / 16 GB on the $20 plan, 16 vCPU / 32 GB from $100 |
| How long a sandbox lives | No documented cap while it is active; the idle timeout can be set to 0 | TTL of up to 7 days for a custom container and 14 days for Code Execution | No session cap on paid plans |
| Regions | US West, US East, Amsterdam and Singapore | 23 locations in the US, Europe, Asia, Canada, Australia and Brazil | EU only: Germany, Finland, France |
Every feature Battleships tracks (43)
| Feature | Railway | Google Agent Runtime | bochka |
|---|---|---|---|
| Full VM (own kernel) | Yes | No | Yes |
| Docker inside | Not published | No | Yes |
| Nested virtualization | No | No | Yes |
| Root | Yes | No | Yes |
| Systemd | Not published | Not published | Yes |
| Desktop GUI | No | No | Yes |
| Browser | Yes | Yes | Yes |
| Computer-use API | No | Yes | 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 | Yes | Yes |
| Memory fork | No | Yes | No |
| Custom image (Docker or snapshot) | Yes | Yes | Yes |
| ≥24 h sessions | Yes | Yes | Yes |
| Idle auto-stop | Yes | No | No |
| Wake on request | No | No | No |
| HTTPS preview URLs | Yes | No | Yes |
| Raw TCP inbound | No | Not published | 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 | Yes | Yes |
| MCP server | Yes | No | No |
| GPU | No | No | No |
| Windows | No | No | No |
| Arm64 | No | Yes | No |
| Self-hosting | No | No | No |
| BYOC | Yes | No | 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 | Not published | No |
| SSO | Yes | Yes | No |
| SOC 2 | Yes | Yes | No |
| HIPAA | Yes | Yes | No |
| EU data residency | Yes | Yes | Yes |
| Zero data retention | Not published | Not published | Yes |
Performance
There is no comparable measurement for Railway or Google Agent Runtime, so we cannot say which of the two is faster. In StarSling's public benchmark run of 2026-09-29, bochka did 26.69 Node.js build-and-test runs per second at 4 vCPU / 8 GB; neither Railway nor Google's sandboxes were part of that run.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Railway and Google Agent Runtime 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 | Google Agent Runtime, 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 | $73 · Pay as you go | $20 · $20/mo |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $70 · Hobby · with limits | $301 · Pay as you go | $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 | $3,626 · Pay as you go · 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 | $223 · Pro · with limits | $1,030 · Pay as you go | $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 | $2,060 · Pay as you go | $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; 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.
Google Agent Runtime: Google bills $0.085 per vCPU-hour and $0.009 per GiB-hour for what you allocate, with the first 50 vCPU-hours and 100 GiB-hours free each month. Runtime skips idle time between turns, but sandboxes bill while they exist, and disk and egress rates are not published.
Google Agent Runtime: 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 marks every scenario as not a clean fit because it is an app platform first and does not price sandbox disk, and it caps sandboxes at 50 per environment on Hobby and 100 on Pro, so 300 user sandboxes or 1,000 jobs at once need several environments. Google fits four of the five scenarios but not the 50-agent fleet, because its sandboxes have no Docker inside, and every Google row leaves disk and egress unpriced. A Google sandbox is also deleted when its TTL ends, 7 days at most for a custom container. 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 | Google Agent Runtime | 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 VM sandboxes with a root shell on the same private network.
- A VM with a root shell and SSH. Useful if your agent needs root and SSH: Railway sandboxes are Linux VMs, while Google sandboxes run as an unprivileged user.
- Next to your apps and databases. Useful if your app already runs on Railway: a sandbox can join the private network of your Postgres and services.
- Short jobs billed for CPU used. Useful for many quick code runs: Railway bills sandbox CPU on what is used and has no published limit on starts per minute.
Use Google Agent Runtime when
you build agents with ADK or LangGraph on Google Cloud and want them hosted inside your own project, network rules and regions, with code runs in a locked sandbox.
- A managed home for your agent code. Useful if you build agents with ADK or LangGraph: Agent Runtime hosts them and skips billing for idle time between turns.
- Inside your Google Cloud network. Useful if agents must stay in a Google Cloud perimeter, with egress off by default and routed through your own firewall.
- Memory snapshots and 23 regions. Useful if you branch sandboxes with their memory, or need regions in Asia, Australia, Canada or Brazil.
Where bochka fits
Railway is an app platform with sandboxes added, and Google Agent Runtime is agent hosting inside Google Cloud. If what you are really running is coding or computer-use 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.
Root, Docker and a real kernel
Google sandboxes run as appuser with no sudo or Docker, so the 50-agent fleet does not fit there, and Railway's sandbox docs do not mention Docker. bochka has root, systemd, Docker and /dev/kvm on every VM.
Work that survives a pause
Railway destroys an idle sandbox after 30 minutes by default, and turning that off keeps memory billing. Google deletes a sandbox when its TTL ends. A bochka sandbox stops, keeps a disk saved every minute and has no session cap.
Agents you drive and watch
Railway runs coding agents headless through exec and Google offers only its Antigravity harness and a browser. bochka adds a prompt, steer and events API, a 60fps desktop, HTTPS on 50 ports and a proxy that keeps AI keys outside.
Use bochka when your agents work for hours or days and need a real computer: a full VM that keeps its disk, with root, Docker, a desktop, public URLs and coding agents you drive from outside. Compare it one to one: bochka vs Railway and bochka vs Google Agent Runtime.
Questions people ask
Is Railway cheaper than Google Agent Runtime?
In all five scenarios we priced, Railway comes out lower: one agent running all month is $70 on Railway against $301 on Google, and 50 agents in parallel are $739 against $3,626. Railway's bills leave out disk, which it does not price, and a Google Runtime agent that sits idle between turns bills less than a sandbox that exists all month. bochka comes to $26 and $317 a month for those two.
Which is faster, Railway or Google Agent Runtime?
We do not know: neither has a result in StarSling's public benchmark. bochka did 26.69 Node.js build-and-test runs per second at 4 vCPU / 8 GB in that run.
Can I run Docker in Railway or Google sandboxes?
Google's sandboxes run commands as the unprivileged user appuser with no sudo, so Docker is not available. Railway sandboxes give a root shell on Ubuntu, but its sandbox docs do not mention Docker. On bochka every sandbox is a VM with root, Docker and /dev/kvm.
What happens to my files when the sandbox stops?
Railway destroys an idle sandbox after its idle timeout, 30 minutes by default, and only checkpoints you took survive. Google keeps files while a sandbox is paused, but deletes it when its TTL ends. A bochka sandbox stops, keeps its disk and costs nothing while stopped.
Is Google Agent Runtime the same as Vertex AI Agent Engine?
Yes. Google renamed Vertex AI Agent Engine to Agent Runtime in April 2026, as part of Gemini Enterprise Agent Platform. Its code, shell and browser sandboxes are a separate part of the same platform called Agent Sandbox.
Can an agent use a desktop on Railway or Google?
Railway sandboxes are headless, with a terminal, exec and SSH only. Google's Computer Use sandbox is a browser with a VNC live view and a click and type API. bochka streams a full 60fps desktop with Chromium and computer use.
Try bochka
Install the CLI, then run bochka new.
Product preview