Dora NodaThe interesting thing about a PaaS appearing in ChatGPT is not that someone can type “deploy my app” into a new chat window. It is that deployment, logs, variables, cost controls, and rollback are becoming distributable capabilities. Once those capabilities can surface in Slack, Discord, a coding agent, and a general-purpose chatbot, the chat app cannot be the place where their meaning or safety lives.
Railway made that shift unusually visible in July 2026. Its agent reached Slack and Discord on July 10, its Grok Build plugin followed on July 16, and its ChatGPT plugin arrived on July 31. The three releases are a useful case study because Railway did not describe three separate platform APIs: the plugins use its hosted MCP server and operating skills, while actions continue to use the connected person’s Railway access level. The Slack and Discord release, Grok release, and ChatGPT release make the progression explicit.
The lesson for a self-hosted PaaS is not “ship a plugin everywhere.” It is: build an open control plane first, then make each chat client a deliberately thin entry point.
The answer: one durable control plane, many chat entry points
An open control plane is not merely an MCP endpoint. It is the capability-and-authorization contract that stays stable while the chat hosts around it change. The table below is the practical artifact a platform team should have before it publishes a second chat integration.
| Durable control-plane contract | What the chat adapter may do | What it must not own |
|---|---|---|
| Resource state: services, environments, releases, domains, jobs, and their current desired/observed states | Turn a request such as “show checkout’s failed deploys” into a read request and present the result | Invent a second model of what is deployed or healthy |
| Mutation semantics: create a deploy, update a variable, scale, roll back, cancel | Collect parameters, render a plan, and send one idempotent command | Decide what a successful deploy or rollback means |
| Operations: long-running work has an ID, stages, timestamps, result, and error | Poll or subscribe, then summarize progress in conversation | Pretend an accepted asynchronous request has already completed |
| Identity and scopes: a person/workload identity with workspace, project, environment, and action bounds | Start an OAuth connection and show the actor | Mint an all-powerful platform token or substitute its own identity |
| Policy and approval: environment rules, change windows, required reviewers, and budget limits | Request confirmation and display the policy decision | Bypass a production rule because a prompt sounded urgent |
| Audit evidence: who asked, which client invoked it, what input was approved, what changed, and the operation outcome | Attach a conversation/reference ID where policy permits | Keep the only record of a production change in a chat transcript |
This arrangement is deliberately boring. A new host may require a different installation flow, widget, skill format, or consent screen. It should not require a new deployment controller, a new RBAC interpretation, or a new definition of rollback. The adapter translates interaction; the control plane remains authoritative.
That is also how the title’s “open” claim should be understood. The platform need not publish every internal implementation detail, nor grant every connected client write access. It does need documented, portable resource and operation semantics so another client can use the same guarded capabilities without reverse-engineering a dashboard.
What Railway’s rollout actually puts behind each plugin
Railway’s July sequence is more than a marketing tour of chat interfaces. On July 10, its Slack and Discord integration let a teammate inspect deployments and logs or make changes after linking both the workspace and their personal Railway account; access is checked on each message. On July 16, the Grok Build plugin bundled the use-railway skill, Railway’s hosted MCP server, and a hook for Railway CLI/API calls. On July 31, the ChatGPT plugin used the hosted server at mcp.railway.com and the same operating knowledge for provisioning, diagnosis, redeploys, and variable changes.
The important invariant is the personal access boundary. Railway says its ChatGPT integration acts with the user’s personal access level, and its Slack/Discord agent immediately stops responding if that person leaves the Railway workspace. That is a better model than a bot that receives one durable administrator credential and quietly impersonates everyone in a channel.
Railway’s current integration documentation makes the boundary clearer still: plugins package a skill with the hosted Railway MCP server, while connectors expose that hosted server directly. The documented integrations now span ChatGPT, Codex, Claude, Claude Code, Grok, and Cursor. Railway’s plugins and connectors guide is a concise illustration of one capability backend reaching many assistant environments.
There is a caveat worth preserving: a plugin can choose unsafe defaults. The Grok release, for example, describes a hook that auto-approves Railway CLI and API calls. That may reduce friction in a coding workflow, but it is not a policy model a platform should carry unchanged into production. “The client can issue a command without asking again” and “the control plane is permitted to change production” are separate decisions.
A deploy-from-chat path that stays reviewable
Here is a representative production request: “Deploy release 42 of checkout to production. If the health check fails, roll it back.” A safe chat experience should expose the real control-plane path rather than hide it behind a cheerful success message.
- Resolve context read-only. The adapter asks the control plane which
checkoutproject and production environment the caller can access, what release42contains, the current revision, current health, change-window state, and relevant budget limit. Ambiguous names stop here; the agent should ask which project rather than choose one. - Create a plan, not a deployment. The control plane returns a plan: image digest or commit, target environment, changed variables, replica/resource delta, health gate, and the rollback target. It also returns a policy result, for example: “production deploy requires the release manager’s confirmation; automatic rollback is allowed only to the immediately previous healthy revision.”
- Obtain approval at the risk boundary. The chat client shows that exact summary and submits a confirmed request bearing an approval reference. A read-only diagnosis requires no confirmation; a production variable edit, deploy, or rollback does. The client cannot turn a free-form “yes” from an unrelated Slack participant into authorization.
- Submit one idempotent mutation. The control plane accepts
createDeploymentwith an idempotency key, actor, target, release digest, policy/approval references, and client identity. It returns an operation such asop_7f3…, initiallyaccepted. A retry after a dropped chat connection returns the same operation instead of starting a second deployment. - Report evidence, then finish. The adapter follows the operation through building, rollout, health checks, and completion. Its final message links the deployed revision, health evidence, timestamps, and audit record. If health fails, the pre-approved rollback becomes a second explicit operation with its own status—not a line the model claims it executed because the word “rollback” appeared in the prompt.
This flow is useful because it covers the awkward, normal case: a connection is lost, a name is ambiguous, a deployment is asynchronous, and production policy differs from staging. A chat client can make this path pleasant. It should not erase any of those facts.
MCP is the transport, not the control plane
MCP is a strong fit for exposing tools and context to assistants, but a tool schema alone does not make a portable platform contract. Two tools named deploy can differ on whether they build from a branch or image, whether they wait for health, whether a retry is safe, whether they reveal a secret in an error, and whether “production” was protected. Those behaviors belong below the chat layer.
| Layer | Portable responsibility | Example |
|---|---|---|
| MCP/client adapter | Tool discovery, structured input/output, conversational status, host-specific UI | plan_deployment, submit_deployment, and get_operation exposed to ChatGPT, Grok, or a terminal agent |
| Control-plane API | Versioned resource model, operation lifecycle, pagination, idempotency, and errors | A deployment has a target revision, operation ID, state transitions, and machine-readable failure reason |
| Authorization service | OAuth connection, scopes, token audience, actor-to-workspace mapping, and revocation | A token can read production logs but cannot update variables or deploy |
| Policy/audit service | Environment rules, approvals, budgets, immutable event trail | A production rollback requires an approved change reference and records the requesting client |
| Reconciler/executor | Makes desired state real and reports observed state | Applies a release, watches rollout/health, and writes the terminal operation result |
The MCP authorization specification provides useful building blocks for this split: HTTP MCP servers use OAuth-based authorization, with protected-resource metadata for authorization-server discovery and resource indicators that identify the intended server. It also requires secure token handling and calls out audience binding. The MCP authorization specification is a protocol foundation, not a substitute for platform RBAC or deployment policy.
That distinction matters for self-hosting. A team may start with one MCP server and one assistant, then add a corporate chat bot, an IDE plugin, or an internal portal. If every client calls the same documented resource and operation API, the new adapter is integration work. If the agent behavior, authorization, and reconciliation were fused into the first plugin, the team has created another opaque PaaS surface to maintain.
The non-negotiables for a self-hosted control plane
Chat changes the user interface, but it also expands the route by which a misleading instruction can reach privileged infrastructure. The controls should be explicit and proportionate to the action.
| Risk | Minimum control | How the policy should vary |
|---|---|---|
| Over-broad or leaked token | Short-lived, audience-bound tokens; granular action/environment scopes; immediate revocation | Production write scopes should be narrower and shorter-lived than development read scopes |
| Prompt injection in logs, tickets, or repository content | Treat retrieved text as untrusted; never grant approval because tool output says to; separate planning from mutation | Higher-risk actions require a human-confirmed plan that names exact targets and changes |
| Confused deputy in a shared channel | Bind every call to the individual user and re-check workspace membership/role | Channel membership is never equivalent to production deploy authority |
| Duplicate or invisible deploys | Idempotency keys, durable operation status, audit events, and clear accepted versus succeeded states | Production operations retain longer evidence and emit notifications to the owning team |
| Surprise agent spend or runaway changes | Per-workspace and per-agent limits, rate limits, and bounded retries | Development can permit lower-risk automation; production needs stricter spend and concurrency caps |
OpenAI’s Apps SDK is itself built on MCP and presents external tools inside ChatGPT; its documentation also emphasizes connection-time awareness of what data may be shared. OpenAI’s launch announcement is a reminder that a chat host’s consent UI is valuable, but it cannot own the platform’s complete authorization and audit story. The platform must still know which resource was touched, who had authority, which policy ran, and what actually happened.
Distribution changes; ownership should not
Railway’s July releases are evidence that deploy-from-chat is becoming a distribution channel, not a novelty button. The same platform actions can now meet users where they already ask questions: a team channel, an IDE agent, a coding terminal, or a general chatbot. That can shorten the distance between “why is this red?” and the evidence needed to answer it.
But a provider-hosted plugin is only one possible interface. Teams that need to run their own infrastructure, retain the full audit trail, or choose their own assistant should keep ownership of the control-plane contract. Build stable resources, operations, identities, policies, and reconciliation once. Then let chat clients compete on interaction quality while the deployment system remains legible, governable, and portable.
Sources
- Railway: “Feature flags, Railway Agent in Slack & Discord, usage limits in the CLI”
- Railway: “Railway plugin for Grok, manage CDN caching in the CLI”
- Railway: “Railway plugin for ChatGPT, dev.new preview, new observability panels”
- Railway documentation: Plugins and connectors
- Model Context Protocol: Authorization specification
- OpenAI: Introducing apps in ChatGPT and the Apps SDK
