Railway Sandboxes vs Fly Sprites (2026): What Hosted Agent Isolation Costs — and the Apache-2.0 Alternative

Two PaaS vendors looked at the same problem in 2026 — coding agents need a computer they are allowed to break — and shipped opposite answers. Railway made the sandbox a disposable Linux VM wired into your project's private network: create it in code, run the agent, checkpoint the disk, throw the box away. Fly made the Sprite a persistent computer: a Firecracker microVM with 100 GB of disk that falls asleep when idle and wakes with everything intact. Both bill by the second, both sell isolation as an API call, and both are dramatically more expensive per active hour than the owned hardware underneath them.

Here is the whole comparison up front, priced for the same 2 vCPU / 4 GB sandbox shape:

The rest of this post substantiates every cell: what each vendor actually shipped, the per-minute rates behind the math, the five-primitive pattern both converged on, and the open-source stack that reproduces it on machines you own.

What Railway shipped: sandboxes as a project primitive​

Railway's June 2026 launch — "Railway over SSH, agents in Sandboxes, private networking in the CLI" — moved agents-in-sandboxes into Priority Boarding with the product framed exactly as the docs still put it: full Linux VMs you create in code, wire into your project's private network, checkpoint, fork, and throw away. A sandbox is scoped to a Railway environment, not floating free: it inherits the project's region and can resolve project services over the private network.

Three design choices define the experience. First, six coding agents come preinstalled, so the loop is create → exec → checkpoint without building a runner image. Second, persistence is disk-only: checkpoint(name) captures a named, bootable disk snapshot, and fork() clones that filesystem into a fresh sandbox — live processes and RAM do not survive either operation. Third, networking is a dial: ISOLATED keeps the box off your project network, PRIVATE attaches it so the agent can reach real databases and internal services with no tunnel plumbing. That last option is also the threat model — I previously worked through the credential blast radius of six agents on a private network, and the short version stands: pairing a ${{Postgres.DATABASE_URL}} reference with private networking hands the agent the production database, so checkpoint images built from private-network runs deserve the same secret hygiene as any other artifact.

The billing is per-second on resources actually consumed. The published sandbox rates are $0.001157 per vCPU-minute, $0.001157 per GB-minute, and $0.05 per GB of egress — roughly $50 per vCPU-month and $50 per GB-month if you ran flat out. Forgotten sandboxes destroy themselves on an idle timeout (30 minutes by default, up to 120 or disabled on paid plans), and concurrency is capped per environment: 10 on trial, 50 on Hobby, 100 on Pro. Destroyed sandboxes cost nothing, which makes Railway's idle story the simplest of the three: there is no idle, only alive or gone.

What Fly shipped: the Sprite as a persistent computer​

Fly went the other direction six months earlier. Sprites, launched in January 2026 on the same Firecracker microVM substrate as Fly Machines, are pitched as persistent Linux computers for agents rather than ephemeral sandboxes — CEO Kurt Mackey's launch argument was that forcing agents to rebuild their environment on every run is pure waste. Each Sprite carries 100 GB of persistent NVMe, checkpoints in about 300 ms, restores in under a second, and puts itself to sleep after roughly 30 seconds idle: warm wake in 100–500 ms, cold start in one to two seconds, state intact either way.

The agent interface is broader than Railway's. There are first-party SDKs for JavaScript, Python, Go, and Elixir against api.sprites.dev, a sprites.dev/mcp hosted MCP server with OAuth (documented under remote MCP), and an official Claude Code plugin — plus a published Codex recipe whose premise is the whole category in one sentence: give Codex full access and let the Firecracker boundary, not the agent's restraint, be the safety property.

Billing follows actual CPU and RAM use while active: $0.07 per CPU-hour and $0.04375 per GB-hour, with zero compute charge in either sleep state and a $30 trial credit. An optional subscription tier bundles concurrent Sprites with included hours for steadier use. The honest footnote is that hosted is still someone else's control plane: on October 8, 2026, Sprite creation failed platform-wide for 31 minutes. Persistence also changes the failure mode — a corrupted persistent disk is worse than a dead ephemeral box, which is an argument for checkpointing Sprites the way Railway forces you to checkpoint sandboxes.

The packaging pattern: five primitives​

Strip away the branding and both vendors converged on the same five-primitive API for isolation-as-a-product. If you are evaluating any sandbox offering — or building one — this is the checklist:

1. Create — one call provisions an isolated Linux machine (scoped to a project/environment on Railway, standalone with an identity on Sprites).
2. Exec — run shell commands or an agent loop inside it, streaming output, with timeouts and background processes.
3. Checkpoint — capture a named, reusable snapshot. Railway's is disk-only; Sprites' persistent disk plus sub-second checkpoints is the stronger version.
4. Fork/clone — stamp N identical boxes from a checkpoint for parallel agent runs.
5. Sleep/resume or destroy — stop paying for idle. Railway destroys (state only via checkpoint); Sprites sleep with disk and fast wake.

Everything else — preinstalled agents, private networking, MCP endpoints, trial credits — is distribution. The moat question for 2026 is whether these five primitives stay a hosted product or become boring infrastructure, and the open-source side of that question moved fast this year.

