Railway's dev.new Preview: The PaaS Is Coming for Your Laptop's Dev Environment

It took Railway about three weeks to move from "runs your code" to "is where your code gets written." On July 31, changelog #0301 previewed dev.new, a prompt-to-production builder where an agent writes your app on a full Railway VM. A week later, changelog #0302 put Cloud Agents in beta: managed computers, running 24/7, that you drive from your laptop, terminal, or phone. When the code is ready, a VM daemon promotes the dev computer straight to production.

TL;DR: the hosted inner loop is genuinely good at zero-to-one. The bill for an always-on dev computer on Railway's meter runs roughly $40–80/month per developer before plan credits — and the meter only sleeps if you tell it to. Meanwhile the same company is telling you, in its own words, that it wants your agent, source, infrastructure, previews, and deployments to "stop being separate places." Dev environments are becoming the next lock-in surface after production deploys, and this post works out the for/against math plus what the own-your-machines equivalent looks like.

What actually shipped​

Two surfaces, two different jobs. Keep them straight, because the cost analysis below depends on it:

The dev.new internals are public and worth reading. Your first prompt creates a Railway project and boots a VM on the same infrastructure as Railway Sandboxes: a /app workspace preloaded with Vite, React 19, Tailwind v4, and TypeScript, a dev server already hot-reloading on port 8080, and the railway-agent coding agent running inside the VM with a pre-authenticated CLI, Playwright with Chromium, and a ship tool that deploys the working directory. The launch demo — a realtime multiplayer FPS from one prompt, which the agent then playtested against itself in two browser sessions before shipping — is the obligatory impressive video. What matters more is the sentence under it: "there's no migration cliff between the prototype and the real thing."

That sentence cuts both ways, and it is the thesis of this post. No migration cliff from prototype to production also means no export step, no exit step, and eventually — per the dev.new announcement — one unified surface where agent, source, infrastructure, previews, and deployments "stop being separate places." Extremely convenient. Also, definitionally, lock-in.

For completeness: the same changelog shipped the ChatGPT plugin that turns a conversation into Railway operations via a hosted MCP server. That is the chat-as-console story, and we already covered what it demands from a Render-compatible API — this post stays on the dev-environment side.

The bill, worked out​

Railway bills per minute at published rates: roughly $20/vCPU/month, $10/GB of RAM/month, volumes around $0.15–0.25/GB/month, egress around $0.05–0.10/GB. Hobby ($5/month) includes $5 of usage credit; Pro ($20/month) includes $20. Apply that meter to a dev computer:

