# Railway Cloud Agents turn coding agents into persistent deployment-adjacent VMs Railway’s Cloud Agents beta runs Claude Code, Codex or Grok CLI inside persistent Linux VMs tied to Railway environments, keeping disk state between sessions and moving agent work closer to the infrastructure it can deploy. Railway Cloud Agents are managed, persistent development machines rather than a new model or harness. They reuse developers’ existing agent credentials, sleep when disconnected by default, retain disk state, and live inside Railway project environments—blurring the boundary between remote coding workspace and deployment platform. - Status: Active - Published: 2026-08-20T22:32:13+12:00 - Updated: 2026-08-20T22:32:13+12:00 - Categories: Artificial Intelligence, Web Development, Cloud & Infrastructure, AI Agents, Cloud Platforms, AI Coding, Deployment & DevOps, Developer Tools - Tags: Coding agents, Railway, Railway Cloud Agents - Canonical HTML: https://beyondthe.news/dossiers/railway-cloud-agents-persistent-vm-coding ## 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. ## Key details - Beta announced August 7, 2026 and currently available through Railway Priority Boarding. - Cloud Agents are persistent Linux VMs scoped to Railway project environments. - Railway currently documents support for Claude Code, Codex and Grok CLI. - Sessions survive the initiating SSH connection and disk contents persist between runs. - Agents sleep on disconnect by default; compute billing stops while sleeping but persistent state remains. - `--keep-awake` allows unattended work and continues to bill compute while the VM runs. - Variables from a Railway environment can be injected when creating a new agent VM. - Multiple sessions on one agent machine share the same disk and can conflict on overlapping files. ## Builder takeaways - Use a dedicated non-production Railway environment for early Cloud Agent experiments; do not make production credentials the default context for an autonomous coding VM. - Pass only the variables a task needs and create a fresh agent when changing sensitive environment scope, because variables are resolved when the agent is created. - Prefer the default sleep-on-disconnect behavior unless unattended execution is intentional; monitor running VMs so agent convenience does not become unbounded compute spend. - Avoid multiple agents editing one checkout on the same persistent machine unless the workflow has explicit worktree or branch isolation. - Treat the VM disk as durable developer state: include dependency hygiene, secret scanning and a deliberate destroy/rebuild path in operating procedures. ## What to watch - Whether Railway broadens harness support beyond Claude Code, Codex and Grok CLI and how compatibility is maintained. - How Railway formalizes the VM-to-production promotion path described in its launch announcement. - Pricing and quota behavior at wider availability, especially for always-on or high-resource agent workloads. - Whether Railway adds per-agent network, variable and service-access policies beyond environment-level controls. ## Uncertainties - Cloud Agents remain beta/Priority Boarding and Railway warns that breaking changes may occur. - Railway’s launch post describes a broad bring-your-own-harness and VM-promotion vision, while current documentation lists a narrower supported-agent set; the product boundary is still evolving. - No independent production-scale reliability or cost comparisons were found for this new workflow. ## Sources - [Changelog #0302: Cloud Agents Beta](https://railway.com/changelog/agents-android-autopatch) — Railway · official changelog · 2026-08-07T00:00:00+12:00. Primary announcement for the beta, bring-your-own-harness direction and development-to-production positioning. - [Cloud agents](https://docs.railway.com/cloud-agents) — Railway Docs · official documentation. Primary source for current supported agents, persistence, credential delivery, lifecycle, billing behavior and environment integration.