Dora NodaRailway's August 2026 Cloud Agents Beta contains the most provocative sentence any PaaS has shipped this year: "with our VM daemon, when you are ready to ship — we promote the VM to prod." No git push. No CI queue. No build step. The machine your coding agent has been living in becomes production.
The motivation is stated just as bluntly: "GitHub and traditional CI is a bit too slow in our eyes." And they have a point — an agent that iterates in seconds should not wait minutes for a pipeline to bless every change. But a build step was never just a delay. It was doing at least five jobs, quietly, on every single deploy. Here is the full ledger — what VM promotion saves, what it skips, and the net — before any background:
| Promote the VM disk | Promote an OCI digest | |
|---|---|---|
| The artifact | A living filesystem: weeks of agent sessions, edits, installs, and shell history | An immutable image@sha256:<digest> built once from a pinned repo state |
| What approval pins | Ambiguous — the VM keeps changing after you approve it | Exact — the digest cannot change, only be replaced |
| Secret residue | The disk holds your own GitHub token, CLI credentials, and agent conversation history | Build-time secrets stay out of layers; nothing personal ships |
| Rollback | "Restore the VM to when?" — there is no earlier artifact, only an older, equally mutable disk | Redeploy the previous digest; the artifact still exists, byte-identical |
| Audit trail | A story the VM could tell about itself, unverifiable after the fact | BuildKit SLSA provenance + SBOM attestations bound to the digest |
| Net per ship | Saves one CI roundtrip (minutes); spends reversibility on every future incident | Spends one CI roundtrip (minutes); buys exact rollback and provenance forever |
The rest of this post substantiates every row — including the honest case for the VM path, because the speed is real and worth stealing.
What Cloud Agents actually are
Cloud Agents, per Railway's August 7 changelog and docs, are persistent Ubuntu VMs, one per environment, with Claude Code, Codex, and Grok CLI preinstalled. Three design choices matter for everything below:
- Bring your own harness and credentials. The agent runs signed in as you, with your subscriptions, your GitHub token, and a pre-authenticated Railway CLI. The VM is personal by design — teammates never see yours.
- The disk persists; compute sleeps. Disconnecting puts the machine to sleep (compute billing stops, running processes stop), and the next launch wakes it with your files in place. Nothing stops a running agent on its own — there is no idle timeout — and
--keep-awakekeeps a task going after you disconnect, "expect the cost." - Demos are built in; production is a separate path. Each agent gets a public domain serving port 8080 for reviewing work, while the docs still advise deploying a service for production traffic. The changelog's daemon promotion collapses exactly that gap: dev machine to prod without the intermediate build.
Pricing is VM pricing: $50 per vCPU and $50 per GB of memory per month, prorated to the minute, plus $0.05/GB egress. The beta graduated to "Cloud Agents Everywhere" in the same month. A sleeping agent bills nothing for compute — which is precisely what makes leaving a 24/7 agent around feel free until it is awake.
Why the loop is genuinely faster
The traditional agent-to-prod path has four tollbooths: push to git, wait for a CI runner, run the build, then deploy the artifact. For a typical small web service that roundtrip takes single-digit minutes when queues are empty and stretches past ten when runners are busy or the build is heavy. An agent iterating every minute or two pays that tax on every iteration if each one goes through the pipeline — or, more commonly, the human batches changes and reviews them in lumps, which is exactly the latency Railway calls too slow.
VM promotion deletes all four tollbooths at once. There is no push because the code is already on the machine. There is no queue because there is no runner. There is no build because the running state is the artifact. The dev-to-prod transition becomes a daemon operation rather than a pipeline run, and the reverse — prod back to dev for the next iteration — is free, because they are the same machine. Any honest accounting has to start here: the digest pipeline cannot match this latency, and for agent-driven development, latency is the whole game.
The five things the build was doing for you
Whether skipping the build matters depends almost entirely on one variable: how long the VM has been lived in. Three archetypes span the range:
- The 10-minute VM — one task, one session, then promoted. Drift is near zero; this is close to a clean build with extra steps.
- The day-long VM — several tasks, a few installs, some debugging. The disk now contains things no review ever saw.
- The week-long 24/7 agent — the documented use case: an always-on machine accumulating sessions, experiments, and credential uses across many tasks.
Each of the five costs below scales across that range. Short sessions dodge most of them; the always-on machine collects all of them.
1. Filesystem drift
A build compiles a declared input (a repo at a commit) into an artifact. A promoted VM ships everything the agent ever did on it: installed packages, edited configs, downloaded models, chmodded directories, leftover debug flags, and the three abandoned approaches from Tuesday. Railway's own docs note that sessions share the agent's one disk, conflicting the way two terminals would — now imagine promoting that shared, conflicted disk to prod. On the 10-minute VM this is negligible. On the week-long agent, nobody — including the agent — can enumerate what is in the release.
2. Secret residue
This is the sharpest row in the table, because Cloud Agents run as you. Your GitHub token, your Railway CLI auth, your harness subscription credentials, and the full conversation history of every session live on that disk by design. A digest build keeps secrets at arm's length: build-time credentials never enter image layers, and the artifact contains no personal state. A promoted VM carries your identity into production as filesystem content — where every future shell, snapshot, and log exporter can reach it. Rotating "everything the agent ever touched" after a promotion is not a runbook anyone wants to write.
3. The approval-to-snapshot gap
An approval is only meaningful if it pins something. Approving a digest pins 64 hex characters that cannot change. Approving a VM pins… a moment in the life of a mutable machine. The agent (or a background process, or a second session on the same shared disk) can keep writing after the approval and before the promotion completes. There is no structural answer to "what exactly shipped" — only the daemon's word about timing. CI's much-maligned slowness was, among other things, a freeze: nothing changes between approval and artifact.
4. Rollback after the VM mutated again
Rolling back a digest deployment means pointing the scheduler at the previous digest — an artifact that still exists, byte-identical, in the registry — and the operation takes as long as a rollout. Rolling back a promoted VM means restoring a disk to a prior state that was itself just a moment in a mutable life, with no guarantee the "previous" state was ever good, or even captured. And once the VM has served production traffic and been iterated on again, the question stops having an answer at all: which of the many post-promotion mutations do you keep? The digest path separates history (a list of immutable artifacts) from state (what is running). The VM path fuses them, and fusing them is what makes rollback a negotiation instead of a command.
5. Missing provenance
Modern supply-chain practice binds each image to BuildKit SLSA provenance and an SBOM, signed and attached to the digest: who built it, from which commit, with which base layers. Verification is mechanical — admission controllers and deploy gates check attestations before traffic moves. A promoted VM has no provenance to verify because there was no build to attest to. Any downstream consumer asking "prove what this is" gets a story, not a signature. For regulated workloads or anyone with an incident review process, that gap alone decides the question.
The other side of the ledger
None of the above is free on the digest side, and a representative comparison says so. The CI roundtrip costs real minutes on every ship — queue waits, cold builders, test suites that grow without bound — and it costs them at exactly the moment an agent workflow wants flow.
Digest pipelines also have their own failure modes: stale base images, flaky tests blocking urgent fixes, registries as single points of failure. Teams that feel those costs daily are the reason the daemon exists, and dismissing the frustration would be dishonest.
The claim of this post is narrower and specific: the minutes are real, but they purchase rollback, pinning, and provenance — and those purchase their value back with interest at 3 a.m., when the question is never "how fast can we ship" but "exactly what is running, and how do we get back to the last thing that worked."
Notably, Railway itself hedges: the same release that celebrates promotion also shipped automatic CVE patching for Postgres, observing that "if agents are running 24/7, so are attackers." Always-on agent infrastructure expands the attack surface by construction — which is an argument for making what it ships more auditable, not less.
Borrow this, not that: a checklist for self-hosted platforms
A Cluster-API fleet on owned hardware can steal the entire fast loop without adopting the mutable release. The split to enforce is simple: the dev machine may be mutable; the release artifact may not be.
- Keep the always-on dev VM. Persistent agent machines with warm disks and conversation history are a genuine improvement over ephemeral dev containers. Offer them per developer or per agent, with sleep-on-disconnect economics.
- Snapshot the repo state, not the disk. When the agent is ready to ship, capture the declared inputs — repo, commit, lockfiles, build config — and build a fresh image in an ephemeral build pod. The VM's filesystem is evidence of how the change was developed, never the change itself.
- Promote the digest, by digest. The release is an
image@sha256:…reference. Rollback is the previous reference. Pin it in GitOps so the desired state is reviewable text, not a machine's memory of itself. - Attach provenance at build time. BuildKit SLSA attestations and SBOMs cost seconds and make admission control possible. A platform that runs agent-built code for tenants will eventually need to show this paperwork; generate it from day one.
- Gate the deploy, not the iteration. Let the agent iterate without friction inside the dev VM, and put the verify gates (tests, attestation checks, preview deploy) on the digest path. Friction belongs at the promotion boundary — which is precisely where VM promotion removes it.
That boundary is the whole lesson. Railway correctly identified that git-push-plus-CI is too slow a dev loop for agents. The fix is a faster loop with the same boundary, not no boundary. Seconds to iterate, minutes to ship, one command to roll back to an exact artifact: that is the combination worth building.
Running agents that ship on machines you own? Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on your own hardware, with agent-operated deploys as a first-class primitive. Star the repo on GitHub or deploy your first app today.
