Railway Built an Agent-Execution Cloud in Six Changelogs — Here's the Open Stack That Replicates It

Between June 5 and July 10, 2026, Railway shipped a closed agent-execution cloud in six changelog entries: sandboxes, Docker inside them, a file API, checkpoints, preinstalled coding agents, SSH-as-front-door, and a Slack/Discord agent to steer it all from chat. On September 18 it went generally available. Now that the shape has settled, the interesting question isn't whether Railway's stack is good — it's what each primitive is actually for, and which open parts compose into the same thing on machines you own.

Here is the short version up front. The timeline of what shipped:

And here is the full replication map — each primitive, the job it does, and the open equivalent. The rest of this post is the evidence for every row.

What each primitive is actually for​

The isolation unit is a Linux VM — but the network mode matters more than the VM. At GA, Railway describes sandboxes plainly as isolated Linux VMs. The non-obvious decision is the two network personalities.

A default sandbox gets internet only, with no route to the rest of your project — safe enough to run images you don't trust. Pass --private-network and the same sandbox joins your environment's private network, reaching Postgres, Redis, internal services, and variables. That split is the whole security model: untrusted execution and trusted integration are the same box with a different network attachment.

If you copy the sandbox but flatten the two modes into one, you've missed the point — and the credential blast radius that comes with the private mode deserves its own threat model.

Templates, checkpoints, and forks are three different answers to "don't redo setup." Railway's vocabulary is precise here. A template is a build recipe (packages, env vars, working directories, commands) that lives in the local store of the machine that built it.

A checkpoint is a named, bootable disk snapshot of a running sandbox, captured synchronously and stored server-side so any machine can boot from it — and it outlives the sandbox it came from. A fork is a live branch of a running sandbox for trying approaches in parallel. Caps are per environment by plan: 10 named checkpoints on Trial, 50 on Hobby, 100 on Pro.

The canonical loop from Railway's own blog post is: build a base template once, create, configure (sign into agents, write guidance files, seed variables), checkpoint the prepared state, then fan out one sandbox per agent. Their Repo Review Agent example boots four sandboxes from one repo-ready checkpoint for tests, architecture, security, and polish. Templates are for recipe reuse, checkpoints are for state reuse, forks are for parallel attempts — conflating them is the most common mistake in homegrown sandbox tooling.

Docker-in-sandbox turns the box into container-shaped work without a deploy. Every sandbox runs its own Docker daemon: pull images, run Postgres or Redis next to the code under test instead of mocking them, build the same image you ship to production and verify it starts. Before this, running a container on Railway meant deploying a service.

The design decision worth noting is that Docker arrived without private networking — containers in the sandbox can't reach the rest of your project. Stateful dependencies for tests, yes; a back door into production, no.

File API, exec, and SSH are three doors into the same box, for three different callers. The TypeScript SDK's sandbox.files API (read, write, list, stat, mkdir, rename, remove — streamed and resumable) exists so programs can move files without shell-quoting them through exec. Exec exists so scripts and agents can run commands.

And SSH — ssh sandbox@railway.new — exists so that nothing needs to be installed at all. That last one is the agent-onboarding hack: a CLI has to be installed, an MCP server has to be configured, and OAuth needs a browser an agent can't drive. SSH is a plain shell command with the key as the credential, so an agent can go from zero to a working sandbox in one command — structured output for agents and an interactive app for humans on the same front door.

Preinstalled harnesses make the default image a distribution channel. Six coding agents ship in the sandbox image: Claude Code, Codex, Cursor, Droid, OpenCode, and Pi, plus git, Node, npm, and mise for toolchain management. (The June 24 blog post announced four; the June 26 changelog brought it to six; GA messaging names four again — the roster clearly moves with partnerships.)

The insight is that "which agent" stopped being an install step and became a default. Nobody wants to spend the first minutes of every session installing the same harness twenty different ways.

The Slack/Discord agent is the human-in-the-loop hand-off. Mention @Railway to ask about projects, inspect deployments, read logs, and make changes without leaving chat. Setup has two halves — a workspace admin links the chat platform, then each teammate links their chat identity to their Railway account.

The agent checks the caller's personal access level on every message, and leaving the workspace silences it immediately. That per-message identity check is the load-bearing detail: a chat agent without it is either underpowered (read-only for everyone) or a confused-deputy incident waiting to happen.

The open stack that replicates them​

