Railway Sandboxes Are GA: The 3-Cent Agent Task and the Crossover Point for Self-Hosting

On September 17, 2026, Railway graduated Sandboxes from Priority Boarding to general availability on every plan. The headline feature is checkpoint-and-fork Linux VMs for coding agents, managed from a TypeScript SDK, a CLI, or the dashboard. But the part that deserves your attention is the meter: a 20-minute agent task averaging 1 GB of memory and 30 percent of one vCPU costs about 3 cents in compute, billed per second from the same credit pool as your production services. Run the arithmetic against a flat-rate dedicated box and the verdict lands early: below roughly 90 such tasks a day, Railway's meter wins; above it, an owned machine wins. The rest of this post is the receipt.

That crossover number is the thing most sandbox announcements never give you. Railway deserves credit here — its docs publish a worked example down to the cent, and the per-second rates check out when recomputed independently. What follows is the full picture: what the GA contract actually includes, what the meter rewards and punishes, and which primitive — fork — a self-hosted sandbox pool should copy first.

What the GA contract actually includes​

Sandboxes are isolated Linux VMs on an Ubuntu base with git, Node.js, npm, and four coding agents preinstalled: Claude Code, Codex, OpenCode, and Pi. You create one, run commands against it with exec, and destroy it when the task is done. The standard loop in Railway's docs reads create -> configure -> checkpoint -> create/fork -> verify -> destroy: prepare an environment once, snapshot it, then boot or fork as many copies as you need.

The GA contract, in table form:

Three details matter more than they first appear. First, the VM size is a ceiling, not what you are billed for — billing follows actual CPU used and memory in use, metered per second. Second, forks do not inherit the source's environment variables, idle timeout, or published domains, so each branch starts clean and must be configured deliberately. Third, a sandbox joins your environment's private network only if you opt into it, which means an agent can reach postgres.railway.internal directly — the sandbox is a peer of your production services, not a detached playground.

That last point is Railway's real differentiator in a crowded field. E2B, Vercel Sandbox (GA since January 2026), Daytona, and Modal all sell isolated compute for agents. Railway sells isolated compute attached to your existing Railway environment, drawing from the same included usage credits. The sandbox is not a separate product with a separate bill; it is another consumer on the meter you already have.

The meter, line by line​

Sandboxes bill at Railway's VM rates, which are steeper than its container-service rates:

Memory is measured in use while running, and it includes the operating system and filesystem cache — the idle floor is never zero. CPU is what the sandbox actually used. Per-second granularity means a task that runs 20 minutes costs exactly 20 minutes of resource consumption, not a rounded-up hour.

Railway's worked example: a sandbox running a 20-minute agent task, averaging 1 GB of memory and 30 percent of one vCPU, costs about 3 cents. Recomputing from the published per-second rates ($0.00001929 per vCPU-second, $0.00000001929 per MB-second) gives 1,200 seconds × (1,024 MB × $0.00000001929 + 0.3 × $0.00001929) ≈ $0.0307. It checks out, and 50 such tasks land at about $1.50, exactly as documented.

The meter rewards one behavior above all: destroy fast. The docs say it three ways — destroy sandboxes when the work is done (await using in the SDK does it for you), keep the idle timeout short unless a workflow needs the gap, and use checkpoints for state you reuse instead of keeping a sandbox alive between runs. The reason is the memory line: an agent waiting on a model response or a human approval burns little CPU but keeps holding gigabytes, and held memory bills at $50 per GB-month whether anything is computing or not. A sandbox parked overnight "just in case" is the most expensive way to store a filesystem that a checkpoint holds with no listed meter of its own.

The crossover math: tasks per day vs a flat-rate box​

Take Railway's own 20-minute, 3-cent task as the typical unit and scale it across a 30-day month against an 8-core, 64 GB Hetzner-class dedicated box at roughly $85 a month:

The lines cross near 90 tasks a day — about 2,800 tasks a month. Below that, per-second metering on shared infrastructure is dramatically cheaper than a machine of your own. Above it, the flat box wins and keeps winning, because its marginal cost per additional task is effectively zero while Railway's stays 3 cents forever.

The included credits redraw the low end further. A $5 Hobby plan covers roughly 167 such tasks a month before metered billing kicks in; a $20 Pro plan covers roughly 667. But those credits are shared with your production services, so the sandbox headroom is whatever your apps leave behind — a team already spending its Pro credit on serving has no free agent tasks at all. Shared credits simplify the bill and muddy the accounting in equal measure: agent experimentation quietly eats the budget your services were sized against, and nothing itemizes which consumer crossed the line first.

