Railway vs Azure Container Apps Sandboxes
Railway is an app platform whose sandboxes are Linux VMs that sit next to your apps and databases and are destroyed when they go idle. Azure Container Apps Sandboxes are microVMs inside your Azure account that suspend with their memory and wake again on traffic.
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.
Azure Container Apps Sandboxes
Azure Container Apps Sandboxes is a service inside Microsoft Azure that gives each agent or user an isolated microVM you create, suspend and resume through an SDK.
It is part of Azure Container Apps, the hyperscaler's serverless container platform, and lives in your Azure subscription as a sandbox group resource. Each sandbox boots from an OCI image or a snapshot, has its own kernel, and can be suspended with its memory and resumed in under a second. It is built for teams already on Azure that want stateful code execution with Azure networking, identity and billing.
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 | Azure Container Apps Sandboxes: price rank | boat: price rank |
|---|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month A software factory needs machines that keep their work for hours; Railway destroys idle sandboxes, Azure lacks SSH and /dev/kvm, and boat keeps the disk with Docker and a desktop. | 51st of 367, with limits $342 a month | 288th of 367, with limits $5,276 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 Railway with the idle timeout set to 0, while Azure bills a running sandbox every second and needs a savings plan commitment to get close. | 16th cheapest of 366 $3,977 a month | 302nd of 366, with limits $6,544 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 and Azure are close for short code runs: Railway bills for CPU used and destroys the sandbox after, while Azure suspends it with its memory and resumes in under a second. | 36th cheapest of 345 $413 a month | 34th cheapest of 345 $354 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 Azure fits sandboxes for your users fully, suspending idle ones with their memory; Railway caps sandboxes at 100 per environment on Pro, and boat gives each user hosting on up to 50 ports. | 42nd of 361, with limits $290 a month | 22nd cheapest of 361 $2,260 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 | 153rd of 360, with limits $10,740 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 Azure fits agent evals fully, since a snapshot of a running sandbox with its memory can seed many new ones; Railway forks the filesystem only, and caps how many run per environment. | 108th of 364, with limits $364 a month | 75th cheapest of 364 $1,728 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 that builds containers needs Docker: Railway's sandbox docs do not mention it, Azure ships it only in some images like azure-dev, and boat has it on every machine. | 113th cheapest of 377 $1,210 a month | 103rd cheapest of 377 $1,046 a month | 4th cheapest of 377 $86 a month |
| 24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB Railway can host a dev box that stays up, and Azure has no SSH, only a shell through its CLI and portal; boat gives every sandbox SSH and a disk that is kept when it stops. | 66th cheapest of 368 $89 a month | 322nd of 368, with limits $262 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 Both Railway and Azure sandboxes are headless, so computer-use agents fit only as a compromise there; boat streams a Linux desktop at 60fps. | 77th of 369, with limits $103 a month | 279th of 369, with limits $1,573 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 | 288th of 367, with limits $795 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 | 284th of 346, with limits $561 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 | 239th of 338, with limits $10,956 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 | 278th of 360, with limits $517 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 | Azure Container Apps Sandboxes | boat |
|---|---|---|---|
| Isolation | Sandboxes are isolated Linux VMs; app services are containers | MicroVM per sandbox with its own kernel | Full VM with its own kernel on dedicated AMD Ryzen 9 9950X hosts |
| When the sandbox goes idle | Destroyed after the idle timeout (30 minutes by default); files survive only in checkpoints you take | Auto-suspends after an idle timeout (5 minutes by default) with memory and disk; traffic or a start command wakes it in under a second | Auto-stop timer you set; the disk is kept, with snapshots every minute and on stop, and a stopped sandbox costs nothing |
| Docker inside | Root shell on Ubuntu; the sandbox docs do not mention Docker | Depends on the image: azure-dev ships Docker on systemd; the default ubuntu image has only Buildah | Docker, systemd and root on every machine |
| Nested virtualization | Not mentioned in the sandbox docs | Not documented | Yes, /dev/kvm for Android emulators and VMs |
| Shell and inbound access | SSH and port forwarding; up to 10 public HTTPS domains, set only at creation | Shell through the aca CLI, SDK or portal, no SSH; public HTTPS routes per published port, no public IP | SSH, HTTPS URLs for up to 50 ports, token-protected, raw TCP and a dedicated IPv4 or IPv6 |
| Fork and snapshots | Fork a running sandbox's filesystem; named disk checkpoints to boot new ones (no memory) | Snapshot a running sandbox with its memory and create new sandboxes from it | Fork a running sandbox with its disk; named snapshots to start new ones (no memory) |
| Coding agents | Claude Code, Codex, OpenCode and Pi preinstalled; run headless through exec | Copilot CLI and Claude Code images, run through the exec API | Seven agents preinstalled, with a prompt, steer and events API |
| Keeping AI keys out of the sandbox | Secrets live in the sandbox as environment variables, or are signed in and saved in a checkpoint | Group secrets usable in egress header rules; Copilot and Anthropic tokens are injected into the sandbox at startup | Credentials proxy for model providers and any HTTPS API; switch a credential to another account when credits run out |
| Desktop and computer use | Headless: terminal, exec and SSH only | Headless; no desktop or managed browser | Linux desktop streamed at 60fps, Chromium and computer-use tools preinstalled |
| Outbound rules | Open internet; no egress allowlist for sandboxes | Egress policy with allow, deny, rewrite and header rules by host, path and method; VNet integration | Open internet, no provider-side allowlist |
| Apps and databases nearby | Postgres, Redis and services in the same project; a sandbox can join their private network | Lives in your Azure subscription; a sandbox group can join your Azure VNets | Sandboxes only; host your own services inside a VM |
| Biggest sandbox | 8 vCPU / 8 GB on Hobby, 32 vCPU / 32 GB on Pro | Tiers up to 4 cores / 8 GB; up to 16 vCPU / 32 GB by API | 8 vCPU / 16 GB on the $20 plan, 16 vCPU / 32 GB from $100 |
| Sandboxes at once | 50 per environment on Hobby, 100 on Pro; Enterprise can ask for more | 500 concurrent active cores by default; more by Azure support request, which can need review | 100 to 2,000 by plan, self-serve |
| Regions | US West, US East, Amsterdam and Singapore | 40 Azure regions, 9 of them in the EU | EU only: Germany, Finland, France |
Every feature Battleships tracks (43)
| Feature | Railway | Azure Container Apps Sandboxes | boat |
|---|---|---|---|
| Full VM (own kernel) | Yes | Yes | Yes |
| Docker inside | Not published | Yes | Yes |
| Nested virtualization | No | No | Yes |
| Root | Yes | Yes | Yes |
| Systemd | Not published | Yes | Yes |
| Desktop GUI | No | No | Yes |
| Browser | Yes | No | Yes |
| Computer-use API | No | No | 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 | Yes | No |
| Wake on request | No | Yes | No |
| HTTPS preview URLs | Yes | Yes | 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 | Yes | Yes |
| Agent harness API | Yes | No | Yes |
| MCP server | Yes | No | No |
| GPU | No | No | No |
| Windows | No | No | No |
| Arm64 | No | No | 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 | Yes | Yes |
| Usage per sandbox (API) | No | Yes | Yes |
| Audit logs | Yes | Yes | 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 Azure Container Apps Sandboxes. boat did 26.69 Node.js build-and-test runs per second at 4 vCPU / 8 GB in StarSling's public benchmark, on dedicated AMD Ryzen 9 9950X hosts. Until the other two are measured on the same test, this page makes no speed claim.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Railway and Azure Container Apps Sandboxes 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 | Azure Container Apps Sandboxes, a month | boat, 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 | $68 · 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 | $262 · 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 | $3,421 · Pay-as-you-go | $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 | $989 · 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,148 · 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, 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 bills leave it out.
Azure Container Apps Sandboxes: Azure bills per second on the Container Apps Consumption meters for the vCPU and memory of the sandbox's tier while it runs, idle time before auto-suspend included. There is no plan fee, and some regions such as West Europe charge more per second.
Azure Container Apps Sandboxes: Plans start at $20 a month, and the whole fee 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, and its cap of 100 sandboxes per environment on Pro blocks 300 user sandboxes or 1,000 jobs at once without several environments. Azure fits most scenarios, but the always-on agent only gets close with a 3-year commitment, and its default quota of 500 active cores caps a fleet until support raises it. For the agent fleet, Docker on Azure means picking an image that ships it, like azure-dev. On boat, 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 | Azure Container Apps Sandboxes | boat |
|---|---|---|---|
| One coding agent, workdays |
| None that bite | None that bite |
| One agent that never stops |
|
| 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 Railway when
your app and databases already live on Railway and you want short-lived sandboxes on the same private network, with SSH and up to 32 vCPU in one machine.
- Sandboxes next to your apps. Useful if your app already runs on Railway: a sandbox can join the private network of your Postgres and services.
- SSH and big machines. Useful when you want to SSH in or need up to 32 vCPU / 32 GB in one sandbox on Pro.
- Short jobs that bill for CPU used. Useful for many quick code runs: CPU is metered on what a sandbox uses, and it is gone when the job ends.
Use Azure Container Apps Sandboxes when
your team already runs on Azure and wants sandboxes that suspend with their memory, wake on traffic, sit behind strict egress rules, or run in many regions.
- Suspend with memory, wake on traffic. Good for stateful jobs that sleep between requests: a sandbox suspends with its memory and resumes in under a second.
- Fine-grained outbound rules. Its egress policy can allow, deny or rewrite each outbound request by host, path and method, with VNet integration.
- Inside Azure, in 40 regions. Teams already on Azure get Entra ID, Azure billing and their own VNets, in 40 regions on six continents.
Where boat fits
Railway and Azure both shine at short jobs: Railway destroys a sandbox when it goes idle, and Azure suspends it with its memory. If your agents work for hours or days and need a whole computer, with Docker, a desktop and SSH, boat gives each one a full VM that keeps its disk. It also comes with coding agents you drive from outside and keys that stay out of the sandbox.
A disk that stays, with no idle clock
Railway destroys a sandbox 30 minutes after it goes idle unless you took a checkpoint, and Azure bills every running second until it suspends. boat saves the disk every minute and on stop, and a stopped sandbox costs nothing.
A whole computer: Docker, KVM, SSH and a desktop
Neither documents /dev/kvm, both are headless, and Azure has no SSH while Railway's docs do not mention Docker. Agents that run emulators or test in a real browser must build that stack themselves there; boat ships it with a 60fps desktop.
Agents driven from outside, keys kept outside
On Railway and Azure you run Claude Code through raw exec and parse its output, and its token sits inside the sandbox where injected code can read it. boat adds a prompt, steer and events API and a credentials proxy.
Use boat when your agents work for hours or days and need a whole computer: a full VM that keeps its disk, with Docker, /dev/kvm, SSH, a desktop, and coding agents you drive from outside. Compare it one to one: boat vs Railway and boat vs Azure Container Apps Sandboxes.
Questions people ask
Is Railway cheaper than Azure Container Apps Sandboxes?
In our scenarios Railway's bills are lower, but they count CPU and memory only, since Railway does not price sandbox disk. One agent running all month comes to $70 on Railway and $262 on Azure, and 50 agents in parallel to $739 against $3,421. boat comes to $26 and $317 for the same two.
Which is faster, Railway or Azure Container Apps Sandboxes?
We cannot say. Neither has a result in StarSling's public benchmark yet, where boat did 26.69 runs per second at 4 vCPU / 8 GB.
Can I run Docker inside Railway or Azure sandboxes?
Railway's sandbox docs do not mention Docker. On Azure, the azure-dev image ships Docker on systemd, while the default ubuntu image has only Buildah. boat runs Docker on every sandbox and also exposes /dev/kvm.
Can I SSH into a Railway or Azure sandbox?
Railway supports SSH and port forwarding into a sandbox. Azure does not: you get a shell through the aca CLI, the SDK or the portal. Every boat sandbox has SSH.
What happens when a sandbox goes idle?
Railway destroys it after the idle timeout, 30 minutes by default, so you keep files only through checkpoints. Azure suspends it after 5 minutes idle by default, with its memory, and wakes it on traffic. boat stops it on a timer you set, keeps the disk and charges nothing while it is stopped.
Is boat SOC 2 compliant?
SOC 2 is in progress. We're open about where we stand: live status at status.ascii.dev and our data retention policy at docs.boat.dev/data-retention.
Try boat
Install the CLI, then run boat new.
7-day free trial