Every PaaS Now Speaks MCP: What Render, Fly, and Railway's Agent Bet Means for Whoever Owns the Server

In the span of about six weeks in the summer of 2026, every major developer PaaS shipped essentially the same announcement: your coding agent can now operate our platform. Render put OAuth and a trigger_deploy tool on its MCP server for Claude Code, Codex, and Cursor. Fly.io taught Sprites — its disposable cloud computers — to speak MCP. Railway connected its hosted MCP server to ChatGPT, Grok, Claude, and Cursor, and pushed agents into Slack and Discord for good measure. Three vendors, three agent surfaces, one unmistakable signal: the deploy target is becoming something software drives, not somewhere humans click.

So here is the verdict up front, with the receipts below:

The pattern across the first three rows is the story of this post: every one of these agent surfaces wraps rented, closed infrastructure. The tools differ, the auth flows differ, but the power relationship is identical — the agent acts on your behalf inside someone else's control plane, under scopes you did not design, against state you cannot inspect except through their verbs. That is fine until it is not: until a deploy needs a capability the toolset does not expose, until a permission model cannot express "read logs but never touch secrets," until the audit trail lives in a dashboard you do not control. The rest of this post inventories what each vendor actually shipped, names what agent-operated deploys genuinely require, and makes the case for the fourth row — an Apache-2.0 MCP server over a platform running on machines you own.

Render: OAuth and a deploy button for your agent​

Render's move is the most legible of the three, because it is the thinnest layer over concepts developers already know. The MCP server lives at https://mcp.render.com/mcp, and the July 22, 2026 changelog entry announced what agents actually needed: OAuth support for Claude Code, Codex, and Cursor, replacing the era of pasting a personal API key into an MCP config file. Setup is distributed as plugins — install the Render plugin, reload the tool, complete the browser OAuth prompt on first use, verify with list_services(). The headline tool is trigger_deploy: agent-written code going live without a human touching the dashboard is now a first-class workflow, with community setups already wiring it as verify-then-deploy-then-watch-logs.

Two honest caveats belong in the same paragraph as the praise. First, the OAuth support is young enough to still have sharp edges: Render's own tracker carries reports of Claude Code failing the flow because the authorization server metadata advertises neither Dynamic Client Registration nor a client-id alternative, leaving the client with no way to obtain credentials. Teething trouble, almost certainly — but a useful reminder that "OAuth support" on launch day and OAuth that works in every client are different milestones, and agents are the least patient OAuth users imaginable. Second, and structurally: every verb the agent can call bottoms out in Render's closed control plane. The toolset is generous, but the ceiling is whatever Render chooses to expose, on infrastructure whose bills, regions, and failure modes are Render's decisions, not yours.

Fly.io Sprites: give the agent a computer, not just a control panel​

Fly's entry is the most architecturally interesting, and the company knows it. The announcement post — "Your Agent Speaks MCP. Give It a Computer," by CEO Kurt Mackey — reframes the problem: Sprites are disposable Firecracker-microVM computers with durable filesystems, and the point is not just letting an agent click your Fly dashboard by proxy but giving the agent somewhere to run. Point any MCP-compatible client at https://sprites.dev/mcp, authenticate to a Fly.io organization in the browser, and the agent can operate nearly the whole Sprites API across the fleet. The accompanying plugins for Cursor, OpenCode, and agent frameworks encode the workflow guidance.

Fly deserves credit for the most clear-eyed technical writing of the three launches. The post takes seriously the real argument against MCP-as-agent-interface — dumping thirty tool descriptions into a context window teaches nothing efficiently — and answers it at the right layer: progressive disclosure is a question of what you say to the model, transport and auth are a question of how the bytes get there, and their plugins are what having both looks like. Capabilities reveal themselves the way CLI subcommands do; the wire stays structured.

And then comes the caveat Fly itself volunteers, which is why this section trusts them most: MCP exec cannot stream, because the protocol has no WebSocket leg to stand on, so shell operators arrive as literal arguments and long-running output does not flow. Community research concluded Fly recommends the direct API or CLI over MCP for agent orchestration — the MCP surface is the convenient front door, not the load-bearing wall. Note the pricing shape that leaks through third-party measurements rather than Fly's own pages: roughly $0.44 for a four-hour Claude Code session on per-CPU and per-GB metering, the scale-to-zero microVM story working exactly as advertised. Cheap per session, metered per unit, and still someone else's meter.

Railway: every chatbot gets a plugin​

