Railway is a canvas

Railway is the platform in this series that most obviously likes small software, and its unit is still a project you tend. The deploy succeeds and nothing is reachable, because a URL is a separate decision. It has also done more for agents than anyone else here, which is what makes the shape of that work worth looking at closely.

Fourth post in a series where we count what it costs to get agent-built software running on the platforms that exist today. So far: Google Cloud Run, a machine built for organisations; Cloudflare Workers, a kit of parts built for engineers; and Vercel, a workflow that starts from a repository. The last post promised the platforms that hand you a container and a dashboard. This is the first of those.

A disclosure that goes further than the usual one. Shed builds with Railway's build system. Railpack is vendored into our CLI at v0.35.0 under its MIT licence, and it is what inspects an application and works out how to build it when shed init writes a SHED file for you. We took the detection and provider half and left the image export behind, but the part that looks at a directory and recognises what the code is came from Railway. We are not neutral about this company, and the thing we borrowed is the thing they got most right.

What Railway actually is

Railway is a container platform with a project canvas in front of it. You make a project, add services to it, and wire them together. A service is a repository, a Docker image, or a directory you push from your machine. Around it sit the pieces a running system needs: Postgres, Redis, MySQL and Mongo as first-class things you add rather than integrations you configure, volumes, buckets, private networking between services, and per-environment copies of the whole arrangement.

The build story is the best in this series and we say that having read the code. Railpack looks at your source, works out what it is across eleven languages including Node, Python, Go, Ruby, Rust, PHP, Java, Elixir, Deno, shell scripts and static HTML, and turns it into a container image with no Dockerfile and no configuration. It reads the project and picks toolchain versions from the files that already declare them. This is exactly the right primitive for agent-built software, because the agent produces ordinary code and something has to decide how to run it without a human writing twenty lines of Dockerfile first. Cloud Run makes you bring the image. Cloudflare makes you fit the runtime. Railway looks at what you have and figures it out.

And unlike Workers, the answer is a Linux container. Your Python script that imports pandas runs. Your Express server runs as written. There is no compatibility flag, no adapter, no rewrite distance. For the category this series cares about, that combination, ordinary containers plus a builder that needs no instructions, is the closest anyone comes to the thing we are building.

The cost to start it

Here is the path from Railway's own quick start, counted from nothing. No account, no CLI, no project.

1. Create an account (handoff)
2. Install the CLI
3. Run railway login, which opens a browser (handoff)
4. Run railway init, answering the workspace and project-name prompts (handoff)
5. Run railway up
6. Open the service settings and generate a domain (handoff)

Six steps and four handoffs. Two of those are the irreducible ones everybody pays. The third is soft, since an agent with a terminal can answer its own prompts, and railway init --name orders-api --workspace acme --json skips them outright. RAILWAY_TOKEN in the environment replaces the browser login for anything automated.

The honest count is two, account and login, which ties Vercel and ties us. Nobody should choose a platform on that number.

The sixth step is the one worth stopping on, because it survives every shortcut above. The quick start's CLI path leaves it out entirely. That path is railway init, railway up, railway open, and then you are looking at a dashboard, because the guide's answer to "how do people reach this" is Generate Domain in the service settings. There is a CLI command, railway domain, and it does the job in one line. The documentation for railway up states the position plainly: run railway domain to add one, up never exposes a service publicly on its own.

The cost to keep it running

An agent is told to put an API somewhere people can reach it. It runs railway up. The build succeeds, the deploy succeeds, the logs stream, the service is healthy, and the exit code is zero. Nothing is reachable. Every signal the agent has says the task is done, and the one fact that mattered is missing from all of them. From inside the session, success and failure look the same, and the fix is a command the quick start never mentions.

The default itself is right, and we should say so plainly, because it is the one we want too. A running application should be private until you decide otherwise. The disagreement is about the second step. On Railway that step is a switch between private and public, so reaching one colleague means giving the service an address anyone who has it can open. We think the second step should be naming the colleague: private until you say who, and then that person can open it and nobody else can. Either way the deploy stops short of the finish line, and this series is about what the finish line costs. A platform whose deploy returns a URL has answered the question. A platform whose deploy returns a dashboard link has moved it.

Underneath that is the model. The unit on Railway is a project, and a project is a canvas: services as boxes, wires between them, environments cloning the whole picture. It is a genuinely good abstraction for a system that persists, and everything about it assumes something worth tending. Small software has a different shape. The migration script that runs twice and is deleted, the validator someone runs before an import, the webhook that reformats one system's noise: each of these becomes a box on a diagram built for architecture, in a project that now needs a name, and nothing about the model suggests when any of it should end. Volume is the problem. One canvas with four services on it is a good way to see a system. Forty projects, each holding one script an agent wrote in a session that finished months ago, is not a picture of anything.