(Before plan credits; storage and egress extra. The 160-hour column assumes you actually stop the box — on Railway's per-minute meter, stopped means unbilled.)

Which column you land in is the entire cost question, and it depends on which surface you use:

• dev.new: the cheap column, by default. Idle VMs shut down and reattach on return. You pay for build time, not wall-clock time.
• Cloud Agents: the expensive column, by default. The product is a computer "running 24/7 controlled from your laptop, terminal, or phone." Nothing in the announcement describes auto-stop; the 24/7 presence is the feature — your agent keeps working while you sleep.

Compare with the incumbent: GitHub Codespaces charges $0.18/hour for a 2-core box (comparable to the 2 vCPU / 4 GB row) but auto-stops after 30 minutes idle by default, so a 160-hour month costs about $29 before storage. A developer who forgets to stop anything still doesn't pay for the other 570 hours. On a 24/7 meter with no auto-stop, forgetting is the billing model. That gap — auto-stop versus always-on — matters more than any per-unit rate difference, and it is the number to watch as Cloud Agents moves from beta to priced.

Sensitivity check, because the honest answer depends on your shape. A solo developer doing bursty evening work pays closer to the active-hours column — active hours are cheap everywhere. A team running 24/7 agent loops, with agents iterating overnight (exactly the workflow Cloud Agents sells), pays the full 24/7 number per box, times headcount, indefinitely. At five developers on 2 vCPU / 4 GB boxes, that is $400/month before credits for machines that mostly sit idle while humans sleep. That is not an argument against the product. It is the number the product needs to beat — compute it before your agents move in, not after.

The case for moving your inner loop to Railway​

Give the hosted side its due — three things here are genuinely good:

Zero-to-one has never been faster. The old flow was: idea → local scaffold → fight your machine's toolchain → railway up → iterate. The dev.new flow is: idea → prompt → live preview → publish, with the agent doing the toolchain fighting inside a VM that already has one known-good configuration. For hackathons, internal tools, and "is this idea even buildable" spikes, removing the local-machine variance is a real win.

Same-project promotion removes the prototype cliff. Because a dev.new app is a regular Railway project, growing it into production means adding a database, setting variables, attaching a domain — not re-platforming. Anyone who has watched a demo-day prototype die during "now let's deploy it properly" knows what this is worth.

Bring-your-own-harness respects reality. Cloud Agents ships with every major harness preinstalled instead of demanding you standardize on Railway's agent. If your team already pays for Claude, Cursor, or OpenCode subscriptions, the dev computer meets you where you are rather than re-selling you the model. Combined with laptop/terminal/phone control, it is the closest thing yet to "your laptop, but it never sleeps and deploys itself."

Who should say yes: solo builders, bursty side-project work, teams with zero ops capacity, and anyone whose alternative is not "a well-run self-hosted platform" but "whatever state our laptops are in." If that is you, stop reading the cost table as a warning and start reading it as a price list — it may be worth it.

The case against: latency, dotfiles, secrets, and the Ona precedent​

Now the other side — four concrete costs, none of them hypothetical:

1. Latency is physics. Every keystroke, completion, and test run on a hosted dev computer is a network round trip. People tolerate this fine on good connections and hate it on airplanes, hotel wifi, and anywhere the speed of light plus a congested uplink exceeds ~100ms. Local development degrades gracefully offline; cloud development degrades to nothing. If your team works from anywhere with unreliable connectivity, the inner loop now has a network dependency it never had.

2. Dotfiles and editor state don't port themselves. Years of shell config, editor plugins, keybindings, and muscle memory live on your laptop. Hosted environments solve this with dotfiles repos and settings sync — workable, but it is a migration project per developer, and every hosted vendor's sync mechanism is subtly different. The switching cost is paid in papercuts: each new surface re-litigates where your config lives.

3. Your secrets now live on someone else's VMs, operated by agents acting as you. This one deserves precision. Railway's ChatGPT plugin "acts with your personal access level," and the dev.new agent runs with a pre-authenticated CLI inside your VM. That is the correct design for usefulness — and it means your credentials, session transcripts (persisted in /app, per the announcement), and production access flow through machines and agent loops you don't control. For side projects, fine. For anything touching customer data, this needs your security review, not a shrug — you are extending your trust boundary to a vendor's VM fleet and every harness running on it.

4. The Ona precedent: hosted dev environments get sunset. Gitpod — the company that arguably invented the modern cloud dev environment — abandoned its self-hosted product in 2022, rebranded as the AI-agent platform Ona in September 2025, and sunset Gitpod Classic on October 15, 2025. Developers who built their inner loop on it got a migration, not a wake. Every hosted dev environment is a bet that the vendor's current strategy still includes your workflow in three years. Railway's strategy clearly does today — "stop being separate places" is about as committed as it gets — but "committed" and "permanent" are different words, and Gitpod's users learned the difference the expensive way.

The self-hosted equivalent you can build today​

As promised up top: per-branch preview environments plus a disposable dev namespace on a cluster you own. Here is what that concretely means, with honest costs:

Per-branch previews are the solved half. Every modern PaaS — Railway included — builds preview deploys per pull request. On your own Cluster API fleet, this is a solved pattern: a controller that reconciles a namespace per PR, deploys the branch, wires a wildcard subdomain, and garbage-collects on merge. No exotic software required; the marginal cost on capacity you already run is near zero.

Disposable dev namespaces are the half Railway just productized. The self-hosted recipe:

• DevPod (open-source, client-only) as the provisioner: it speaks the same devcontainer.json standard as VS Code Dev Containers and Codespaces, runs as a local client or desktop app with no backend service, and provisions workspaces onto whatever you already have — local Docker, an SSH box, or your Kubernetes cluster. The tool provisions; it doesn't host. Your devcontainer.json stays portable across DevPod, Codespaces, and plain VS Code, which is the opposite of a lock-in surface.
• Your cluster as the substrate: dev namespaces on a Cluster API-managed fleet, with resource quotas per developer and automatic cleanup of idle namespaces. You already pay for these machines; dev workloads backfill capacity that would otherwise sit idle — the mirror image of paying a per-minute meter for a box that idles while you sleep.
• Coder (self-hosted, AGPL) if you want the managed-server experience: Terraform-defined workspace templates, workspaces as K8s pods or VMs, a control plane you operate. More powerful than DevPod, more to run.

What you give up, stated plainly: someone has to operate the control plane, build the golden devcontainer.json images, run onboarding ("install DevPod, point it at the cluster" versus "click this URL"), and be on call when the dev cluster has a bad day. For a team with zero platform capacity, that is a real cost — potentially larger than $80/dev/month. The self-hosted equivalent is cheaper in dollars and more expensive in attention. Anyone who tells you otherwise is selling something.

Verdict: the inner loop is the next lock-in surface​

Step back and look at the sequence: production deploys first (Railway's origin), then databases (now private-by-default with automatic CVE patching — increasingly managed), then chat-operated infrastructure (the plugin wave), and now the inner loop itself (dev.new, Cloud Agents). Each step is individually convenient. Together they move the center of gravity from "your laptop builds, Railway runs" to "Railway builds, previews, runs, and operates, and your laptop is a thin client." That is not a criticism of the engineering — it is good engineering. It is a description of the surface area one vendor ends up owning: your code's entire lifecycle from first prompt to production incident.

The decision rule I'd actually use:

• Hosted wins when your alternative is laptop chaos: solo builders, tiny teams, bursty work, zero ops capacity. Pay the meter with eyes open, set calendar reminders to stop idle boxes until auto-stop exists, and keep your devcontainer.json (or equivalent) portable so the exit stays cheap.
• Self-hosted wins when you already run a fleet: the marginal cost of dev namespaces on owned machines is near zero, your secrets never leave your trust boundary, and no vendor rebrand can sunset your inner loop. DevPod plus per-branch previews gets you 80% of the experience with no per-minute meter.

Either way, treat the dev environment as infrastructure with an exit plan, not as a free tab in your PaaS dashboard. Production lock-in took a decade to build and we're still untangling it. Don't sleepwalk into round two.

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, keep your inner loop on hardware you control, and never pay a per-minute meter for a dev box that's idle while you sleep.