State of Railway: Agents

State of Railway: Agents

When we wrote Railway for Agents, the idea was simple: moving forward, agents are going to build and operate a growing amount of the software that's being shipped. Railway should feel like the easiest (and most complete) place for them to go end-to-end with that workflow.

"Deploy this repo" is relatively easy, and has been done a lot already. We want to focus on unlocking the WHOLE application workflow. Frontends, APIs, workers, databases, caches, buckets, volumes, variables, logs, metrics, domains, certs. All of the pieces an application needs to go from toy project to full SaaS application, available from the same place, in a shape an agent can actually use. How far can an agent get with no dashboard?

Over the past few months, that work has shifted from "make better tools available" to "make the loop feel clean, and fast."

That end-to-end loop matters more than any individual feature. When a user asks an agent to build something, and the agent discovers Railway, it needs to be able to move them through sign-up, configure itself (and its tools), get the first version of their app deployed (the right way), figure out the parts that break, build the fix, and ship the next version. This has to happen hands-off, because odds are the person building it is already thinking about the next feature.

For agents, that's the surface area we're spending a lot of energy on. Making the path from idea to running software, and then from running software to the next working version faster (and safer).

So, let's talk State of Railway: Agents.

All aboard, agents. Agent Sign-Up and the first deploy.

A meaningful share of inbound Railway discovery is now happening through agents.

Historically, you could assume a person was coming through the website - and a lot of your work was going to be around optimizing how that discovery happened in SEO, followed by how easily they could get through a sign up flow. You'd then spend a lot of energy trying to optimize the "golden path" of their first action. Make an account, poke around the dashboard, create a project, connect a repo, and hopefully deploy something.

That is not how an agent wants to discover a platform.

The models tend to push towards the shortest path to an outcome. In this case, that's the technical path to getting the app online. It's much more likely to try and pull down your CLI than it is to push you into a website sign up. If that command stops halfway through and tells the user to "go make an account, come back and start over", the loop is already broken, and most users are just going to ask the agent to try something else.

We've reworked how our core web properties respond to agents, and the markdown we serve to agents is tuned specifically for harnesses, to guide them through that initial agent configuration.

We rebuilt the installation flow for the Railway agent configurations of focus entirely on getting your agent setup, and keeping it updated for future use. The installer (curl -fsSL agents.railway.com | sh) completely configures your agent, the Railway Agent skills, and MCP servers in one shot end to end.

Long term; it also ensure's the health of the agent configurations is good.

Building a better "Up"

When agents reached for Railway, the first thing they usually tried was railway up. So, we started there - and made that flow a lot more friendly to guide an agent through sign up.

For a new user, railway up will now look at the type of agent harness you are using, and pull you into the sign up/in flow. From there, it drops right into deployment from your current application directory, creating the first project, and biasing towards getting you up and running. We're going for the fastest path to first deploy - how much of that can we make happen without friction?

If you are already signed in, railway up continues down its normal path of getting your app deployed in your project, but includes the project creation and linking steps - making it far more effective one shot.

Most of this ends up sounding like plumbing, and largely, it is. It was a lot of unwinding human interaction in favor of creating the shortest path to outcome. Now, the agent monitors waiting for completion - and once you complete it, it picks right back up where it left off.

Home for the Agents

This week, we launched https://agents.railway.com, and gave the /agents page a big facelift, making it the entrypoint for how agents get pulled into Railway. The goal is that an agent can find Railway, understand the install path, configure the right tools, and get to the first deploy without needing the user to translate product concepts along the way.

Shortening zero-to-one is still the most important thing. Agents are very good at continuing once they have a working loop. The hard part is getting that loop started without dropping context. We need good docs and content to establish what the right context is, better tools for obtaining that context and taking action, and workflows that will properly guide the agent on the actions it should take. This brings us to the interaction pathways...

The CLI as an agent interface

The Railway CLI used to be mostly a human interface. That means it inherited a lot of human assumptions.

Humans are surprisingly tolerant interfaces. They can read a prompt, understand that a command is waiting for input, realize they are in the wrong project, and make a judgment call about whether they meant production or staging.

Agents are much worse at that. They need better context, and unstructured content increases the risk of incorrect actions being taken. Explicit targets, parseable outputs, clear errors. Managing interactivity is important too; prompts can't hang waiting for a response, and should be able to be verified afterwards.

This is what we're talking about when we talk about making the CLI "agent-first". It shows up in boring-but-important places: more JSON output, more explicit project / environment / service scoping, more non-interactive flags, better status and log commands, and clearer behavior around deployment state. An agent should be able to tell the difference between "the build was queued" and "the deployment is actually live." If it cannot, it will confidently tell you the wrong thing.

We have also added agent health checks into the CLI. If your Railway skills are missing, outdated, or not configured for the harness you are using, the CLI can surface that and help fix it. Skills can be updated through the railway skills command as we keep improving the routing instructions.

That combination matters. The CLI is the tool surface, but the skill is the operating manual. It teaches the agent when to deploy, when to inspect logs, when to use MCP, when to call Railway Agent, and when to ask for confirmation. If the tool surface improves but the instructions do not, the agent still makes bad choices. If the instructions improve but the tools are awkward, the agent gets stuck.

