What changed
Railway put Cloud Agents into beta on August 7, 2026. A Cloud Agent is a persistent Linux VM scoped to a Railway environment with supported coding agents preinstalled. Developers can launch it from the Railway CLI, reconnect to durable sessions, retain the VM disk between runs, sync local agent skills, and supply environment variables from the Railway project. Railway currently documents support for Claude Code, Codex and Grok CLI.
Why it matters
Most cloud coding agents either own the harness or sit outside the runtime where an application actually deploys. Railway is taking a different route: it supplies the persistent computer and project context while letting developers bring an existing coding-agent account. Because the VM lives inside a Railway environment, agent development is physically and operationally closer to databases, services and deployment configuration. That can reduce setup friction for long-running work, but it also increases the importance of environment isolation, credential scope, cost controls and review before an agent touches production-adjacent resources.
Railway is selling the computer around the agent
Cloud Agents are persistent Linux virtual machines with coding harnesses already installed, not a Railway-specific foundation model. Railway’s current documentation lists Claude Code, Codex and Grok CLI. Credentials are read locally and transferred to the VM over SSH rather than stored as Railway project variables, letting builders reuse existing subscriptions or API access instead of adopting a single bundled agent.
Sessions and disks persist while compute can sleep
An agent is associated with a Railway environment and its disk survives reconnects. By default, disconnecting puts the VM to sleep, stopping compute billing while retaining the disk; reconnecting wakes the machine and returns to the durable session. A `--keep-awake` option lets work continue after disconnect, but Railway explicitly notes that a running agent continues to incur compute charges.
Project context makes the agent deployment-adjacent
Cloud Agents can receive Railway variables and references to variables from other services in the same environment when a VM is created. Railway’s launch announcement also describes a VM-promotion path intended to narrow the gap between development and deployment. The practical consequence is that an agent can work in an environment much closer to the application’s actual cloud context than a generic remote sandbox.
Persistence creates both leverage and new failure modes
Persistent disks and reusable environments avoid repeated bootstrap work, but they also accumulate state. Multiple sessions on the same machine share one disk, so parallel agents can conflict when editing the same files. Environment-scoped variables can expose powerful service access if builders overprovision them. Teams should therefore treat each agent VM as a real development host with explicit lifecycle, credential and data-handling policies rather than as a disposable chat session.