Railway's strategy is distribution maximalism. Where Render shipped one server plus OAuth and Fly shipped one server plus workflow plugins, Railway shipped official plugins and connectors for ChatGPT, Codex, Claude, Claude Code, Grok Build, and Cursor — each packaging Railway workflows for that assistant's surface and connecting back to the hosted MCP server at https://mcp.railway.com, with the use-railway skill as the shared behavioral core and agents embedded in Slack and Discord alongside. If your team lives in chat, Railway met you there: deploys, service state, variables, domains, logs, and Postgres operations without leaving the conversation, and the Cursor plugin is open source to boot.

The critique is not that any single integration is bad — it is that N integrations is a worse shape than one protocol. Each chatbot plugin carries its own review process, capability gaps, auth model, and update cadence; a feature that lands in the Cursor plugin may lag in ChatGPT or Grok, and every new assistant that matters means a seventh plugin. This is precisely the fragmentation MCP was supposed to end: one standard server, every client. Railway built the standard server — the hosted MCP endpoint is real and documented — and then wrapped it in per-silo packaging that re-creates the matrix it could have collapsed. The community has already voted with code: third-party projects now offer a single self-hosted MCP server spanning Railway plus GitHub, and unified deploy dashboards covering Vercel, Render, Railway, and Fly.io in nine tools. Agents want one surface per platform, not one surface per chatbot per platform.

What agent-operated deploys actually need​

Strip the three launches to their common shape and a requirements list falls out — the deploy/rollback/logs/scale toolset any platform, open or closed, has to expose before "my agent ships it" is a responsible sentence:

• Deploy as a verb with a plan step. Render's trigger_deploy is the minimum; better is validate-then-apply against a checked-in manifest, so the agent reviews a resource plan and estimated pricing before anything mutates. Reapplying unchanged content should be a no-op.
• Rollback and state inspection as first-class tools. Deployment state, per-service status, build and runtime logs — machine-readable, pollable, with structured errors rather than dashboard screenshots. An agent that cannot read why a deploy failed will retry the failure.
• Scoped authorization, not one token to rule them all. Reads versus mutations versus secrets access must be separable grants. Request bex.read for inspection, add bex.write for changes, reserve a secrets scope for the rare work that truly needs credentials — and workspace roles must still restrict every call underneath.
• Machine-readable state over chat UX. Slack and Discord embeds are onboarding; the durable interface is structured tool results an agent can branch on. Chat surfaces rot with every platform redesign; schemas version.
• An audit trail you can hold. Who authorized what, which agent call mutated which resource, what the plan looked like before apply. On closed platforms this lives in someone else's dashboard with someone else's retention policy.

Score the three vendors against that list and the picture is fair rather than damning: Render has the deploy verb and fresh OAuth but young client reliability; Fly has the deepest execution story and the most honest framing but a streaming-shaped hole in exactly the interactive workflows agents love; Railway has the widest distribution and the narrowest per-surface consistency. All three fail the last row the same way — the trail, the scopes, and the ceiling belong to the landlord.

The fourth row: an open MCP server on machines you own​

This is where the open-source alternative stops being a philosophy and starts being a URL. Bex — the open-source, AI-native Render alternative — exposes its platform to agents through an MCP server with the same shape as the closed offerings: Streamable HTTP at https://api.bex.co/mcp, browser OAuth in Claude Code and Cursor, headless API-key exchange to a short-lived token for CI. The differences are the ones this post has been building toward. The scopes are explicit and minimal (bex.read, bex.write, bex.sensitive, with identity-only scopes granting nothing). The deploy flow is validate-before-apply: read the render.yaml manifest, call validate_bex_yml, review the resource plan and pricing, then deploy — and validation explicitly does not pretend multi-resource rollout is atomic. Protected environments can demand a confirmation phrase. Self-hosted installations serve the same server from their own API origin, so the audit trail, the scopes, and the ceiling answer to the team that owns the machines.

None of that removes the operator's burden — running the server means carrying the on-call rota the closed vendors absorb — but it moves the trust boundary to a place you can inspect. When the toolset lacks a verb, the fix is a pull request, not a feature request. When a scope is too broad, the policy is yours to tighten. Agent-operated deploys concentrate power in whatever speaks last to the control plane; the question is whether that speaker works for you under a license you can read.

That is the summer-2026 scoreboard in one line: Render gave agents a deploy button, Fly gave them a computer, Railway gave them every chat window — and all three kept the server. The platforms racing to become the hands of coding agents are still asking you to place your infrastructure inside their fists. An open MCP server inverts the grip: the agent's hands, your machines, scopes you wrote, and a trail you keep.

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