Railway MCP Server Cursor IDE Setup (2026): railway mcp install, CLI Auth & Deploy Tools
Connect Railway's official MCP server to Cursor IDE with railway mcp install --agent cursor: no API token to paste, since it reuses your railway login session. Covers the deploy, get-logs, and variable-management tools, and why delete operations are intentionally missing.
Railway MCP Server Cursor IDE Setup (2026)
How do you connect Railway to Cursor? Install the Railway CLI, run railway login once to authenticate in the browser, then run railway mcp install --agent cursor — this writes the MCP entry into your Cursor config automatically, reusing your CLI session instead of asking for an API token. Once connected, Cursor can deploy services, read build and deploy logs, manage environment variables, and spin up isolated environments, all from chat.
Railway folded its MCP server into the CLI itself rather than shipping it as a standalone npm package — the older @railway/mcp-server package still exists but is now a compatibility shim that just launches railway mcp under the hood. If you're following an older tutorial that has you npx-ing a standalone package with a RAILWAY_TOKEN in an env block, that path still technically works through the shim, but the CLI-native route below is what Railway's own docs point to now.
If you're comparing PaaS options for MCP-driven deploys, Vercel, Netlify, and Heroku all have dedicated guides on this site — Railway's closest to Heroku's model in that both wrap the CLI rather than the underlying API directly.
What the Railway MCP Server Can Do
Railway's announcement of the server names its tools directly, and they map onto real CLI operations rather than a paraphrased feature list:
deploy — push an iterative update to an existing servicedeploy-template — stand up a template covering multiple services at once (e.g., an app plus a database)create-environment / link-environment — spin up an isolated environment (a PR preview, a staging copy) and connect your working directory to itlist-variables / set-variables — read and write environment variables on a serviceget-logs — pull build or deploy logs for debuggingTypical prompts:
The Design Choice Worth Knowing Before You Rely on This: No Delete Tools
Railway's own announcement of the server is explicit about this: there's no delete-x tool for services, environments, or variables. That's a deliberate constraint, not a missing feature — it's meant to keep an agent from accidentally tearing down a running service or environment while working through a multi-step deploy request. The trade-off is that agents can still run arbitrary CLI commands if your client allows shell access outside the MCP tool boundary, so this isn't a hard security guarantee — it just removes the easiest way for a destructive action to happen by accident through the MCP tool surface itself.
Prerequisites
curl -fsSL https://railway.com/install.sh | bash on macOS/Linux, or see Railway's install docs for Windows)railway loginStep 1: Install the Railway CLI and Log In
curl -fsSL https://railway.com/install.sh | bash
railway login
railway login opens a browser window for authentication. This session is what the MCP server reuses — there's no separate credential to generate for Cursor specifically.
Step 2: Install the MCP Server into Cursor
railway mcp install --agent cursor
This writes the server entry directly into Cursor's MCP config for you. Railway's docs note that the installer merges the entry into your existing config rather than overwriting it — safe to run even if you already have other MCP servers configured.
If you'd rather add the entry by hand (or want to see what the installer writes), the equivalent mcp.json block is:
{
"mcpServers": {
"railway": {
"command": "railway",
"args": ["mcp"]
}
}
}
Restart Cursor after either method.
Step 3: Test the Connection
In Cursor chat:
List my Railway projects
Or, if you have a project with recent activity:
Show me the last deploy's logs for [service name]
A real response with your actual project or log data confirms the connection. If Cursor reports it can't reach Railway, check railway whoami in a terminal first — an expired or missing CLI session is the most common cause, and it fails at the CLI level before it ever reaches Cursor.
A Real Setup Gotcha: This Only Runs Locally (For Now)
Railway's own announcement is candid about this: the MCP server currently only supports local deployment via the CLI, specifically because remote/hosted MCP servers would require hardcoding an API token somewhere less controlled — and OAuth-based remote auth for MCP wasn't ready at launch. That means the AI can only manage Railway from the same machine where you're logged into the CLI; there's no url-based remote config option the way there is for Stripe's or Atlassian's hosted servers. If your workflow needs a shared, always-on connection independent of any one developer's machine, that's not what this server is built for yet.
Combining With a Database MCP Server
Railway commonly hosts Postgres, Redis, or MySQL alongside your app service. Once you've got the app deploying through MCP, pairing it with a database-specific server lets Cursor inspect schema and query data directly against what Railway is hosting — see the PostgreSQL MCP server guide or MySQL MCP server guide for that half of the setup.
Troubleshooting
"railway: command not found" inside Cursor even though it works in your terminal
Cursor's MCP process doesn't always inherit your shell's PATH, especially if the CLI was installed via a shell profile change you made after Cursor was last launched. Fully quit and reopen Cursor (not just the chat panel) after installing the CLI, and confirm which railway resolves in the same shell type Cursor uses.
"Unauthorized" or the server can't see your projects
Run railway whoami directly in a terminal. If it returns nothing or an error, your CLI session expired — railway login again, then retry in Cursor without needing to touch the MCP config at all.
railway mcp install --agent cursor doesn't find Cursor's config
This usually means Cursor was installed somewhere non-standard, or the CLI version predates the --agent flag. Check railway --version against Railway's changelog, update if needed, or fall back to the manual mcp.json block in Step 2.
Deploy tool runs but nothing changes in the Railway dashboard
Confirm you're linked to the environment you think you are — create-environment/link-environment change which environment subsequent commands target, and it's easy to lose track of that across a long chat session. Ask Cursor to confirm the currently linked project and environment before a deploy if you're not sure.
Logs come back empty for a service you know just deployedget-logs reads build/deploy logs for the most recent deployment by default in most CLI-wrapped setups — if you triggered a deploy through the dashboard or a git push rather than through this MCP session, ask specifically for the latest deployment's logs rather than assuming context carries over from an MCP-triggered deploy earlier in the conversation.
When Not to Use This
Because there's no delete tool by design, this server is safer than most for exploratory use — but "no accidental deletes" doesn't mean "no accidental deploys." deploy and deploy-template are write operations that ship real changes to a real environment. Point any early experimentation at a scratch project or a non-production environment until you're confident in how the agent is scoping its requests, the same caution that applies to any MCP server with write access to infrastructure.
Frequently Asked Questions
Q: Do I need a Railway API token to set this up?
A: No — the recommended path reuses your existing railway login CLI session. The older @railway/mcp-server npm package (now a compatibility shim) could take a token, but the current CLI-native install doesn't ask for one.
Q: Can this server delete a service or environment?
A: No. Railway's own docs confirm delete tools are intentionally excluded from the MCP tool surface to prevent accidental destructive actions. Deletions still have to go through the CLI directly or the dashboard.
Q: Does this work as a remote/hosted MCP server, like Stripe's or Atlassian's?
A: Not yet. It's local-only by design, tied to the machine where you're logged into the Railway CLI — Railway's team has said remote support depends on OAuth-based auth for MCP maturing further.
Q: What happened to the old @railway/mcp-server npm package?
A: It's deprecated as a standalone implementation. It's still published, but now acts as a compatibility shim that delegates to railway mcp under the hood rather than running its own separate server.
Q: Can I use this with a Railway project I access as a team member, not the owner?
A: Yes — access follows your Railway account's actual permissions on that project, the same as using the CLI or dashboard directly. If you can't deploy or view a service through railway commands normally, the MCP server won't grant extra access beyond that.
Q: How is this different from the Heroku MCP server on this site?
A: Structurally similar — both wrap their platform's CLI rather than calling the API directly, and both default to reusing an existing CLI login instead of a separate token. The tool surfaces differ: Heroku's leans heavily on Postgres-specific tools (pg_psql, pg_ps, pg_locks); Railway's centers on deploys, environments, and variables. See the Heroku MCP server guide for the comparison.
Related Guides
---