Railway's Q2 Changelog Is the Deploy-From-Chat Playbook: Sandboxes, SSH, and Private Networking in Dependency Order

In eight weeks, Railway shipped the full dependency stack for agent-driven deploys — and the order was not an accident. From May 1 to June 26, 2026, the changelog reads like a build plan discovered in production: first a standard transport agents can speak, then a disposable computer for the agent to work in, then agent-native onboarding and scriptable networking, with guardrails landing in the same quarter rather than as an afterthought. Nobody announced it as a roadmap. Read in sequence, it is one anyway.

That sequence is the point of this post. If you are building deploy-from-chat on infrastructure you own — a Cluster API fleet on Hetzner, a single-box PaaS, a GitOps pipeline with an agent on top — Railway already ran the experiment for you, on hosted infrastructure, with real users. Below is the quarter in one table, the dependency claim behind each step, and the build order it implies for a self-hosted platform.

The quarter in one table​

The thesis, stated up front: transport first, then isolation, then agent-native access and scriptable networking together. The isolate-first-then-access-then-networking order holds across the agent-facing primitives — the May 22 computer precedes the June 26 agent controls — and the last two co-ship because they are co-dependent: key-auth onboarding is pointless if the agent then cannot resolve anything, and --json networking output is pointless if no agent can reach a terminal to call it.

Standardize first: May 1 SSH was the prerequisite​

Before May, Railway had SSH, but only its own CLI could speak it: a custom protocol over a WebSocket relay, with no ~/.ssh/config, no SCP, no port forwarding. The May 1 entry replaced it with a standard SSH connection, and the CLI now shells out to the OS ssh client, picking up --session persistent tmux sessions, -i identity-file forwarding, PTY autodetection for interactive tools, and workspace-owned keys for CI.

Read the feature list closely and it is plainly human-facing: tmux sessions for flaky networks, remote vim and htop that just work, a dashboard button that copies a ready-to-paste command. Humans were the customer.

But the dependency claim runs the other way: nothing agent-facing later in the quarter could have shipped on the old protocol. June 26's entire pitch — "no CLI to install and no config to write," an agent running ssh sandbox@railway.new with nothing to set up — only works over stock ssh. A custom relay protocol means every new agent harness needs a bespoke integration; standard SSH means the client everyone already has is the front door. May 1 looks like a quality-of-life entry. It was load-bearing.

Isolate before agency: the May 22 sandbox​

Until late May, the Railway Agent could inspect projects, services, and deploys through tools, but it had no environment of its own. Changing a repo meant the human pasting code into the conversation, running things locally, and applying edits by hand. The agent suggested; the human typed.

The May 22 sandbox VM inverted that: filesystem, shell, and tools to clone a repository, read and write files, run commands in the foreground or background, and open a pull request — torn down when the conversation ends, so there is no long-lived environment to manage. The dependency claim: the sandbox had to precede agent-usable access, because a shell into your services before the agent owns a disposable computer means every mistake runs against production. Isolate first, then hand over the keys.

June 12 reads as sandbox maturation, and one detail deserves attention: Docker-enabled sandboxes shipped with deliberately no private-networking access — internet only, each sandbox running its own Docker daemon. Railway's own framing is that this makes sandboxes "a reasonable place to run images you don't trust," with destroying the sandbox removing everything. Isolation was the designed property, not a missing feature.

Only later, in the June 26 entry, do sandboxes reach the rest of the project over private networking so agents can work against real databases and internal services. Connectivity was granted after the isolation primitive matured — the same order, repeated one level down. Checkpoints (named, server-side, bootable snapshots, capped 10/50/100 by plan) and railway sandbox forward port multiplexing rounded out the loop: prepare once, fork many, work locally.

Access and networking, together on June 26​

June 26 is the payoff entry, and it ships the last two primitives as a pair. On the access side: ssh railway.new opens an interactive terminal app, ssh agent@railway.new drops straight into the agent conversation, and ssh sandbox@railway.new provisions a sandbox and hands back ready-to-run commands. First connection from a new machine returns a signup link to approve the SSH key; after that, the key is the credential — no token to paste, no browser flow to repeat. Railway's changelog states the agent case explicitly: a CLI has to be installed, an MCP server has to be configured, and an OAuth login needs a browser the agent cannot drive. None of that applies to ssh.

Every sandbox also ships with six coding agents preinstalled (Claude Code, Codex, Cursor, Droid, OpenCode, Pi) plus git, Node, npm, and mise, so no session starts with reinstalling the harness.

