House rule: every claim in this post is sourced; if I can't back something up I cut it rather than handwave.
If you've been watching the agentic coding space, you already know the shape of it. Claude Code, Cursor, Codex (and the long tail of forks) have gone from autocomplete-with-vibes to collaborators that open PRs, run tests, read logs, and fix their own mistakes. What hasn't been obvious, until recently, is which platforms are built for this loop. Most clouds give you a console, a CLI, and a shrug. The agent ends up doing screen-scraping cosplay with a headless browser, or asking you to copy-paste IDs into chat like it's 2014.
This piece is a practitioner walkthrough. I want to teach you how to point Claude Code, Cursor, or Codex at Railway and ship real production workloads end to end, not spin up a hello-world and call it a demo. I'll show you the workflows that work today, the ones that still stall, and the gotchas I've watched teams hit hard enough to bruise.
The phrase has been beaten flat by marketing decks, so here is the ground truth.
An agentic IDE is an environment where the model is allowed to take actions, not suggest them. Claude Code runs in your terminal and edits your repo. Cursor lives in the editor and does the same plus inline review. Codex (the OpenAI flavor) tends to spin its own sandboxed branches. All three share one trait: they call tools, read the results, and decide what to do next without you in the loop for every step.
MCP (Model Context Protocol) is the glue. It's an open protocol Anthropic shipped in 2024 and the rest of the industry adopted faster than anyone expected. MCP servers expose tools (functions) to any compatible client. That's how your agent learns to do anything outside its training corpus: file ops, git, Linear, Postgres, Railway.
Agent-driven deploys means the agent doesn't hand you a railway up
command to copy. It runs the command. It reads the build logs. It notices the build failed because you forgot a Dockerfile, writes one, and redeploys. You watch.
Agent-as-validator-of-own-PR is the loop that matters most: the agent opens a PR, Railway spins up a preview environment with a fresh database, the agent runs its integration tests against the preview URL, and only then does it ping you for human review. The agent is doing what a careful junior engineer would do, except in ninety seconds.
Three things matter, and they're connected.
Complete MCP coverage. Railway ships an official MCP server that exposes the full surface area of the platform. Every operation you can do in the CLI or the dashboard, the agent can do too: create projects, link services, set variables, deploy, read logs, fork environments, roll back. There are no "you'll have to do this part in the UI" footnotes. If you've used a PaaS where the agent eventually hits a wall and asks you to "click through the onboarding flow," you know how badly that breaks the loop. The agent stalls, you context-switch, the magic dies. Railway's MCP doesn't have those dead ends.
Stripe Projects CLI for stack provisioning. Railway recently shipped support for the Stripe Projects CLI for account-to-prod provisioning. Its stripe add
command provisions managed infrastructure and is built for agent-driven workflows. What this means in practice: an agent acting on your behalf can sign you up, pay, and stand up a running stack in one continuous loop. No human-in-the-middle for the parts that used to require a card form and a verification email. If you're skeptical of the security implications, jump to the gotchas section. There are real ones. But the loop closure works.
Agent-friendly primitives. This is the underrated one. Railway's product was built around a small set of primitives that happen to be exactly what agents need:
- Per-PR preview environments with isolated databases. The agent opens a PR, gets a full clone of staging with its own Postgres, and can break things without fear. When the PR closes, the environment is reaped.
- One-click rollback to any prior deploy. The agent doesn't need to git-revert and redeploy and hope. It promotes a known-good build in one call.
- Environment promotion. Variables, services, and config can be promoted from staging to production as a single atomic operation. Agents don't have to reason about drift.
- Secrets per environment. Production secrets never leak into preview branches, which means the agent can have broad permissions in dev without you sweating about a model hallucination running
DROP TABLE
in prod.
Put together: the agent can do everything you can do, the loop never breaks, and the blast radius is bounded by primitives the platform enforces.
These are real workflows I run, or have watched customers run, on production traffic.
Open Claude Code in an empty directory. Type:
Build me a Fastify API with a /healthz endpoint and a /users
CRUD route backed by Postgres. Deploy it to Railway and give
me the URL.
What happens: Claude scaffolds the repo, writes the Fastify app and the Prisma schema, runs npm install
, commits to git, then calls the Railway MCP to create a project, link the service, provision a Postgres database, set DATABASE_URL
, and deploy. When the build finishes, it reads the deploy logs to confirm the migrations ran, then returns the public URL.
End state: a running service in production. Total wall time the last time I ran this was about four minutes, most of which was npm install
.
You have a service deployed. You want a database.
Add a Postgres database to my production environment, run
migrations from prisma/schema.prisma, and redeploy.
The agent calls the Railway MCP to add a Postgres plugin to the environment, captures the injected DATABASE_URL
, links it to the existing service, triggers a redeploy, and tails logs until the Prisma migration completes. If a migration fails (column type mismatch, missing extension), the agent reads the error from the log stream and fixes the schema before retrying. No browser, no copy-paste.
Create a preview environment for the current branch, clone
the staging database into it, deploy, and give me the preview
URL.
The agent forks the staging environment (Railway calls this a "PR environment" or "ephemeral environment" depending on the integration), snapshots the staging Postgres, links the new branch to deploy into the forked env, waits for the build, then hands you a URL. The preview's database is isolated. The agent can run destructive migrations, seed test data, or wipe rows, and nothing touches staging.
This is the workflow that changed how I review PRs. I stopped reading code first. I open the preview URL, click around, then read the diff.
Production deploy fails. You ping the agent.
Production deploy 7f3a2b failed. Find out why and fix it.
The agent calls the Railway MCP to fetch the failed build's logs, parses the error (let's say it's a missing OPENAI_API_KEY
because someone added a new dependency that imports it at module load time), inspects the codebase to confirm, asks you for the key (or pulls it from an existing environment via promotion), sets the variable, and retriggers the deploy. It tails the new build logs to confirm green.
The thing worth noticing here is that the agent isn't pattern-matching on the word "failed." It's reading actual log lines, locating the stack trace, and reasoning about which environment variable maps to which import. That's only possible because the MCP returns structured log data, not a screenshot.
This is the apex workflow.
Implement the rate-limiting middleware described in
LINEAR-2847. Open a PR, deploy to a preview environment, run
the integration tests against the preview URL, and only mark
the PR ready for review if they pass.
The agent writes the middleware, opens the PR, the GitHub integration triggers a Railway preview deploy, the agent waits for the build (polling the MCP, not refreshing a browser tab), runs the integration suite with the preview URL as the base, parses results, and either marks the PR ready or pushes additional commits to fix what broke. You get pinged once, at the end, with a green PR.
I've watched this loop run unattended for forty-five minutes on a moderately complex feature. The agent shipped three corrective commits before flagging me. The final diff was cleaner than what I would have written in the same time.
At a glance:
Maturity matrix of agentic capabilities on Railway: deploy, logs, env vars, preview envs and rollback are mature; long migrations still stall, with what to watch for in each
Works well today:
- Scaffolding, deploying, and configuring services. The MCP coverage is mature.
- Reading logs and reasoning about failures. Structured log output makes this tractable.
- Managing environment variables and promotions across staging/production.
- Preview environments and ephemeral databases. The primitives compose cleanly.
- Rollbacks. One MCP call, no ambiguity.
Still stalls sometimes:
- Long-running migrations where the agent doesn't have a great mental model of progress. It can read logs, but a six-minute index build looks identical to a hang at minute three. You'll see agents impatiently cancel and retry. Set timeouts explicitly in your prompts.
- Complex multi-service orchestration where service A depends on B depends on C with circular config. Agents tend to deploy in the wrong order and then untangle, which works but isn't elegant. Better prompting (or a written runbook the agent reads first) helps.
- Reasoning about cost. The agent will happily provision a beefy Postgres instance because the spec said "production-grade." See the gotchas section.
Coming, or already landing as I write this:
- Tighter Stripe Projects CLI integration for fully agentic onboarding, with finer-grained spend controls so the agent can provision but not overshoot a budget cap.
- Better support for agents running long-lived background jobs (think nightly batch loops) where the agent is more orchestrator than coder.
- Richer MCP tools for observability: tracing spans, error budgets, SLO checks. Right now the agent can read logs but doesn't have first-class access to distributed traces. That gap is closing.
I'd rather flag the rough edges than pretend they aren't there. The platform is good enough today to ship real workloads. It's not yet good enough to leave unsupervised on critical-path production.
Things I've watched go wrong.
-
Scope tokens narrowly to environments. When you create a Railway token for the agent, scope it to a single environment (staging, ideally) for most workflows. A token with production write access is fine for senior engineers; it is not fine for an agent loop you're still tuning. Most accidents I've seen weren't malicious models, they were agents enthusiastically applying a fix to the wrong env.
-
Always require human review on production promotions. The agent can prepare the promotion, run the diff, validate the preview, and tee everything up. The final click should be yours. Configure protected environments in your repo settings and require manual approval on production deploys. The five seconds you spend on the approval are worth it.
-
Set spend alerts. Agents are confident. If you tell one to "make this scale," it might decide that means an 8-vCPU Postgres and a Redis cluster. Railway has usage alerts; turn them on. Pick a number that would make you wince, and set the alert at half of that.
-
Watch for the over-correcting agent. Revert loops are a real failure mode. The agent deploys, sees a transient error, rolls back, redeploys the previous version, sees a different transient error, panics, rolls forward again. If you notice the deploy history flapping, the agent and read what it's responding to. Often it's a downstream service hiccup the agent is mistaking for its own bug.
-
Pair agentic workflows with proper observability. The agent can read Railway logs. It can't read your APM tool unless you give it an MCP server for that too. If you're running anything complex, plug in Sentry, Datadog, or whatever you use. The agent's debugging quality is bounded by what it can see.
-
The agent is fast but doesn't know your business constraints. It will happily deploy the right code at the wrong moment. The pre-Black-Friday freeze, the compliance review window, the customer demo at 2pm. Calendar context isn't free; if those constraints matter, write them down somewhere the agent reads (a
CLAUDE.md
, a project README, a system prompt) and remind it. Speed without judgment is just speed.
Agentic coding is the first developer-tooling shift in a decade where the platform you choose matters more than the editor. The agent only goes as far as its tools let it. If the platform has gaps, the agent stalls there. If the platform composes cleanly, the agent goes the distance.
Railway was built (years before agents were the story) around primitives that turned out to be exactly what agents need: full API and MCP coverage, isolated environments, one-click rollback, environment promotion, per-env secrets. The Stripe Projects CLI support closes the last loop: an agent can take you from zero to running production in a single conversation.
Pick a workflow above. Run it tonight. If it stalls, ping me; I'd rather hear about the rough edges than have you give up on the platform.
Happy shipping.
Angelo
Angelo Saraceno is a Solutions Engineer at Railway. Before Railway he was at Citrix, working inside Verizon and Lockheed environments, so he has seen what "enterprise IaaS" looks like after the slides come down. He writes about infrastructure, deployment, and the gap between how cloud is sold and how it runs in practice.