Yes, yes we know it can feel like “Just one more MCP server, bro. I swear this one’s different…” But in all honesty, we think you’ll like what the Railway MCP server can do. 

Here’s a quick demo where we one-shot a Next.js app, deploy it, give it a domain, and then spin-up a Postgres database and a ClickHouse database.

Beyond the 0 → 1 experience, the MCP server offers a bunch of tools that coding agents can use to iterate on existing projects:

• deploy - Deploy a service. This tool can be called more than once so coding agents can continuously apply changes.
• deploy-template - Deploy a template from the Railway Template Library. This makes it possible to deploy arbitrarily complex collections of services and databases.
• create-environment and link-environment for working with environments. Great for ensuring that coding agents are working in an isolated environment
• list-variables and set-variables for configuring and pulling variables
• get-logs - Retrieve build or deployment logs for a service. Useful for having coding agents debug deployed services.

You can find the complete list of tools as well as detailed setup instructions in the project’s README on GitHub.

In most cases, using MCP to manage infrastructure doesn’t really make sense. Infrastructure is typically complex, hard to automate, and with most providers you end up paying for resources regardless of your usage.

With Railway you can one-shot your infra and only pay for what you use.

Agents need deployment targets that are reliable, scalable, and cost-efficient. Railway checks all of these boxes.

If an agent spins up resources that go idle shortly after, you don’t get stuck with a big bill. On Railway you only pay for active compute time and resources you actually use. This makes the platform ideal for for experimentation and fast iteration.

Additionally, all deployed services on Railway support vertical autoscaling out-of-the-box. So you don’t need to pick an instance size and pay a fixed monthly fee that doesn’t take your usage into account.

Railway enables you to spin up isolated environments. This means that coding agents can make changes to deployed resources without affecting resources in other environments. You can run multiple agents in parallel and give each one their own environment.

We made a few design decisions along the way when building the Railway MCP Server. None of them are set in stone, but we thought it would be useful to share our reasoning and the trade-offs that led us here.

This one is the most obvious one. If there are no delete-x MCP tools, the odds of the coding agent running a destructive action goes down significantly. This way, you avoid running into this situation.

However, coding agents can still run arbitrary CLI commands, so you should be careful.

MCP has a transport layer responsible for how clients and servers talk to each other and how authentication is handled. It takes care of setting up connections, framing messages, and making sure communication between MCP participants is secure.

MCP currently supports two types of transport:

• Stdio transport: This uses standard input and output streams for communication between local processes on the same machine. It’s the fastest option since there’s no network overhead, which makes it ideal when everything is running locally.
• Streamable HTTP transport: This uses HTTP POST for sending messages from client to server, with optional Server-Sent Events for streaming responses. It’s what enables remote servers to work and supports common HTTP authentication methods like bearer tokens, API keys, and custom headers. MCP recommends OAuth as the way to obtain these tokens.

Remote MCP servers make a lot of sense in the broader vision of MCP. In that world, any AI tool could act as a host, connect to multiple remote MCP servers, and pick the right tool for the job.

For Railway, though, most of our users are developers working inside editors like VS Code, Cursor, or Claude Code. In that context, a remote MCP server doesn’t bring much benefit.

Another limitation is authentication. Since Railway doesn’t yet support OAuth, the only way to connect to a remote MCP server would be to hardcode API tokens. That means going to the Railway dashboard, generating an API key in your account settings, and then manually adding it to your MCP config file. Not exactly a great experience.

We also haven’t come across a real use case where an MCP host only works with remote servers, nor have users asked us to integrate Railway that way. So instead, we went with a local MCP server. The Railway CLI already offers a seamless authentication flow, so setup is as simple as:

1. Install the CLI
2. Run railway login
3. Install the MCP server

There’s also a nice side effect of using the CLI as a dependency. If something breaks or the agent hits an edge case, it can fall back to the same workflows a developer would use manually. Rather than getting stuck, it just calls the CLI, which makes the system more resilient and avoids frustrating dead ends.

Under the hood, the MCP server runs CLI commands. This approach helped us spot gaps in the experience of integrating with the CLI programmatically, which gives us valuable feedback for improving it.

import { exec } from "node:child_process";
import { promisify } from "node:util";
import { analyzeRailwayError } from "./error-handling";

const execAsync = promisify(exec);

export const runRailwayCommand = async (command: string, cwd?: string) => {
	const { stdout, stderr } = await execAsync(command, { cwd });
	return { stdout, stderr, output: stdout + stderr };
};

export const checkRailwayCliStatus = async (): Promise<void> => {
	try {
		await runRailwayCommand("railway --version");
		await runRailwayCommand("railway whoami");
	} catch (error: unknown) {
		return analyzeRailwayError(error, "railway whoami");
	}
};

We’d love to hear how you’re using the Railway MCP server and what improvements you’d like to see. Share your feedback with us on Central Station and help us shape future versions. And if you’re building an agent platform and want to use Railway to power the underlying infrastructure, we’d love to chat.