We need both to keep moving together.

MCP - Local and Remote, and when less is more.

MCP is an ever changing surface area, that we're still evolving the story in.

• CLI MCP is the default for local coding-agent workflows.
• Remote MCP is the option for environments where local terminal access is not available or not wanted.
• The older npx path is officially deprecated.

CLI MCP is the right answer when local context matters. If the agent is deploying the directory in front of it, using your local auth, or working inside a linked project, it should go through the CLI-backed MCP server. It's also extremely low friction, since the same setup flow can install the CLI, configure MCP, and add Railway's agent skills.

Remote MCP is the right answer when the agent only needs OAuth-scoped Railway operations. It can inspect projects, pull logs, check deployment status, and call into railway-agent without depending on a local install. We have been expanding that tool surface based on what people are actually using, with more project status and log workflows already in, and sandbox and deployment configuration work coming next.

Usage has been moving in the direction you would expect. MCP-driven agent usage keeps climbing, and active user utilization is up more than 5x over the past month.

That does not mean MCP is the whole answer. It means agents clearly want a tool interface to the platform. Our job is to make the routing obvious enough that they choose the right surface without turning every task into a protocol decision.

More than just a computer. Giving agents infrastructure.

Sure, agents are better when they have a computer, but in Railway - we're giving agents access to the entirety of infrastructure. Databases, volumes, functions, services, networking. The works.

If you give an agent a shell, it can edit files and run tests. That is good. If you give it a shell plus the ability to create services, attach Postgres, add Redis, persist data in a volume, create buckets, configure variables, deploy templates, inspect logs, and ship the result, you get a very different kind of loop.

The agent is not just producing code anymore. It is assembling and operating the system around the code.

Sandboxes fit into that story. Some work should happen somewhere disposable before it gets anywhere near a live service: dependency upgrades, build debugging, reproduction cases, PR review, security checks, code generation, and all the other messy middle steps between "I have an idea" and "this should deploy."

We have been adding sandboxes so agents can get a real execution environment with a filesystem and shell, clone code, run commands, make changes, and hand back something reviewable.

We have also been making the sandbox itself more agent-native. More on that this week; getting started using agents inside of these sandboxes is about to get much easier also.

We want to make it easy to move past "can an agent run code in a sandbox?" and instead get platforms thinking about "what can an agent do when the sandbox is connected to the same infrastructure layer it will eventually deploy onto?"

Railway Agent as an operator

There is also Railway Agent itself.

Your coding agent knows what you asked for. Railway Agent knows Railway.

It knows the project model, the services, the deployments, the logs, the variables, the templates, the networking, and the ways these things usually break. It can help deploy a new service, configure a template, diagnose a failed build, inspect logs, and open a PR when the fix needs to land in code.

We have been exposing that agent wherever the rest of the loop happens: in the dashboard, through the railway agent command, and through Remote MCP. The more places it is available, the less your coding agent has to become a Railway expert from scratch.

That is the delegation model we want. Your agent should be able to ask the Railway-native operator what is going on, get a useful answer, and keep moving. For more complex work, Railway Agent can use sandboxes too, which gives it room to do real debugging or code-change workflows instead of only describing what it thinks might be wrong.

Over time, this becomes less like chat bolted onto a dashboard and more like another operator on the project. One that can help keep the system running, but also help ship the next version of it.

Rails, not handcuffs

The more capable these agents get, the more important boundaries become.

This is the reason Guardrails matter.

If an agent can create infrastructure, deploy services, change configuration, inspect logs, open PRs, and run code in sandboxes, teams need a way to say "yes, go fast, but inside these rules."

One of the first Guardrails policies is deploy source control. Workspace admins can restrict deploys to repositories owned by approved GitHub organizations. Railway verifies the source server-side, stores approved orgs by immutable GitHub IDs, and fails closed when it cannot prove the source is allowed. Existing resources are not shut down, but future deploys and source changes have to follow the policy.

That is not about making agents less useful. It is what lets teams give agents more room.

Nobody wants an agent deploying from a random fork, a personal repo, or an unapproved image because it got a little too confident halfway through a task. The answer is not to keep the agent away from deploys forever. The answer is to make the deploy path safe enough that using it feels reasonable.

Guardrails are the policy layer for that.

Where we are

The elegance of Railway isn't that it's just a great place to host applications - it's the underlying primitives that we've exposed that make it consumable in so many different ways. It's the collection of different building blocks that, when put together, can create everything from Agent Runners up to full SaaS products.

Onboarding gets the user and agent into Railway without breaking the first deploy. The CLI gives agents a predictable local control plane. Skills teach them how to choose the right path. MCP gives them a tool interface, locally or remotely. Railway Agent gives them a project-aware operator. Sandboxes give them somewhere to do the messy work. Guardrails let teams define the boundaries.

There is still a lot to build. More CLI coverage. More Remote MCP tools. Better sandbox workflows. Cleaner plugin distribution. More Guardrails policies. More ways for Railway Agent to generate and verify code changes. More docs written for agents without becoming unreadable for humans.

But the direction is set.

Agents should be able to find Railway, sign up, deploy, debug, modify, test, recover, and ship again.

Fewer dead ends. Tighter loops. More software running.

Happy shipping.

— Cody