Bottom line up front. We've partnered with Stripe and built on their new Agentic Provisioning Protocol spec to let developers sign up and deploy in one command.

$ stripe projects link railway
✓ Successfully linked Railway account

$ stripe projects add railway/postgres
✓ Provisioned PostgreSQL — credentials synced to .env

$ stripe projects add railway/hosting --config '{"image": "nginx:latest"}'
✓ Deployed nginx:latest on Railway

Install the projects plugin in the Stripe CLI and you get access to their provider catalog where you (or your agent) can provision Railway resources on demand. We join PostHog, Supabase, Vercel, and others in their developer preview as Stripe grows the APP ecosystem — and we're glad they invited us to be in the first wave.

To see why we went ahead and built a new set of /provisioning/ routes, read on.

---

Let's open with two statements:

1. LLMs are a game-changing technology.
2. We're still figuring out what that means for all of us.

I used to derive joy out of sitting in my terminal, typing out and stepping through a problem. Maybe 6 or 7 hours, going through the motions of crafting functions, wiring up calls, and spamming console.log until I got what I wanted.

Now?

I roll for charisma on Claude, trying to convince the thinking machine to whip up a feature given some context about the problem I'm trying to solve and...

"Remember, I said make no mistakes."

Voilà. We get code.

For Railway, this means that everyone is a developer now. And a lot of you are bringing your creations to Railway when they need a long-term home.

So much so where at the time of writing, you're joining us at 15,000+ new users a day.

The demand for compute is insatiable, and we're all about being the quickest place for developers to deploy. Any language from JS, Go, to Python to Rust, anywhere (in our 4 regions and 40+ PoPs).

(And yes, you can deploy your web apps to Railway! I don’t know why people think you can’t deploy a front-end to Railway.)

We like to think we are known for having excellent developer ergonomics, but we can always do better. So when we saw a message in a shared Slack channel (that our internal support tool caught), our interest was piqued.

Remove Friction, Always

Let's take a step back and talk about Railway's mission.

We want to make every builder unstoppable. Our mandate is to give them tools that dramatically increase their odds of success, whatever they do.

These builders are usually fighting entropy in many ways. Like, angry customers, their first or millionth user, or when they drown in feedback. But always, chaos.

So it’s important to provide calm wherever we can… and for us, that's infrastructure.

The status quo was (and still is) a scary cloud platform interface where different PMs of different teams fight over management console real estate to surface one of the most basic primitives every builder needs: compute.

Railway specializes in just that. Push button, get compute. We scale the rest.

There is a sort of implication that the brave new world of LLMs and agents bring us to, the web app isn’t dead, but if a developer lives in their terminal more, and just does everything via the terminal- are we removing the friction in the right areas?

This led to a short spiral but the answer was clear- we then became obsessed with making Railway visible to agents.

Enter OpenAI Tools, A2A, and MCP

The good news was that foundation model labs were also thinking about trying to get the models to use vendors at the same time.

Over the last year or so (keep in mind, o1 shipped on December 5, 2024, which really feels like 5 years ago at this point) each foundation model provider took a stab at connecting models to external tools. When we looked into supporting them, we felt they didn't provide portability. Work spent integrating A2A wouldn't give us any benefit on a different marketplace. Especially when the model would just lean towards crafting a GraphQL call to our API anyway. (Or use our CLI.)

Of the pre-MCP attempts, I liked OpenAI's design the most because it let you register tools directly in the OpenAI App Store. But it was limited to OpenAI's models, so adoption stayed niche.

When MCP came along, it had the criticism that it felt designed by committee- and in fairness, these standards usually are. (Hi CNCF!)

But what let MCP grow where others didn't was that the spec was loosely defined and the different marketplaces weren't too particular about early implementation. Servers could run locally or operate standalone. It left matters of implementation in the vendor's hands, which was fine from our perspective.

When we felt that vendors were fully committed to MCP, we got to work porting our CLI functionality to this paradigm. We shipped our first MCP server in June 2025.

And it was... crickets.

What Do AI Agents Actually Need?

I don’t get the hate around MCP by the way. This is not a MCP hate blog.

MCP is great for tool-calling, it lets an existing user who already has a Railway account ask their agent to deploy a service or check logs. It works great and our users love it. …and the fact that you have a separate install flow unless you have a desktop app is very confusing for a lot of users.

But namely, it’s a tool augmentation for people who already know Railway.

What it doesn't solve is onboarding.

A brand new user, or an agent acting on behalf of one, can't sign up, set up billing, and provision infrastructure through MCP. There's no concept of account creation, payment credentials, or resource lifecycle management in the spec. MCP connects tools to users and handles access patterns, that’s all it’s intended for.

Meanwhile, many of you develop in ways that range from babysitting your LLM and auditing every step (fair) to multi-track drifting 24 Warp sessions with a mix of Claude Code, Cursor, or Codex. (also fair)

In all of these flows, the terminal is the center of gravity. And in all of them, the gap isn't "how do I call Railway's API" — it's "how do I go from nothing to deployed without leaving my editor."

That's the gap we think Stripe's Agentic Provisioning Protocol fills.

Logic Needs a Home

With all the code that LLMs are generating: it still needs to run somewhere.

Stripe, in our opinion, has done a great job being the home for near everything business related. Oft underreported is how Stripe Atlas handles 25 percent of new Delaware C-Corp incorporations. Every business needs payment rails, and now every business deploys software. So we felt that there was mission alignment when they pitched us APP.

We now see through our analytics that nearly every agent session that produces a working app. Leading to hundreds of thousands "I can't believe that worked" moments when people see it deploy in one shot on Railway.

When it came to working around the limits of MCP, we strongly felt that the path from "Claude just wrote me a full-stack app" to "it's running in production" should be one command.

So… that's what we built.

Stripe's APP spec gave us the right abstraction: a protocol-level way to handle account creation, billing, and resource provisioning in a single flow. When you run stripe projects link railway, we create your account, set up a trial with $5 in credits, and hand back credentials in one round-trip. When you run stripe projects add railway/postgres, we spin up a managed database and sync the connection string to your .env.

Stripe handles the KYC, you get a honest to Jones Railway account ready to ship to.

No dashboard. No signup form. No billing page. Just the resource you asked for.

What's Here and Soon

So as of today (March 29th, 2026) we're in alongside the other providers in Stripe's catalog. Right now you can provision:

• PostgreSQL, MongoDB, Redis - standard template databases
• Object Storage - S3-compatible buckets, or just Buckets as we like to call ‘em.
• Compute Services - deploy Docker images or GitHub repos

To use it today if you have the Stripe CLI installed, all you need to do is:

stripe plugin install projects
stripe projects init
stripe projects link railway
stripe projects catalog railway

This is just the starting catalog. We're actively working on agent sandboxes - ephemeral, isolated environments where your agent can spin up infrastructure, test against it, and tear it down without touching production. Think of it as a scratchpad for agents that need to try before they deploy.

And we're building something bigger on top of all of this.

(As well as a iOS App for those who thought that the H1 mentioned this was an app.)

Worth noting: none of this would have been possible without the work we did on Login with Railway. That investment gave us the building blocks for new user provisioning creating accounts, linking identities, and you too can build on the same primitives we use.

Happy shipping!