Railway Turned Its CLI MCP Server Into a Proxy: One Credential for Every Agent, and an Audit Trail You Can No Longer See

On September 4, 2026, Railway changed what railway mcp means. Previously the command started an MCP server bundled inside the CLI, running on your machine. Now it starts a local proxy that forwards your agent's requests to mcp.railway.com, authenticating with your existing railway login credentials — no second login, no OAuth browser dance inside your editor. The bundled server still exists, demoted to railway mcp local. The cutover needs CLI v5.44.0 or later, and the numbers behind the decision are public: only 2,141 users had opted into the proxy while 18,054 stayed on the in-process server, so Railway flipped the default rather than waiting for volunteers.

The auth mechanism is the elegant part. The proxy is a stdio-to-HTTPS bridge: your editor speaks MCP over stdio to the local railway mcp process, which attaches a fresh Bearer [REDACTED] your stored CLI login onto every request it forwards to the hosted endpoint. No long-lived tokens sit in editor configs, and token refresh reuses the same lockfile-serialized path the rest of the CLI uses. And the endpoint is not new — it is the same mcp.railway.com that already powers Railway's ChatGPT plugin (launched July 31, which Railway says "acts with your personal access level") and its Grok plugin. One credential, one endpoint for every agent surface: CLI-connected editors through the proxy, plugin hosts through OAuth.

That consolidation is genuinely good UX. It is also a trust-boundary move, and the two deserve to be weighed separately. Here is the three-way tradeoff up front — the old bundled server, the new proxy-to-hosted default, and the self-hosted MCP server you could run instead — followed by what each row means in practice.

The tradeoff in one table​

The rest of this post walks the table row by row: what the proxy buys, what it moves behind the vendor boundary, and what self-hosting keeps inspectable that a proxy to somebody else's endpoint structurally cannot.

What the proxy buys​

Start with the wins, because they are real and they explain why Railway flipped the default instead of merely offering the option.

One credential for editor agents, with no OAuth ceremony. Before the proxy, reaching the hosted endpoint from an editor meant the full remote-MCP auth flow: dynamic client registration plus a browser consent round-trip. The proxy makes the existing CLI login be the auth. If your agent already runs inside a repo linked to a Railway project, railway mcp now connects it to the hosted toolset with zero additional secrets — and, just as important, zero long-lived credentials written into editor config files that get dotfile-synced, screenshared, and committed by accident. The credential hygiene story here is strictly better than API-key paste, which is still how a depressing share of MCP servers authenticate.

Always-current tools. The in-process server only improved when you upgraded the CLI. The hosted endpoint improves when Railway ships. Bug fixes, new tools, and protocol updates arrive without any action on your end — and without the version-skew support burden of eighteen thousand users each on their own CLI vintage. Railway's docs now frame this explicitly as one MCP server reached two ways, rather than two servers to choose between.

A separate, OAuth-based road for plugin hosts. Note the shape of the consolidation carefully: CLI-connected editors reach mcp.railway.com through the proxy on CLI-login credentials, while ChatGPT, Grok, and other plugin hosts reach the same endpoint through OAuth with the use-railway skill bundled in. Same tools, same hosted behavior — but two distinct auth paths, each fitted to its client. That is the right way to read "aligning them with Railway's plugins": endpoint consolidation, not auth consolidation. Your editor agent and someone's ChatGPT session now exercise the same server-side code, which is good for consistency and worth remembering when we get to the audit trail.

What moves behind the vendor boundary​

Every row of convenience above has a corresponding row of visibility you no longer own. None of these is a Railway-specific criticism — they are structural properties of any proxy-to-vendor-endpoint design, and they are worth naming precisely because the migration is frictionless enough that you might never notice them moving.

Per-request logs now live on Railway's side. With the bundled server, the complete stream of tool calls — which tools your agent invoked, with what arguments, in what order — existed only on your machine. With the proxy, that stream traverses Railway's infrastructure on every call. Railway needs it to serve the request; the point is that you cannot see it anymore. When an agent does something surprising at 2 a.m. — invokes a deploy tool you did not expect, reads variables in an order that suggests prompt injection — your local evidence shrinks to whatever your editor bothered to record, while the authoritative record sits in someone else's log pipeline, under someone else's retention policy, queryable only through whatever support or dashboard surface they expose.

Scope enforcement is Railway's code, running on Railway's schedule. The bundled server enforced your user's permissions locally. The proxy forwards; the hosted endpoint decides. That decision logic — which tools exist, what each tool is allowed to touch, how "your personal access level" maps onto tool availability — now changes when Railway deploys, not when you upgrade. A new tool appearing server-side is a new capability your agents can invoke immediately, with no local diff to review and no version to pin. For most teams this is a feature (fresh tools, no toil). For a team with change control over what its agents are allowed to do, it is a control plane it does not operate.

Update timing is no longer yours. This is the mirror image of "always-current tools." The bundled server's coupling to CLI releases was annoying, but it was also a gate: nothing about your agent's capabilities changed until you ran an upgrade. Server-side tool updates remove the gate along with the annoyance. If a tool's behavior changes in a way that breaks your agent workflow — a renamed parameter, a tightened validation, a removed tool — you find out from the failure, not from a changelog you read before upgrading. Railway does publish changelogs, but the consumption model changed from pull to push.

