Railway's Summer of Agents: Sandboxes, Chat-Ops, and the Three Layers of Lock-In

Between June 5 and July 31, 2026, Railway shipped sandboxes, Docker inside sandboxes, a sandbox file API, preinstalled coding agents, Railway-over-SSH, a platform agent in Slack and Discord, plugins for Grok and ChatGPT, and a prompt-to-production builder called dev.new. Eight weeks, one direction: the agent stops being a tool you point at your infrastructure and becomes a tenant of it — provisioned, networked, billed, and chatted with like any other workload.

Here is the whole summer in one table; the rest of this post is about what it adds up to, where the all-in-one-vendor version traps you, and what the same shape looks like on machines you own.

Three things jump out before we get into analysis. First, the cadence is weekly and compounding — each layer assumes the previous one. Second, the surface converges on two ideas: agents as first-class platform tenants, and chat as the deploy console. Third, every layer lives behind one vendor's API, identity system, and bill. That last point is the one this post spends the most time on, because it is the one the changelogs don't spell out.

Agents stop visiting and move in​

The June 24 "Agents in the Sandbox" post says the quiet part out loud: people really like using sandboxes for agent workloads, so Railway stopped making them install the harness. Claude Code, OpenAI Codex, OpenCode, and Pi now ride in the default image. Fire up the agent, configure it, checkpoint, loop.

But the more interesting move is architectural, not convenience. A sandbox created with --private-network joins the environment's private network, which means the agent tests code against the same Postgres, Redis, and internal services it will use in production — not mocks, not a local container that kind of matches. The June 5 infrastructure-as-code support means the project's services, databases, domains, variables, and replicas live in a typed .railway/railway.ts file an agent can read and plan against. The July 10 feature flags add runtime toggles scoped to the project that take effect in seconds without a redeploy — exactly the kind of lever you want an agent to be allowed to pull, and exactly the kind you want audited.

Put those together and the agent is no longer a visitor with an API key. It has a computer (sandbox), a neighborhood (private network), a map (IaC config), and safe levers (flags) — all inside the platform boundary. That is what "agents as first-class platform tenants" means in practice, and Railway built the whole tenancy stack in about five weeks.

The honest version of this section admits the adjacency is genuinely good. Testing against real services instead of mocks removes a whole class of "worked in CI" failures, and checkpointing a configured agent state beats rebuilding it from a clean Debian base every session. Any self-hosted alternative has to reproduce that adjacency, not just the sandbox primitive. More on that below.

Chat becomes the deploy console​

The second half of the summer moves the operator, not the agent. On June 26, Railway-over-SSH lets you ssh railway.new and chat with the platform agent from a terminal with nothing installed. On July 10, @Railway lands in Slack and Discord: mention it to ask about projects, inspect deployments, read logs, and make changes without leaving chat. Then come the plugins — Grok Build in mid-July, ChatGPT on July 31 — each bundling the use-railway skill and the hosted MCP server at mcp.railway.com, with a hook that auto-approves Railway CLI calls so the agent isn't interrupted for permission on every command. The dev.new preview closes the loop: describe an idea in a chat box, watch the agent build it in a live preview, publish, and it's a Railway project.

Two design decisions deserve attention because they show unusual care. First, every chat surface acts with your personal access level, checked on every message — the agent in Slack can only see and change what you already could, and it stops responding the moment you leave the workspace. That is the correct permission model for a deploy-capable chatbot, and it is worth naming because plenty of chat-ops bots historically ran as overprivileged service accounts. Second, usage is billed to the connected workspace at standard rates, which keeps the cost model legible: chat-driven operations cost what dashboard-driven operations cost.

But note what "chat as the deploy console" quietly assumes: the console, the agent, the runtime, and the bill all belong to Railway. Your team's deploy muscle memory starts forming around @Railway, the use-railway skill, and mcp.railway.com — none of which you can take with you.

Where the lock-in actually lives: three layers​

This is the audit the changelogs don't write. Railway's agent stack couples three layers that are separable in principle and bundled in practice.

Layer 1: the runtime. Sandboxes run on Railway's VM primitive, on Railway-owned hardware ("Railway Metal" in third-party comparisons), scoped to a Railway environment. Practical consequences already visible in the ecosystem: checkpoints are region-pinned — a checkpoint built in one region refuses to boot in another. There is no pause primitive, so idle sandboxes keep metering until the idle timeout kills them; one third-party teardown measured the effective duty cycle of an always-available sandbox at under 1% of its list price, meaning you pay for a lot of idle. And everything is still Priority Boarding, i.e. breaking changes may occur — automation you build today against the SDK or CLI can shift under you, which is exactly what happened when older CLI versions were told to update or lose SSH access.

Layer 2: the control plane. The use-railway skill, the plugin packages for ChatGPT, Claude Code, Cursor, and Grok, and the hosted MCP server at mcp.railway.com are all served from Railway's repos and domains. MCP is an open protocol, but the server endpoint, the skill content, and the auto-approve hooks are vendor artifacts. If the hosted MCP server changes behavior, rate-limits, or deprecates a tool, every chat surface that routes through it changes with it, simultaneously. Contrast this with a self-hosted MCP server over your own API: same protocol, but the endpoint is yours and the tools change on your schedule.

Layer 3: identity and billing. The permission model praised above — personal access level, per-message checks, workspace billing — is also the stickiest part. Your team's agent access graph (who linked which chat identity, which workspace pays) lives in Railway's identity system. Usage from every surface — sandbox compute, agent operations, chat-driven deploys — lands on one workspace bill at Railway's per-second usage rates (roughly $30/month for a 1 vCPU / 1 GB container running full-time, per 2026 third-party comparisons). That single bill is convenient right up until you want to move one layer and keep the others.

None of these layers is a trap on its own. Together they mean the agent, the sandbox, and the runtime migrate as a unit or not at all. That is the lock-in: not a contract, but an architecture where every shortcut your team learns — @Railway, railway sandbox fork, the checkpoint you boot every morning — resolves to a Railway-owned endpoint.

The same shape on machines you own​

So what does the same shape look like on infrastructure you own? Here it is as a concrete mapping, not a slogan:

The honest accounting goes both ways. What you lose is the zero-setup adjacency: Railway's version works the moment you pass a flag, while the self-hosted version requires you to actually build the network policy, the snapshot story, and the MCP server. What you gain is separability — each layer moves independently — plus the flat-rate economics this blog has recomputed all year: sandbox duty cycles under 1% are brutal on a per-second meter and irrelevant on hardware you already own.

One more thing the mapping reveals: the open-protocol choices (MCP, skills as files, IaC as code) are what make the self-hosted column possible at all. Every layer Railway built on an open substrate is a layer you can rebuild yourself; every layer that resolves to *.railway.com is a layer you have to replace. When evaluating any vendor's agent stack — not just Railway's — count the endpoints, not the features.

The pattern to watch​

Railway's summer is the clearest statement yet of where hosted PaaS is going: the platform's next interface isn't a better dashboard, it's an agent that already lives inside the runtime and meets you in chat. The August changelogs confirm the arc continued — Cloud Agents beta, agent connectors, a Grok bot plugin — so this isn't a seasonal experiment.

The question for your team isn't whether this shape wins. It will; the tenancy model is too convenient not to. The question is whether your agents move in as tenants of your infrastructure or someone else's. If the answer is someone else's, go in with the three layers priced and named. If the answer is your own, the mapping table above is your build list — and the open protocols are the reason the list is short.

Railway's summer shows the target clearly: sandboxes agents live in, a deploy API agents can read, and chat as the console. 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.