The dependency claim for access: ssh sandbox@railway.new could not ship before the sandbox primitive existed — it provisions one on connect, so without May 22 there is nothing to hand the agent — and it needed May 1's standard transport, since zero-install onboarding over a proprietary relay is a contradiction.

On the networking side, railway private-network status exposes a service's hostname, short name, DNS suffix, address family, and sync state, with --json for scripts and agents, while railway private-network update renames an endpoint with validation. Previously both were dashboard actions. The dependency claim for networking: scriptable internal DNS only pays off once non-humans are resolving endpoints every turn. A human clicks the dashboard twice a year to rename a service; an agent resolves hostnames every few tool calls.

Exposing this in June, after agents became first-class terminal users, is the order revealing itself again. Pair it with June 12's railway connect tunneling to private databases over SSH, and the pattern is complete: every private surface gained a terminal path in the same quarter agents learned to use terminals.

The guardrail thread underneath​

Agency never shipped alone. The same May 1 entry that delivered standard SSH also made API volume deletions soft-delete for 48 hours — matching a safety net the dashboard already had — after Railway watched an AI agent delete a production database using a long-lived account-scoped token it found on a developer's machine. The changelog's own moral is worth quoting in spirit: a human hesitates before a bad command, while an agent calls the next tool, which is why guardrails ship by default. May 22 added GitHub-organization deployment allowlists for enterprise workspaces, extending an existing guardrail pattern (previously: restrict domain generation, restrict TCP proxies) to deployment sources.

The lesson for the build order is that safety is not step six. Every capability entry in this quarter either shipped with its guardrail or followed within weeks. A deploy-from-chat platform that sequences "powerful agent tools now, safety review later" is not following this roadmap — it is repeating the incident that wrote it.

The build order for a self-hosted deploy-from-chat platform​

Translated off hosted infrastructure and onto machines you own, Railway's quarter prescribes five steps, in this order — transport before computer before controls:

1. Standard-protocol access first. Expose stock SSH with key-as-credential; no browser OAuth an agent cannot drive, no custom control channel only your CLI speaks. This step is cheap for self-hosted: OpenSSH already exists on your machines. You never built Railway's custom relay protocol, so you skip its May 1 migration and start where it ended up.
2. E2B-style sandbox second. Isolated execution before any agent agency: a disposable computer with a filesystem and shell, torn down when the task ends, internet-only until you deliberately grant more. Railway's May 22 entry is the spec — clone, edit, run, open a PR — and its June 12 internet-only default is the isolation posture to copy.
3. MCP server surface third. Deploy, rollback, and log tool calls only make sense once the agent has somewhere safe to run and a transport it speaks. Tool design notes from the quarter: generous read paths, narrow write paths, explicit refusals over silent ones, and per-call scope so a reconnect cannot silently shift which project an agent is acting on.
4. Machine-readable networking fourth. This is the step a Cluster-API fleet must still build: --json endpoint inspection, per-sandbox network identity, scriptable DNS and endpoint naming, and sandbox-to-project egress policy. What per-tenant NetworkPolicy already covers is the floor, not the ceiling — tenant-to-tenant isolation and a default-deny posture are ground Railway had to build from scratch and you inherit from Kubernetes. The agent-addressable layer above it (names an agent can read and rename, endpoints it can resolve without asking a human) does not exist yet.
5. Guardrails by default throughout. Soft-delete on destructive APIs, short-lived scoped tokens instead of account-wide ones, deployment-source allowlists. Ship each with its capability, not after the incident.

Note the deliberate MCP-before-networking logic inside the June 26 co-ship pair: the tool surface (what the agent calls) precedes the addressable network (what the agent resolves), because tool calls work against IPs and dashboard-copied hostnames on day one, while scriptable naming pays off once call volume makes humans the bottleneck.

Changelogs are roadmaps when agents are the user​

Step back and the meta-lesson is about reading order, not just build order. Each entry in this quarter is unremarkable alone — an SSH migration, a chat feature, a CLI subcommand. Taken together, they show a platform discovering, empirically, what agents need: standard transports, disposable computers, zero-install onboarding, scriptable networks, and guardrails at every step. The next entries practically write themselves: finer-grained agent scopes, sandbox-to-production promotion paths, checkpoints as shareable team artifacts.

If you run the fleet instead of renting it, you get to skip the discovery phase and build the end state. But build it in the order Railway found, not the order that demos best — because the quarter's real message is that the demo order (agent controls first, isolation and safety later) is backwards. Transport, computer, controls: that is the roadmap, and it was sitting in the changelog all along.

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.