Letting an AI agent deploy your app, safely

Giving a coding agent push access to production sounds reckless until you look at what it actually needs to do day to day: check if a deploy went out, read the last 100 log lines, restart a stuck process, maybe set an environment variable. Most of that is read-only. The small part that isn’t should still require a human to say yes.

That’s the shape Railyard’s Model Context Protocol server is built around, not an afterthought bolted onto an API that was designed for something else.

Connecting an agent

Railyard runs an MCP server at https://app.railyard.run/api/mcp over streamable HTTP, authenticated with the same API tokens the CLI and REST API already use. Create one under Settings → Team → API tokens, pick read if the agent should only ever look:

claude mcp add --transport http railyard https://app.railyard.run/api/mcp \
  --header "Authorization: Bearer rly_..."

Cursor, or any other MCP client that speaks streamable HTTP and can send an Authorization header, connects the same way — point it at the URL, pass the token.

What the token actually allows

The tool list is small on purpose: list_servers, list_apps, get_app, and app_logs are read-only. deploy_app, restart_app, and set_env need a write token. That’s the whole surface for day-to-day agent work — nothing about servers, domains, or databases is exposed here; those still go through the REST API or CLI, deliberately out of the agent’s reach by default.

The permission boundary is the token, not a prompt. An agent with a read token physically cannot deploy anything, no matter what it’s asked to do or what it decides on its own — there’s no instruction that talks a read-only token into a write action.

The part that waits for you

Two tools — unset_env and delete_app — are marked approval, even on a write token. Neither runs when the agent calls them. Instead, a request appears on the team’s Approvals page, visible from the dashboard, and nothing changes until a team admin approves it. Approving runs the action and records the result; rejecting just drops it.

This is the line that matters: an agent can deploy your app, restart it, and tweak its environment on its own, because those are recoverable — a bad deploy rolls back, a restart is just a restart. Removing a variable or deleting an app isn’t recoverable the same way, so it waits for a person, every time, regardless of how the token was scoped.

Deploys an agent starts still go through the app’s existing deploy approval and rate limit, same as a deploy triggered from the dashboard or a git push — the agent doesn’t get a faster or looser path than you do.

Good habits, not just good defaults

• Give each agent its own token with an expiry, and revoke it when the task is done rather than leaving a long-lived credential in an agent’s config.
• Default to a read token for agents that mostly answer questions (“why is this endpoint slow?”) and only hand out write when the agent’s actual job requires it.
• Treat the Approvals page as a real review step, not a rubber stamp — it exists because unset_env and delete_app are the two actions on this list you can’t easily undo.

Full tool reference and token scopes: MCP for AI agents.