Stripe's Agentic Provisioning Protocol Puts Railway One CLI Command Away — and Draws the Line Where MCP Stops

Your agent just wrote you a full-stack app. Getting it running still means a signup form, a billing page, an API key pasted into a dashboard, and a connection string copied into .env — every one of those steps a human errand the agent watches from the sidelines. Railway's diagnosis of that gap is the sharpest sentence any PaaS has written about agents this year: 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."

On March 27, 2026, Railway shipped its answer in changelog #0283: an integration with Stripe Projects, built on Stripe's Agentic Provisioning Protocol (APP) spec, that provisions Railway resources from the Stripe CLI. The transcript is the whole pitch:

$ 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

This post dissects that flow command by command, names the three moving parts underneath it, draws the exact line where MCP stops and provisioning starts, and turns all of it into a checklist for what a self-hosted PaaS must build before a third-party protocol defines what "provision me infra" means.

The flow, concretely: one-time setup, then one command per resource​

"One CLI command away" needs one honest qualification, and Railway's own docs make it: there is a one-time setup, and then there is the steady state. The setup runs once per machine — install the plugin, initialize, link the provider, browse the catalog:

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

link is where the magic concentrates. It creates your Railway account, sets up a trial with $5 in credits, and hands back credentials in a single round trip.

After that, every resource is genuinely one command: stripe projects add railway/postgres spins up a managed database and syncs the connection string straight to .env. No dashboard, no signup form, no billing page — just the resource you asked for.

Each CLI step replaces a specific human errand:

Railway's starting catalog covers PostgreSQL, MongoDB, and Redis, S3-compatible object storage ("Buckets"), and compute services from Docker images or GitHub repos. The company says agent sandboxes are next: ephemeral, isolated environments where an agent spins up infrastructure, tests against it, and tears it down without touching production. Note the direction of travel — five months later, in August 2026, Railway shipped deploys without a Railway account at all. The account is dissolving as a prerequisite; the protocol handshake is replacing it.

The three moving parts underneath​

One command is the interface. Underneath, every APP flow has the same three stages — discovery, authorization, payment — with a fourth, provisioning-and-configuration, landing the result. Cloudflare's April 30, 2026 launch on Stripe Projects, now in open beta, is the cleanest public description of the machinery, and it matches Railway's flow part for part.

Discovery: the agent queries a catalog, not a docs page. A REST/JSON service catalog returns what a provider offers — services, plans, prices — in a shape an agent can reason over. stripe projects catalog railway is the human-readable version; agents in the wild already script catalog <provider> --json and refuse to guess slugs. This is the step MCP never standardized: MCP connects an agent to tools somebody already configured, while APP lets the agent learn what exists before anything is configured.

Authorization: Stripe acts as identity provider, and the account appears. Stripe verifies who the user is; the provider either links the matching existing account over OAuth or provisions a new one automatically. On the wire, the APP reference implementation (version 0.1d) shows the shape: the orchestrator sends signed requests — Stripe-Signature: t=<timestamp>,v1=<signature> — to provider routes like POST /provisioning/account_requests, and the provider creates the account or initiates sign-in. Railway's plain-English version: "Stripe handles the KYC, you get an honest-to-Jones Railway account ready to ship to." None of this was greenfield for Railway — its earlier "Login with Railway" OAuth work supplied the account-creation and identity-linking primitives.

Payment: tokenized, capped, and human-approved — the agent never sees a card. Stripe issues a tokenized payment method the provider bills against, so raw card details never pass through the agent's context. Cloudflare's terms put a default $100-per-month spending cap per provider on agent-provisioned resources, and the human still accepts the provider's terms of service, with agents asking approval whenever payment details are required. Agent skills circulating on GitHub encode the same discipline: present the exact plan, pricing, and terms, get explicit approval, and only then run add with --accept-tos --yes. The pattern is approval-gated provisioning, not ambient spending authority.

Then comes the part Cloudflare names explicitly and Railway demonstrates implicitly: provisioning and configuration. The flow doesn't end with a paid invoice — the agent configures DNS records, deploys the Worker, attaches the domain, and produces a working setup. Runloop, which co-designed APP with Stripe and demoed autonomous software deployment in the Stripe Sessions 2026 keynote, states the three properties that make this trustworthy across providers: deterministic provisioning steps, a secure credential handoff, and resources that live in the user's own account with normal dashboard access. No shadow estate, no side-channel credentials.

(One aside to prevent a common confusion: Stripe now has three agent protocols, and they cover different layers. APP provisions infrastructure accounts and resources; the Agentic Commerce Protocol, co-developed with OpenAI as an open-source checkout spec, covers agent-driven purchases; the Machine Payments Protocol covers how agents pay. This post is only about the first.)

Where MCP stops​

Railway earned the right to draw this line because it ships both sides: it has an MCP integration its users love, and it built APP routes anyway. Its verdict is worth quoting at length:

"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... 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."

The changelog says the same thing in one sentence: "MCP is great for tool-calling when you already have a Railway account, but it has no concept of account creation, billing, or resource lifecycle management."

This is layering, not rivalry. APP provisions the account; MCP operates it. An agent that arrives with no account uses APP to get one — identity attested, trial funded, credentials synced — and then uses MCP tool calls (or REST, or a CLI) for everything after. Confusing the two layers produces the two failure modes the ecosystem keeps demonstrating: onboarding flows duct-taped onto tool calls that were never designed to create accounts, and agents handed standing credentials for operations that should have been provisioned per task. Railway's stack keeps them separate, and any platform copying it should too.