The data path carries prompts and arguments off your machine. Tool arguments routinely include the sensitive stuff: variable names, log excerpts pasted into debugging prompts, fragments of customer data an agent is reasoning about. With a local server, that data stayed local except for the API calls the task genuinely required. With the proxy, the full MCP envelope — including the agent's framing, retries, and exploratory calls that lead nowhere — crosses the network to the vendor. Again: expected, necessary for the architecture, and worth stating plainly, because "local proxy" sounds more local than it is. The proxy is local; the server, and everything it observes, is not.

What a self-hosted MCP server keeps inspectable​

The alternative is not the old bundled server — it is running the MCP server yourself, on infrastructure you control, behind a gateway you operate. The pattern that has emerged across the self-hosted MCP gateway ecosystem is a single enforcement pipeline that every call flows through: rate limit, then RBAC, then schema validation, then an approval gate, then audit. No second path around it. Here is what each stage buys that the proxy design structurally cannot, stated as direct contrasts.

Your RBAC, evaluated where you can read it — versus scopes enforced in vendor code. A self-hosted gateway applies per-tool, per-identity scope checks from policy files you version-control. You can answer "which agents may invoke the deploy tool, and against which projects?" by reading a file, and you can prove the answer in an audit by pointing at the commit. Against the proxy: the equivalent policy ("acts with your personal access level") is implemented server-side, changes on Railway's deploy cadence, and is observable to you only through its behavior. Both designs enforce something; only one lets you diff the enforcement.

Fail-closed per-tool scopes — versus one credential with your whole access level. The hardened self-hosted pattern issues tokens carrying explicit scope claims, where a token with no scope claim gets read-only access and state-changing tools require an opt-in write scope. A leaked agent token then buys the attacker only what that token's scopes allow. Against the proxy: the credential in flight is your full CLI login, attached to every request. Its blast radius is your entire Railway access level — every project, every environment, read and write alike. Railway's model inherits your permissions; the self-hosted model subdivides them. The April 2026 incident in which an agent found a stray API token and deleted a production Railway volume is the case study for why subdivision matters: the token the agent found had more authority than the task needed, and nothing between the agent and the API narrowed it.

A query-level audit trail tied to a named identity, in your log store — versus a vendor-held record. The gateway pattern logs every call with the calling identity, the tool, the arguments, the policy decision, and the outcome — records you can join against deploy logs, alert on (three failed approval gates in a minute pages someone), and retain on your own schedule. Against the proxy: the authoritative record of what your agents did to your infrastructure lives in Railway's pipeline. You get whatever observability surface the vendor builds; "show me every deploy-tool invocation across all my agents last Tuesday, with arguments" is a support ticket, not a query.

Approval gates in your path — versus direct tool execution. Because every call flows through your pipeline, you can hold state-changing tools for human approval: the agent proposes the deploy, a human (or a second, narrower agent) approves it, the gateway executes. This is the control that turns "agent with deploy authority" from a liability into a workflow. Against the proxy: the tool call executes when the agent makes it. There is no insertion point for your approval logic between an editor agent and the hosted endpoint, because the path between them is Railway's code.

Egress independence — versus mandatory reachability to the vendor. A gateway on your own network serves agents that can reach it, including from egress-restricted or air-gapped environments where mcp.railway.com is unreachable or prohibited. Railway kept railway mcp local for exactly these machines, which concedes the point: the proxy design assumes open HTTPS to the vendor, and where that assumption fails, you fall back to the frozen local server rather than a current self-hosted one.

None of this argues that every team should self-host its MCP server. It argues that the proxy tradeoff has a shape — convenience and freshness on one side, inspectability and control on the other — and that teams handling production infrastructure through agents should choose their side deliberately rather than inheriting it from a CLI default.

The decision rule​

Choose the proxy default when your agents operate on non-production or low-blast-radius surface and your scarcest resource is toil: solo developers, staging environments, teams whose worst case from a surprising agent action is a wasted afternoon. The credential hygiene (no pasted tokens), the zero-maintenance freshness, and the single-endpoint consistency across editors and plugins are real wins that cost you nothing you were using.

Self-host the MCP server — or at minimum, put a gateway you operate between your agents and any hosted endpoint — when agents touch production, when more than one human needs to answer "who did what" afterward, or when your threat model includes prompt injection steering an over-scoped credential. The test is one sentence: if an agent surprises you at 2 a.m., do you want the authoritative record of what it did to be a query you run or a ticket you file? If it is a query, the enforcement pipeline, the fail-closed scopes, and the audit trail need to live on your side of the boundary, because a proxy to someone else's endpoint structurally cannot put them there.

Railway's move is also a signal about where the category is going. Hosted MCP endpoints with first-party plugins are becoming the default agent surface for every platform — Railway this month, with the same Streamable-HTTP-and-OAuth shape the rest of the industry is converging on. As that default spreads, "who holds the audit trail for agent actions against production" stops being a question each team answers once and becomes a standing architectural property of the stack. Worth deciding on purpose, before the next CLI upgrade decides it for you.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with agent-operated infrastructure as a first-class surface. Star the repo on GitHub or deploy your first app today.