Deploy From Your Coding Agent: Wire Railway's MCP Server Into OpenCode

Your coding agent writes the pull request. You review it, merge it, and then the familiar second half of the job starts: open the hosting dashboard, create the project, push the code, wait for the build, assign a domain, find the logs when it crashes. That second half is exactly the kind of repetitive tool work an agent should be doing for you, and in 2026 it can: Railway ships an official Model Context Protocol (MCP) server that turns its whole platform into a toolset your agent can call.

This guide wires that server into OpenCode, the open source agent CLI, so one prompt covers the entire journey: create the project, deploy the service, assign a domain, verify it responds, tweak a variable, redeploy, and read the logs when something breaks. No dashboard clicks, no context switching, no "ship it" messages to your future self. Seven steps, under an hour, every step ending in something you can run. If you are new to MCP itself, the beginner guide covers the protocol; here we stay on the build.

Official Sources#

Step 1: Install the two CLIs#

Prerequisites: a Railway account (the free trial comes with a one-time $5 grant, which covers this whole build), a code directory for a small test app, and a model provider key for OpenCode.

Install OpenCode with the official one-liner from the docs:

curl -fsSL https://opencode.ai/install | bash

Install the Railway CLI from the official docs. The no-frills path:

bash <(curl -fsSL railway.com/install.sh)

There is also curl -fsSL agents.railway.com | sh, which installs the CLI and immediately runs railway setup agent for detected editors, and npm i -g @railway/cli if you prefer npm (requires Node 16 or newer). Verify both sides:

opencode --version
railway --version

What you have now: two CLIs on your machine, nothing connected yet.

Step 2: Authenticate both agents#

OpenCode needs a provider. Run opencode auth login and pick one; this week's DeepSeek V4 Flash guide covers why a budget model is plenty for tool orchestration like this. Prove the harness runs one task and exits:

opencode run --model opencode/deepseek-v4-flash "print the current directory tree, two levels deep"

Railway needs your account. The login command opens a browser; use --browserless on a headless box:

railway login

Confirm the session:

railway whoami

What you have now: two authenticated CLIs. The next step is where they meet.

Step 3: Connect Railway to OpenCode over MCP#

Railway's agent setup writes the MCP configuration for you. The docs document three ways to connect - Local MCP, Remote MCP through a CLI proxy, and Remote MCP with direct OAuth - and railway mcp install targets specific editors with --agent. For OpenCode:

railway mcp install --agent opencode

This merges an entry into OpenCode's config without touching any other MCP servers you have configured. What it writes, per the documented config table:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "railway": {
      "type": "local",
      "command": ["railway", "mcp"],
      "enabled": true
    }
  }
}

You could write that file by hand, but the installer is better: it keeps the exact command shape current across CLI releases. Verify the server registered:

opencode mcp list

You should see railway listed with a local transport. Now run a probe that forces tool use:

opencode run --model opencode/deepseek-v4-flash "list my Railway workspaces, projects, and services. use railway"

A real answer instead of an apology means the loop is live. Local MCP runs railway mcp as a child process using your existing railway login session, so there is no token file to leak and nothing to refresh.

What you have now: your coding agent can see Railway. It can read; the next step lets it ship.

Step 4: The first deploy, fully agent-driven#

Local MCP exposes the CLI workflow as tools: projects (list_workspaces, list_projects, create_project), services (create_service, connect_service_source, scale_service), deployments (deploy, list_deployments), domains (generate_domain, domain_status), variables (list_variables, set_variables), and observability (get_logs, service_metrics). The full list is in the MCP server docs.

Fire the canonical prompt from those same docs:

Create a Next.js app in this directory and deploy it to Railway.
Also assign it a domain.

Watch the sequence: the agent scaffolds the app, calls create_project, connects the directory as a service, triggers deploy, waits on deployment status, and runs generate_domain. When it reports a URL, hit it:

curl -I https://<your-service>.up.railway.app