The worked math: where hosted wins and where it loses​

Same spec throughout: 2 vCPU / 4 GB, the smallest shape you would actually give a coding agent.

An active hour costs ~$0.42 on Railway (6 billable units × $0.001157 × 60 minutes) and ~$0.32 on Sprites (2 × $0.07 + 4 × $0.04375). For context, the sandbox-only vendors price the same active hour lower: about $0.17 on E2B-class Firecracker, per a 2026 seven-way comparison — I compared those three directly earlier this month. The PaaS packaging (project networking on Railway, persistence on Sprites) roughly doubles the active-hour price over bare sandbox compute. Run flat out for a 730-hour month and the totals are ~$300 (Railway) and ~$230 (Sprites).

Now the owned side. Hetzner's official price list puts an AX41-class dedicated box (6 cores, 64 GB RAM, NVMe) at €57.30/month. That box comfortably hosts ten concurrent 2 vCPU / 4 GB sandboxes, which is about €6 per always-on sandbox slot per month — roughly a fiftieth of the hosted always-on totals. The breakeven falls out directly: one sandbox crosses the cost of its owned slot after ~15 active hours a month on Railway pricing, ~20 hours on Sprites pricing.

So the decision rule is about duty cycle, not ideology:

• Spiky, idle-heavy agent use (a few assistant sessions a week, long pauses between runs): hosted wins. Railway's destroy-on-idle and Sprites' zero-compute sleep mean you pay nearly nothing between sessions, with no box to operate.
• Sustained fleet use (CI agents, always-warm harnesses, a team of developers each with a live box): owned wins by an order of magnitude once any given sandbox is warm more than about an hour a day — and the gap widens with concurrency, since the tenth concurrent sandbox on your own box is free while the tenth hosted one is full price.

Two caveats keep this honest. First, hosted bills actual CPU-used, so a bursty agent that thinks more than it compiles lands well under the flat-out math — the $0.42/$0.32 figures are ceilings, not averages. Second, the Hetzner comparison uses shared-cloud or self-operated dedicated capacity, which trades per-slice performance isolation and zero ops for price. Egress is the line item most likely to surprise on either hosted bill ($0.05/GB on Railway); agents that npm install the world on every fresh box should be forking from a checkpoint with dependencies baked in.

The Apache-2.0 fleet: what runs instead on owned hardware​

None of the five primitives above requires a hosted vendor. The self-hosted stack in 2026 has three layers, all Apache-2.0:

The orchestrator: kubernetes-sigs/agent-sandbox. This SIG Apps subproject, introduced on the Kubernetes blog in March 2026, is the closest thing to a standard sandbox API on your own cluster: Sandbox, SandboxTemplate, SandboxClaim, and SandboxWarmPool CRDs that run on any conformant Kubernetes. Templates decouple the workload from the isolation backend (plain runc, gVisor, or Kata via runtimeClassName); warm pools hand out pre-booted sandboxes for sub-second assignment; the controller handles pause/hibernate with automatic resume on network activity plus pod snapshots for save/restore. It is the create/exec/checkpoint/fork/sleep surface, expressed as YAML instead of a vendor SDK.

The strong-isolation option: self-hosted E2B. E2B's Firecracker-microVM infrastructure is Apache-2.0 and self-hostable, with pause/resume preserving filesystem and memory and billing that stops while paused. The price of admission is operational: the reference deployment runs on Nomad and Consul, which is a real infrastructure project, not a Helm chart. Choose it when the sandbox runs genuinely adversarial, multi-tenant code and you want a dedicated kernel per session; choose agent-sandbox with Kata when VM-grade isolation inside your existing Kubernetes is enough.

The primitives underneath. Firecracker for microVMs, gVisor for a user-space kernel without hardware virtualization, Kata Containers for VM-grade pods — the same trio every hosted vendor is built on. Day-long spikes that exceed your box? Burst to a hosted vendor per second and keep the base load owned; the checkpoint/fork pattern works the same way in both places.

One cautionary tale belongs here. In June 2026, Daytona archived its open-source repository and moved core development to a private codebase, ending at v0.190.0 under AGPL-3.0 — and a community fork appeared within weeks. "Open core, hosted default" is a licensing strategy, not a guarantee; if the self-host path matters to you, prefer components whose license and governance survive their vendor's strategy change. Apache-2.0 projects under neutral governance (CNCF, Kubernetes SIGs) clear that bar; single-vendor open cores need a fork contingency in the runbook.

What hosted still buys you​

The honest close: most teams should start hosted. Operating Firecracker at multi-tenant density, tuning warm pools, patching node images, and answering 3 a.m. pages for sandbox control planes is a platform team, not a side quest — and both Railway and Sprites price the first hundred active hours cheaply enough to learn what your agents actually need. Railway is the better default when the agent must touch your real project infrastructure (private networking is the feature); Sprites is the better default when the agent needs a long-lived computer with state (persistence plus sleep is the feature).

But know what the meter is teaching you. The month your hosted sandbox bill crosses the price of a dedicated box you could have amortized it across, you are no longer paying for isolation — you are paying to avoid operating it. That is a fine trade right up until it isn't, and the Apache-2.0 stack above is what the other side of the crossover looks like.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.