Two caveats keep this honest. First, the 20-minute task is Railway's example, not a law of nature. Shorter tasks favor Railway more (per-second billing shines under ten minutes); tasks that hold 4 GB while waiting on a slow model cost roughly 12 cents, not 3, and pull the crossover down toward 25 tasks a day. Size your own unit before trusting anyone's table. Second, the $85 box excludes the engineering time to build and operate the equivalent — snapshots, scheduling, networking, reaping — which is the subject of the checklist two sections down. The crossover table prices compute, not labor.

Fork is the primitive worth copying​

Checkpoint and fork look similar and serve different jobs. A checkpoint is a named snapshot of a sandbox's disk, stored server-side; the source sandbox can be long destroyed when you boot from it. A fork clones a running sandbox's filesystem into a new, independent sandbox right now. Both boot fresh — files survive, running processes and memory do not.

That disk-only semantics is the honest gap. E2B's pause and resume captures filesystem, memory, and processes, resumes in about a second, and stops billing while paused — a true suspend. Railway's checkpoint preserves the filesystem and nothing else; a half-finished test run, a warm model in VRAM, or an SSH agent's in-memory state does not survive the round trip. For the canonical agent loop — install dependencies once, snapshot, then run many independent attempts — disk-only is exactly sufficient. For long-lived interactive sessions, it is not a substitute for keeping the machine alive.

The pattern to copy is fork-as-eval-harness: prepare one base (dependencies installed, repo checked out, tools configured), checkpoint it, then fork per attempt and keep only the winners. Each attempt is isolated, reproducible from the same base, and disposable. It is the agent-era version of a build matrix, and it is the primitive a self-hosted sandbox pool should implement first — before fancy scheduling, before GPU support, before multi-tenancy. Everything else in the sandbox market (templates, snapshots, idle reaping) is an optimization of this loop; the loop itself is the product.

A self-hosted implementation has real options. Firecracker supports full and differential microVM snapshots with millisecond-scale resume, and it is the engine underneath E2B, Vercel Sandbox, and AWS's agent runtime. E2B itself is open source with a self-hosted enterprise path. What none of them give you for free is the orchestration: the snapshot store, the fork scheduler, the per-second metering, and the private-network attach that makes a sandbox a peer of production rather than a stray VM.

The build-vs-buy checklist for a self-hosted pool​

If your volume sits above the crossover and you are tempted by the flat box, here is what matching Railway's GA contract requires you to build or borrow:

• Snapshot store. Named, content-addressed disk snapshots with fast copy-on-write restore. This is the checkpoint primitive; without it you are re-running npm install per task.
• Fork scheduler. Rate-limited, concurrent sandbox creation with per-environment caps, so one runaway agent loop cannot fork-bomb the fleet.
• Private-network attach. Sandboxes must reach tenant databases over a private network without exposing every sandbox to every tenant. Railway's isolated-by-default, opt-in-private model is the right default to copy.
• Idle reaping. Automatic destruction after a configurable idle window, with keepalive semantics for genuinely long tasks. The 30-minute default exists because humans forget to destroy things.
• Per-second metering. Even if you never bill for it, you need per-task cost attribution — otherwise agent spend hides inside the flat box exactly the way it hides inside Railway's shared credits.
• Prebuilt bases. Maintained images with current agent CLIs and toolchains, rebuilt on a cadence. Stale bases silently become the slowest part of every task.

None of this is exotic, but all of it is operations. A fair fully-loaded comparison adds on-call time, base-image maintenance, and the week you will spend debugging snapshot restore the first time it corrupts. Teams with a platform engineer and steady agent volume clear this bar easily; teams running 30 tasks a day do not, and should stay on the meter.

Shared credits are the real product decision​

Step back from the price table and the interesting move is not checkpoint or fork — it is that sandbox usage draws from the same included credit as production services. Every other sandbox vendor bills agent compute as its own line item; Railway blends it into the number you already pay. That is genuinely convenient at low volume and genuinely opaque at high volume, because the bill stops telling you what fraction of your infrastructure spend is agents experimenting versus apps serving.

The same changelog that announced GA also let Railway Agent run on your own ChatGPT subscription and brought point-in-time recovery to MySQL — the direction of travel is unmistakable. Agent compute is being folded into the platform as a first-class workload, metered like any other. Whether you buy that compute from Railway or provision it on machines you own, the discipline is the same: meter agent tasks separately, destroy aggressively, and checkpoint instead of idling. The teams that learn those habits on someone else's meter will be the ones ready to run their own.

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.