The configuration story is mid-move, and the destination is interesting. railway.json and railway.toml are deprecated: new services cannot opt into them, and existing files stop being read on 1 December 2026. The replacement is Infrastructure as Code, authored in .railway/railway.ts, generally available, with Python and Go in beta. It covers far more than the old file did, services, databases, volumes, buckets, custom domains, environment variables, replicas and canvas groups, where the old one could only describe how one service builds and starts and could not touch an environment variable.

It is also a program rather than a document, and the CLI evaluates it, diffs it against the selected environment, shows what it would change, and applies only after you confirm. For infrastructure that is exactly right, and it is a better answer than most of this industry has. For one Python file it is a plan-and-apply cycle with a confirmation prompt in the middle, which is a handoff by design, deliberately placed there by people who were correct to place it. Describing a project and describing an app are different jobs, and Railway has built a very good tool for the first one.

On the recurring question in this series, Railway does better than the rest. A Railway cron is a real container that runs the service's start command and exits, not an HTTP route pretending to be a job, which is better than what Vercel and Cloudflare offer for the same task. The constraints are honest ones: five minutes is the shortest interval, schedules are UTC, and if the previous run has not exited the next is skipped. There is still no one-off job, no way to say run this once against production and tell me the exit code, which is the thing nobody in this series has.

Pricing is modest and clear. Free is a dollar of credit a month, Hobby is five dollars including five dollars of usage, Pro is twenty including twenty. New trial accounts get a one-time five-dollar grant. Accounts are one per person, enforced through email, GitHub and payment-method verification. For software that idles almost all of its life those numbers are unremarkable in the good sense, and there is no per-invocation cliff to explain to anyone.

The agent story, taken seriously

Railway has done more for coding agents than anyone else in this series, and it would be dishonest to leave that to the end.

There is railway agent, which chats with a Railway agent from your terminal and keeps threads you can resume. There is a hosted MCP server that works with Cursor, Claude Code, VS Code, Codex, Copilot, Droid, OpenCode and Windsurf, exposing a railway-agent tool for multi-step operations. There are agent skills, installed with railway setup agent, that teach Claude Code, Codex, OpenCode and Cursor how to drive the platform. There are sandboxes, short-lived isolated Linux environments you create, run commands in and destroy, and every one ships with six coding agents preinstalled: Claude Code, Codex, Cursor, Droid, OpenCode and Pi. There are cloud agents, persistent machines running the coding agent itself so a session survives your terminal closing.

That is a serious body of work and a lot of it is genuinely ahead of the field. Taken together, though, it all points one way.

Every piece of it is about agents operating Railway. The MCP server lets an agent drive the platform. The skills teach an agent the procedural knowledge that driving it requires. The sandbox is somewhere an agent works, a development environment with a lifecycle you manage rather than a place the finished thing lands. The cloud agent runs the agent, not the software the agent wrote. Of everything on that list it is the one we are most sympathetic to, because we think an agent should have a computer of its own: durable, up in seconds, owned by nobody in the model business. Railway's version is that machine. It is a place for the agent to work rather than a home for what the agent makes. Add them up and you get a platform that has invested heavily in being drivable by a machine, while the thing being driven is still a canvas of long-lived services with a dashboard at the centre.

The skills are the tell, and we mean that with respect rather than as a gotcha. Skills exist because operating Railway takes procedural knowledge too large for a tool description, and shipping them is the honest response to that. But a platform where the deploy returns the URL, and the app is described by one file the agent can read and write, has much less to teach. The work Railway has done is the work you do when the platform is the given and the agent is what changed. We started from the other end.

Our own count, honestly

Two handoffs against two, the same tie as Vercel, and on start cost there is nothing between us. Handoffs are the part of the cost you can see, which is why the first post stopped counting them on their own. Everything above is the part you cannot.

The difference is what a deploy leaves behind. Shed takes a directory and one file that says how to build it and how to run it, and shed deploy returns an address. There is no project to name, no service to add to it, no canvas accumulating boxes nobody will ever revisit, and no second command standing between a successful deploy and something a person can open. The service, the job and the cron are one unit here, described by the same file and sent by the same command, with the exit code and the logs kept for you. The shape of the software is a detail of the software, not a decision you make before you understand the problem.

We also owe them the larger point. Railpack is in our CLI because it is the best answer anyone has to the question of what to do with a directory of code you did not write. None of this is an argument that Railway built the wrong thing.

A very good cloud, aimed one layer up

Railway is what you get when people who care about developer experience build a platform for running systems, and they have executed it better than most. The builder is excellent, the containers are ordinary Linux, the cron is real, the pricing is legible, and the agent investment is the most serious in this comparison.

The distance between that and what agent-built software needs is not quality, and it is not effort. It is the unit. Railway's unit is a project, something with an architecture, a lifespan and someone tending it, and that unit is correct for the software most people are paid to write. Agents produce the other kind, in volume, with no owner and no roadmap and often a working life measured in days, and asking each of those to become a project on a canvas, then to be published in a second step, is asking small software to dress up as a system before anyone will run it.

They built for agents operating a cloud for systems. We think the software agents write needs a cloud of its own.

Last in the series: Fly.io is a fleet, the other platform that hands you a container and a dashboard.