Your Cloud should come with an app builder | Railway Blog
Mahmoud Abdelwahab<br>Aug 13, 2026<br>Twenty minutes is apparently enough time for an agent to build and deploy an online multiplayer first-person shooter. Don't take our word for it. You can play it right now. Bring a friend, there's respawning.
Real-time multiplayer first-person shooter. Runs fully in the browser
Here's the entire prompt:
Build a realtime multiplayer first person shooter game.<br>Players can automatically quick-join a room, join an existing room using a code, or create a new room and receive a code to share with others.<br>Players can shoot each other and deal damage. once you die you respawn again.<br>Generate all assets. Map, sounds and visual graphics.<br>Ensure that the realtime aspect works locally and in production
The agent went off, built it, tested it by playing a round against itself, and shipped it. The game is fun for a couple of minutes. Making it something you would come back to would require a lot more work. That said, it's pretty impressive what agents can do today off a couple of instructions.
Better yet?
The whole thing happened on dev.new, which is the thing we actually want to show you.
dev.new?
Until recently, if you wanted to deploy something to Railway, you needed a source. It could be local code via railway up, a GitHub repo, or a Docker image. From there, we'd build your app and deploy it.
If you didn't have a source though, there wasn't much you could do. Fortunately, agents made that a lot less of a problem. You just tell an agent what you want to build and it will give you code. From there, the agent can even deploy it to Railway and keep iterating until it works.
We've been building for exactly that workflow: an agent-first CLI, MCP servers, and skills, so Railway is easy to drive from an agent. We've written plenty about it.
But in that workflow, the building still happens somewhere else. The code only arrives here at the end. So we asked the next question: what if you could build and deploy in the same place? Show up with just an idea, leave with a running app?
Back into the lab we went. The result is dev.new.
dev.new<br>You log in with your Railway account, describe what you want to create, and your app gets built for you. You can preview your app, iterate on it, and once you're happy with the result, deploy it. Deploying gives your app its own service in the same Railway project, with a public URL you can share.
On dev.new, your app runs on a real computer on Railway from the first prompt: persistent disk, real domain, and a server that can hold state.
That's why we picked a real-time multiplayer game as the demo. It's the kind of app you can't build client-side. Something has to hold the state of the match: where each player is, how much health they have, which room they're in. Something has to accept a WebSocket per player, decide who shot whom, and keep the room alive as players come and go. All of this requires a long-running server.
Here's what that computer looks like, and what the agent did with it.
The machine, the agent, the run
The machine
Your first prompt creates a Railway project in your workspace, named after what you're building. Inside it boots the computer the agent lives on: a full VM. It uses the same infrastructure that powers Railway Sandboxes. Here's how the pieces connect:
How dev.new works<br>The workspace is /app. First boot copies in a baked template with Vite, React 19, Tailwind CSS v4, and TypeScript. The dependencies are preinstalled, so the preview can start without waiting for a cold install.
Everything in /app persists, including the agent's session transcript. After the machine has been idle for a while, it flushes the filesystem and shuts down. When you come back, it reattaches the same volume and starts again, with the code and conversation where you left them. The template also carries the workspace rules. The dev server is already running on port 8080 with hot reload, so the agent must never start, stop, or restart it. vite.config.ts, the file that wires the live preview, is off limits. Adding dependencies is fine.
That vite :8080 line is also your window into the machine: the studio renders it as the live preview while the agent works. Click an element in the preview and dev.new resolves it to the component, file, and line that produced it. The element is then handed to the agent with your next prompt. This is a much better experience than writing a paragraph about "the third card from the left".
Targeted edits by selecting browser elements in the preview panel<br>The agent
The coding agent inside is the Railway Agent, railway-agent, our own coding agent. It runs inside the VM rather than reaching into it from outside, and it works in /app like any developer would: editing files, running commands, reading logs.
Beyond the shell, it gets the pre-authenticated Railway CLI, Playwright with Chromium baked into the image, and ship, a tool that deploys the working...