Isolation: Firecracker microVMs you run yourself. E2B's pitch is the sandbox without the platform: every sandbox in its own Firecracker microVM with its own kernel, driven from open SDKs. The backend (e2b-dev/runtime) is Apache-2.0 and self-hostable with Terraform on GCP (AWS in beta).

Because a new sandbox is a snapshot restore, startup lands around 150 milliseconds. If you want Kubernetes-native instead, Kata Containers gives you VM-isolated pods behind a standard RuntimeClass — the same "own kernel per sandbox" property inside the scheduler you already run. Weaker options exist on purpose: gVisor's userspace kernel (what Modal and Beam use) or plain hardened containers (Daytona's default).

Pick the isolation your threat model needs; the point is that VM-grade sandbox isolation is a commodity part, not a moat.

State capture: snapshots yes, Kubernetes-native restore no. This row has the sharpest honest gap in the table. Firecracker snapshots do the checkpoint job well: E2B's pause saves filesystem and memory state, resumes in about a second, and a paused sandbox is kept indefinitely.

But if you want checkpoints inside Kubernetes itself, the story is thinner. The kubelet Checkpoint API (KEP-2008) went alpha in v1.25 and beta in v1.30, delegating to CRIU through containerd — and there is still no restore API. Checkpoint exists; restore is a manual exercise, and a dedicated working group only stood up in January 2026 to formalize it.

We did the math on what pausing a mid-task agent sandbox actually saves back in August; the conclusion stands. Budget for snapshot-based (Firecracker) state capture today, and treat K8s-native restore as roadmap, not inventory.

Docker-in-sandbox, the file API, and exec: all commodity. Docker-in-Docker inside a microVM is a solved recipe. For the programmatic doors, you have three open SDK shapes: E2B's SDKs against your self-hosted runtime, Daytona's SDK for workspace creation plus file operations and process execution (with VM and Windows classes beyond its default containers, and ~200ms startup claims), or AgentENV.

AgentENV is a self-hosted Firecracker runtime exposing an E2B-compatible HTTP API, so existing E2B SDK code works against it unmodified. The SSH front door is the most commodity row of all: plain OpenSSH plus first-boot provisioning. Railway's innovation there was product (the key is the credential, no install), not protocol.

Preinstalled harnesses: trivially replicable. This is just image baking. The agents are all downloadable CLIs; your base image can ship the same six, or a different six that match your team's subscriptions. There is no lock-in at this layer and no reason to treat the roster as a differentiator.

ChatOps: the genuinely hard row. Nothing single and open matches "@Railway with per-message identity checks." Assembling it means a chat bot, an agent runtime behind it, MCP or API tools scoped to least privilege, and per-user credential mapping with revocation that actually propagates when someone leaves.

The mechanism is unglamorous identity plumbing, and it's where self-hosted efforts most often ship the dangerous version: a shared bot token with one ambient identity. If you replicate one thing carefully, replicate this carefully — per-session identities, default-deny egress, approval-gated mutations, and auditable teardown are the controls that make a chat-driven agent safe to aim at infrastructure.

The piece both sides are still missing​

Notice what neither Railway's six changelogs nor the open-parts map closes: the loop from sandbox experiment to deployed service. A sandbox is where the agent tries things; production is where the result runs.

Railway clearly sees the gap — the same June 5 changelog that launched sandboxes also shipped experimental Infrastructure as Code (railway config init/pull/plan/apply over a typed .railway/railway.ts), a typed source of truth an engineer or agent can review alongside code. That's the beginning of promotion-path thinking: the artifact that moves from experiment to production should be reviewable configuration, not a snowflake VM somebody checkpoints and prays over.

The open answer to that gap is the git-push PaaS. The sandbox produces a diff; the push produces a deployment. Experiment in an E2B-compatible microVM or a Kata-backed namespace, merge the result, and the platform builds, previews, and promotes it through the same pipeline a human's pull request would travel.

Agent execution stops being a separate world with its own lifecycle and becomes the front end of the deployment pipeline you already operate. That is the full composition: microVM or Kata isolation, snapshot-based state capture, and a git-push platform as the promotion path from sandbox experiment to deployed service. Run it, don't rent it.

What to run this week​

If you want the shape of Railway's stack on your own machines with the least assembly: stand up AgentENV or the self-hosted E2B runtime for Firecracker-backed sandboxes with pause/resume, bake one base image with your team's agent CLIs, front it with SSH, and keep the private-network split — internet-only by default, explicitly attached when the task needs your real services. Leave ChatOps for last; it's the only row where the integration work exceeds the parts cost.

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.