The scale argument for getting this right is sitting in Railway's own analytics: at the time of writing, 15,000+ new users a day were arriving, much of it agent-generated code looking for a long-term home across Railway's 4 regions and 40+ points of presence. Every one of those arrivals hits onboarding before it hits anything else. Whoever owns the first mile — signup to running resource — owns the default home for agent-built software.

The honest costs​

A post that only praised the flow would be a press release. Four costs come with the protocol, all visible in the launch materials if you read them skeptically.

A new trust layer with Stripe in the middle. Every provider flow now mediates identity and payment through Stripe: Stripe attests who you are, Stripe tokenizes how you pay. That centralization is the price of the one-command UX, and it means the agent's first mile for Railway, Cloudflare, Vercel, Supabase, and PostHog all answer to the same orchestrator. Teams that chose self-hosting precisely to avoid that kind of dependency should notice what they're being asked to reintroduce.

Open beta, supported providers only. Stripe Projects works where providers have built /provisioning/ routes and joined the catalog — Railway joined PostHog, Supabase, Vercel, and others in the developer preview wave, and Cloudflare's launch is explicitly an open beta. Anything outside the catalog is still signup forms and dashboards. A protocol with a handful of launch providers is a partnership program wearing a spec's clothes until the long tail arrives.

Agent-provisioned billing needs guardrails as code, not vibes. Cloudflare's $100 default cap is the right instinct, but it's one provider's default, not a protocol guarantee — and every agent with provisioning power is one misread catalog away from buying production-shaped resources. The approval-gated skill pattern (show plan, price, and terms; provision only after explicit human approval) needs to be the default posture, not folklore copied between dotfiles repos.

KYC is moved, not removed. "Stripe handles the KYC" is convenient right up until your threat model asks who verified what. The provider trusts Stripe's attestation; abuse teams that used to see the signup funnel now see signed account requests. Railway's own history with anti-abuse outages is the cautionary tale for what happens when account creation gets easier faster than abuse detection does.

None of these is fatal. All of them are load-bearing for the next section — because a self-hosted platform adopting this shape inherits every one of these design questions, with no Stripe to answer them.

What a self-hosted PaaS must build​

Here is the uncomfortable part for our side of the fence: bex's API already assumes a tenant account. So does every git-push PaaS API. APP's whole point is the path before the account exists — and if the only implementation of that path is Stripe's orchestrator fronting venture-backed providers, then "provision me infra" gets defined by a third party, on their identity system, with their billing meter, and self-hosted platforms get to implement somebody else's handshake. The alternative is building the same zero-to-deployed agent path natively. Seven primitives, in dependency order:

1. A queryable provider catalog. An endpoint that returns services, plans, and prices as structured data an agent can reason over — the catalog verb. If onboarding your deploy tools requires the agent to read your docs page, you have re-created the discovery tax for every agent × every project.
2. A link-or-create account handshake. One route that takes an attested identity and returns either an OAuth link to an existing tenant or a fresh account with credentials — APP's account_requests shape, with signed requests and replay protection. Railway built it on its Login-with-OAuth primitives; a self-hosted platform builds it on whatever SSO it already trusts.
3. Trial funding that isn't a credit card. Railway's $5 trial and Cloudflare's $100 cap are both answers to "what can a stranger spend before a human approves." On owned hardware the answer is quota, not dollars — CPU-hours, VRAM-minutes, byte-days — but the primitive is identical: a bounded grant, visible to the agent, enforced by the platform.
4. Provision-plus-credential-sync. The add verb must end with credentials in the project's environment, not in a dashboard widget. Railway syncs to .env; a self-hosted equivalent syncs to the project's env store or emits a file the agent's next command can source. A provision call whose output is "now go copy this" is half a verb.
5. Per-agent identity with spend caps. Every agent session gets its own identity, scoped to the task, carrying only the quota its job needs — never a shared platform token. Cloudflare's default cap is the model; make it a platform guarantee, not a provider default.
6. Human approval bound to the exact plan. Terms acceptance and any spend above the free grant require explicit approval of the concrete plan — this service, this price, these terms — mirroring the --accept-tos --yes pattern. A broadly scoped agent token must never count as standing permission to buy.
7. A full audit trail. Who (which agent identity) provisioned what (which service, which version) under which grant, and what it cost — queryable by the next agent session, not just by a human in a dashboard. Chat history is not the source of truth; the provisioning log is.

Items 1–4 make the platform's resources reachable without a human; items 5–7 make them safe to reach. What self-hosting changes is the funding instrument (quota instead of cards) and the identity anchor (your SSO instead of Stripe's). What it can't skip is the handshake shape: catalog → attested identity → bounded grant → provisioned resource with synced credentials. That shape is the actual standard APP is proposing, whatever logo sits on the orchestrator.

Whoever defines "provision me infra" owns the agent's first mile​

Step back and the trajectory is unmistakable: in March, Railway made onboarding one command per resource; in April, Cloudflare extended the same protocol to accounts, domains, and Workers; in May, Runloop demoed autonomous deployment on a Stripe keynote stage; by August, Railway was letting people deploy with no account at all.

Each step moves the same direction: less prerequisite, more protocol, with the human retained exactly where judgment is required — terms, money, consequences. MCP won the argument about how agents call tools. The open argument is how agents arrive — and arrival is currently being standardized by a payments company, which should tell infrastructure people everything about where the leverage sits.

A self-hosted PaaS that builds the seven primitives above doesn't just match the hosted UX; it offers the one thing Stripe's orchestrator structurally can't, which is an arrival path where identity, quota, and audit never leave machines you own. Build it before "provision me infra" is a sentence your users can only say to somebody else's protocol.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Agents are first-class operators: a Render-compatible API plus machine-readable infrastructure state they can deploy against today. Star the repo on GitHub or deploy your first app today.