Expect a 200 (or the 3xx from your app's own redirect - the point is a live response, not a dashboard state). You just went from a blank directory to a deployed, domain'd service with one sentence and zero dashboard tabs.

What you have now: a deployed service your agent built and shipped in one session.

Step 5: Operate the loop from the chat#

Deployment is the first step, not the last. Keep the whole operating loop inside the agent:

Add an environment variable GREETING=hello to my api service and deploy the change.
Then show me the last 20 lines of its logs.

That is set_variables, a fresh deploy, and get_logs back to back. This is the loop you will use every day: change something, ship it, look at the logs, iterate. When you want to check what is costing you money, the agent can do that too:

Show me my current Railway usage and what it is costing. use railway

Small services like this one stay comfortably inside the Hobby plan's $5 of included usage ($20/vCPU/month and $10/GB/month, billed per minute, per the pricing docs) - but the habit of checking costs from the same chat that deploys is the one that keeps the overnight-bill failure mode from ever being yours.

What you have now: a deploy and iterate loop that never leaves the agent.

Step 6: Add the debugging agent (remote mode)#

Local MCP covers day-to-day operations, but two capabilities are remote-only: redeploy / accept-deploy, and railway-agent, Railway's hosted agent tool for multi-step work like log analysis and crash diagnosis. Install remote mode the same way:

railway mcp install --agent opencode --remote

This swaps the entry to command: ["railway", "mcp", "proxy"] - the proxy reuses your railway login credentials and forwards to mcp.railway.com over HTTPS. There is also --remote --oauth, which writes {"type": "remote", "url": "https://mcp.railway.com"} and hands OAuth to OpenCode itself; with that mode, run opencode mcp auth railway once and OpenCode stores the token in its own auth store.

Now break the app on purpose, so the debugger has something to find. Set a variable that points your service at a nonexistent value and deploy. Then ask:

Use the railway agent to figure out why my api service is crashing on deploy.

The railway-agent tool investigates on Railway's side - logs, config, recent deploys - and comes back with a diagnosis and a proposed fix. If you would rather work without the MCP hop, the same brain is available as a CLI command, documented at railway agent: railway agent -p "help me debug why my api service is failing". When the fix lands, accept-deploy is how a staged change ships.

What you have now: a debugging path for when your agent's own code is not the thing that is broken.

Step 7: The guardrails that make this safe#

Giving a coding agent deploy access is a real capability, and the security model matters more than the convenience. The Railway docs are explicit, and the rails worth keeping:

• Destructive tools ask first. remove_service, delete_domain, redeploy, accept-deploy, and railway-agent are marked with protocol-level hints, and Local MCP returns a preview that requires your confirm: true. Read the preview; an agent that deletes a service costs you a rebuild.
• Scope the blast radius. With remote OAuth you choose which workspaces the client can access, tokens are short-lived and revocable from your account settings, and project tokens are not accepted for remote MCP at all - it requires a user identity for billing and audit trails. Railway's own guidance: avoid production risks by keeping agent access to non-critical environments.
• Watch context, not just cost. MCP servers add their tool list to every request's context, and the OpenCode docs warn that too many servers eat tokens fast. This one is worth it - it replaces a whole dashboard - but keep it scoped per agent (enable it for your build agent, disable it globally for the rest).
• The agent deploys, you review. The same discipline as PRs from scheduled agents applies here: let the agent ship to staging and preview environments, keep production deploys behind your own eyes, and railway usage is your monthly scoreboard.

What you have now: a deploy-capable agent with explicit confirmations, scoped credentials, and a cost check in the loop.

What you have now, in one sentence#

A coding session that starts with "build me this" and ends with a live URL, with every intermediate step - project, deploy, domain, variables, logs, diagnosis - a tool call instead of a dashboard. The same connection works in Claude Code, Cursor, Codex, and the rest if you want it elsewhere, and Railway's agent skills (railway skills install) add procedural knowledge on top of the tools. The pattern that stays with you: hosting platforms are becoming agent toolsets, and the agent that writes the code should be the one that ships it.

FAQ#

Does the Railway MCP server work with OpenCode?#

Yes. Railway documents OpenCode as a supported agent: railway mcp install --agent opencode writes the exact config entry (local stdio, CLI proxy, or remote OAuth), and OpenCode's own MCP support handles local and remote servers with opencode mcp list to verify.

Local MCP or Remote MCP, which should I use?#

Local MCP for day-to-day work on a machine where you are already logged in with railway login - it runs the CLI as a child process with no token files. Remote MCP when you want the railway-agent debugging tool, redeploy / accept-deploy, or a hosted connection that survives your laptop.

Is it safe to let my coding agent deploy?#

Deploy to non-critical environments, keep destructive tools behind their confirmations, scope OAuth to specific workspaces, and use short-lived revocable tokens. Railway's remote MCP deliberately does not accept project tokens, so every action trails back to a user identity.

What does this cost?#

The build stays inside the free trial's one-time $5 grant and, after that, the Hobby plan's $5 monthly fee with $5 of included usage. A single small service typically stays inside the included amount; per-resource rates are $20/vCPU/month and $10/GB/month billed per minute. Ask your agent for railway usage instead of guessing.

Do I need a Railway API token for this?#

No. Local MCP and the CLI proxy reuse your railway login session, and remote OAuth authenticates in OpenCode via opencode mcp auth railway. For remote MCP specifically, Railway does not accept project tokens.

Sources#

Some links to tools above are referral links - see our affiliate disclosure.

Last updated: August 11, 2026

Continue Reading#

• Ship a Remote MCP Server on Railway - the other direction: your own MCP server, hosted where the tools live
• OpenCode Developer Guide 2026 - the full tour of the agent CLI driving this build
• Put an AI Agent Behind a Webhook - deploys without anyone at the keyboard, event-driven
• Put an AI Agent on a Cron Job - the scheduled sibling of the same runner pattern
• What Is an MCP Server? - the protocol primer if any of this is new