Railway vs OpenAI Containers
Railway sandboxes are Linux VMs with root, SSH and open internet that you create from a CLI or SDK, next to apps you host on Railway. OpenAI Containers are the boxes the model itself runs code in during an API call, with no sudo, no inbound access and no internet until an admin allows domains.
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.
OpenAI Containers
OpenAI Containers are the sandboxes OpenAI runs for its own model tools: Code Interpreter, Hosted Shell and the Agents API's hosted sandbox.
This is a different kind of product from bochka: a tool inside OpenAI's model API, not a machine you rent. You create a container through the API or let a Responses call make one, and the model runs Python or shell commands in it on a fixed Debian 12 image without sudo, until it expires after 20 minutes without use. It is built for apps that already call OpenAI models and want them to run code, read files and make charts without running any servers.
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 | OpenAI Containers: price rank | bochka: price rank |
|---|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month A software factory needs root, Docker and a disk that stays; Railway gives root but destroys idle sandboxes, and an OpenAI container has no sudo and expires after 20 idle minutes. | 51st of 367, with limits $342 a month | 356th of 367, with limits $17,371 a month | 3rd cheapest of 367 $634 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB An always-on assistant fits on Railway with the idle timeout set to 0; an OpenAI container has to be touched every 20 minutes or its data is discarded. | 16th cheapest of 366 $3,977 a month | 341st of 366, with limits $13,140 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 This is what OpenAI Containers are built for, since the model runs its code in the same API call; Railway also fits short code runs and bills for CPU used. | 36th cheapest of 345 $413 a month | 194th of 345, with limits $6,000 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 gives each sandbox public HTTPS domains and SSH, but caps sandboxes per environment; an OpenAI container has no inbound access at all, only the API. | 42nd of 361, with limits $290 a month | 361st of 361, with limits $3,780 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 | 191st of 360, with limits $30,000 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 boot many from one checkpoint; OpenAI containers have no fork or snapshot, so each eval starts from the fixed image. | 108th of 364, with limits $364 a month | 360th of 364, with limits $5,760 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 need open internet and usually Docker; Railway has open internet and root, while OpenAI's code containers start with no internet and no documented Docker. | 113th cheapest of 377 $1,210 a month | 345th of 377, with limits $1,728 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 and SSH make it a workable dev box; OpenAI containers have no SSH and no persistent disk, while bochka sandboxes keep their disk for weeks. | 66th cheapest of 368 $89 a month | 362nd of 368, with limits $1,051 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; OpenAI has a hosted browser for computer use in the Agents API beta, and bochka streams a full 60fps desktop you can embed. | 77th of 369, with limits $103 a month | 351st of 369, with limits $5,280 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 | 328th of 367, with limits $1,440 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 | 328th of 346, with limits $1,755 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 | 311th of 338, with limits $35,100 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 | 308th of 360, with limits $870 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 | OpenAI Containers | bochka |
|---|---|---|---|
| What it is | An app platform that added sandbox VMs you create from a CLI or TypeScript SDK | A sandbox tool the model uses inside OpenAI's API | A cloud VM you create, keep, stop and reach from outside |
| Isolation | Sandboxes are isolated Linux VMs; app services are containers | A fully sandboxed virtual machine; hypervisor not named | Full VM with its own kernel on dedicated AMD Ryzen 9 9950X hosts |
| Root, Docker and nested virtualization | Root shell on Ubuntu; the sandbox docs do not mention Docker or /dev/kvm | Commands do not run with sudo; no Docker or /dev/kvm documented | Root, systemd, Docker and /dev/kvm on every machine |
| When the sandbox goes idle | Destroyed after the idle timeout (30 minutes by default, or never if set to 0); files survive only in checkpoints | Expires after 20 minutes without use and its data is discarded | You stop it; the disk is saved every minute and on stop, and a stopped sandbox costs nothing |
| Fork and checkpoints | Fork a running sandbox's filesystem; named disk checkpoints to boot new ones | No fork and no snapshots | Fork a running sandbox; named snapshots to start new ones |
| Custom image | Templates built from ordered steps (apt packages, env, commands) and cached | Fixed Debian 12 image; you upload files or skills into each container | Named snapshots of a set-up machine, reused as templates |
| Machine size | Up to 8 vCPU / 8 GB on Hobby, 32 vCPU / 32 GB on Pro | 1, 4, 16 or 64 GB of memory; vCPU not published | 4 vCPU / 8 GB by default, up to 16 vCPU / 32 GB |
| Reaching the sandbox | Up to 10 public HTTPS domains, set at creation; SSH and port forwarding | None; you reach the container only through the API | SSH, HTTPS URLs for up to 50 ports, token-protected; raw TCP |
| Outbound internet | Open internet | Code Interpreter and Hosted Shell: off until an admin sets an org domain allowlist; Agents API sandboxes: on by default | Open internet on every plan |
| Keeping API keys out of the sandbox | Secrets go in as environment variables, or are signed in and saved in a checkpoint | domain_secrets: a sidecar adds the real header for approved domains, the model sees a placeholder | Credentials proxy for model providers and any HTTPS API; 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 | Agents API (beta) drives a managed Codex harness from outside, with steering and events | Claude Code, Codex, OpenCode and more preinstalled, with a prompt, steer and events API |
| Desktop and computer use | Headless: terminal, exec and SSH only | Hosted browser for the Agents API computer_use tool | 60fps desktop and Chromium, computer use, embeddable stream |
| Apps and databases next to the sandbox | Deploy Postgres, Redis and services in the same project; a sandbox can join their private network | None; files go in and out through the API | No hosted databases; host your own inside a sandbox |
| Regions | US West, US East, Amsterdam and Singapore | US or EU processing for Code Interpreter; Agents API data residency in the US only | EU only: Germany, Finland, France |
Every feature Battleships tracks (43)
| Feature | Railway | OpenAI Containers | bochka |
|---|---|---|---|
| Full VM (own kernel) | Yes | Yes | 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 | Yes | Yes |
| Browser | Yes | Yes | Yes |
| Computer-use API | No | Yes | Yes |
| SSH | Yes | No | Yes |
| Persistent disk | Yes | No | Yes |
| Pause/resume | Yes | No | Yes |
| Automatic snapshots | No | No | Yes |
| Fork/clone | Yes | No | Yes |
| Live fork (no pause) | Yes | No | Yes |
| Memory fork | No | No | No |
| Custom image (Docker or snapshot) | Yes | No | Yes |
| ≥24 h sessions | Yes | Yes | Yes |
| Idle auto-stop | Yes | Yes | No |
| Wake on request | No | No | No |
| HTTPS preview URLs | Yes | No | 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 | No | 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 | Yes | 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 | No | 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 either. Railway and OpenAI Containers are not in StarSling's public CPU benchmark, and OpenAI does not publish how many vCPU each container size gets. bochka did 26.69 Node.js build-and-test runs per second at 4 vCPU / 8 GB in that benchmark.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Railway and OpenAI Containers 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 | OpenAI Containers, 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 | $228 · API pay as you go · with limits | $20 · $20/mo |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $70 · Hobby · with limits | $1,051 · API pay as you go · 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 | $739 · Hobby · with limits | $11,405 · API 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,620 · API pay as you go · 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 | $6,000 · API pay as you go · with limits | $2,000 · $2000/mo · with limits |
Railway: Railway bills sandboxes per second on CPU actually used and memory in use, plus outbound data, 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 numbers leave disk out.
OpenAI Containers: OpenAI bills each container session by the minute for the memory size you pick, with a 5-minute minimum, and model tokens are billed separately on top. There is no plan fee.
OpenAI Containers: 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
Neither cleanly fits the five scenarios. Railway is an app platform first with no published sandbox disk price, and 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. OpenAI Containers have no persistent disk, no Docker and no internet by default, and OpenAI does not publish how many can run at once. 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 | OpenAI Containers | 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
you want short-lived VMs with root and open internet next to apps and databases you already host on Railway, or you need US or Asia regions.
- A real machine with root and internet. Useful if your agent installs packages or calls outside APIs: a Railway sandbox is a VM with root, SSH and open internet.
- 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.
- Fork and checkpoints. Useful for evals and retries: fork a running sandbox's files or boot many new ones from one checkpoint.
Use OpenAI Containers when
your app already calls OpenAI models and the model only needs to run short pieces of code on files you give it, with a locked-down network.
- Built into the model call. Useful if your app already calls OpenAI models: one tool line in a request gives the model a place to run code.
- Locked-down network by default. Useful if code must only reach chosen hosts: Code Interpreter and Hosted Shell have no internet until an admin allows domains.
- Keys the model never sees. Useful when code calls approved APIs: a sidecar adds the real secret, and the model only sees a placeholder.
Where bochka fits
If your agents work for hours or days, neither fits cleanly: Railway destroys idle sandboxes and OpenAI discards a container after 20 idle minutes. bochka gives each agent a full VM that stops instead of disappearing, with Docker, a desktop, ports you can reach and coding agents you drive from outside.
A disk that stays
An agent waiting on a review loses its clone and installs when Railway's idle timeout or OpenAI's 20-minute expiry runs out. Railway's workaround is a timeout of 0, with memory billing until you destroy it; OpenAI has none.
Docker, systemd and /dev/kvm
Real repos need a database in Docker or an emulator. OpenAI runs commands without sudo and documents no Docker, and Railway's sandbox docs do not mention Docker or /dev/kvm, so you install and verify it yourself.
A desktop and agents you drive from outside
Railway sandboxes are headless and you parse each agent's exec output yourself. OpenAI drives only its own Codex harness. bochka has a 60fps desktop and a prompt, steer and events API for Claude Code, Codex and more.
Use bochka when your agents need a machine they keep: a full VM with Docker, a disk saved every minute, a desktop, ports you can reach and coding agents you drive by API. Compare it one to one: bochka vs Railway and bochka vs OpenAI Containers.
Questions people ask
Is Railway cheaper than OpenAI Containers?
In every scenario here, yes. One agent running all month comes to $70 on Railway and $1,051 on OpenAI, and 50 agents in parallel come to $739 against $11,405. OpenAI also bills model tokens on top, and Railway's numbers leave out disk, which it does not price.
Which is faster, Railway or OpenAI Containers?
Nobody can say yet: neither is in the public CPU benchmark, and OpenAI does not publish the vCPU behind each container size. bochka did 26.69 runs per second at 4 vCPU / 8 GB in that benchmark.
Can Railway or OpenAI Containers run Docker?
Railway gives a root shell, but its sandbox docs do not mention Docker. OpenAI's hosted shell runs commands without sudo and documents no Docker. bochka has root, systemd, Docker and /dev/kvm on every sandbox.
How long do Railway sandboxes and OpenAI containers last?
A Railway sandbox is destroyed after its idle timeout, 30 minutes by default, or never if you set it to 0. An OpenAI container expires after 20 minutes without use and its data is discarded. A bochka sandbox has no session cap on paid plans and keeps its disk when it stops.
Can I open a web app running inside the sandbox?
On Railway, yes: a sandbox can have up to 10 public HTTPS domains, plus SSH. OpenAI containers have no ports, URLs or SSH. bochka gives each sandbox HTTPS URLs for up to 50 ports, raw TCP and SSH.
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