run402: backend infrastructure that lets AI agents pay their own way

What run402 actually solves

run402 solves a specific mismatch: most backend platforms assume a human signs up, copies an API key, and clicks through a dashboard. An autonomous agent cannot do that. run402 is a backend-as-a-service addressed to a machine. The README is explicit: an agent provisions a Postgres database, user auth, file storage, serverless functions, and site hosting, ships them in one atomic deploy, and pays for usage itself. The intended users are AI agents and coding agents. The project is the backend that Kychee's open products run on, and the first product is kysigned. This is not a toy. It is a working layer for agent-driven applications.

Agent-first identity and authority model

The core design decision is that agents are first-class principals, not borrowed human accounts. The README states that a person or agent acts through its own Run402 principal and authenticator, and actions remain attributable. Identity answers who acted; memberships, roles, grants, delegates, freshness, and spend policy determine what that principal may do. An autonomous agent can remain the legitimate owner of an org-of-one it creates. People can join through explicit co-ownership. Agents entering someone else's organization receive bounded authority instead of borrowing a human account. This is a meaningful departure from platforms where a service account is a second-class credential. Different keys, equal standing, explicit authority. That model is worth understanding before you build on it.

The surfaces: SDK, CLI, MCP, and more

The repository ships multiple surfaces, all sharing a typed kernel in @run402/sdk. The CLI is a thin shim over the SDK action runner. The MCP server exposes core operations as tools for Claude Desktop, Cursor, Cline, and Claude Code. There is an OpenClaw skill for agents that do not use MCP, and a Buzz integration that lets a person or agent install run402, preflight identities, deploy a contextual demo, and offer human co-ownership through a normal HTTPS/passkey handoff. The @run402/functions package is imported inside deployed functions and provides helpers like db(req?), adminDb(), auth.user(), email, ai, and assets. The @run402/astro integration layers the SDK and functions runtime into Astro's build and SSR flow. The README says to pick whichever interface fits your runtime. The architecture is consistent: MCP tools, CLI subcommands, and OpenClaw scripts are thin shims over SDK calls.

How you get it running

The 30-second start is simple: install the CLI globally with npm install -g run402@latest, then run run402 up --name my-app -y. That command bootstraps allowance, tier, project, and link, then deploys the manifest. You get a real Postgres database and a deployed static site, paid for autonomously with testnet USDC. You can claim a subdomain with run402 subdomains claim my-app, giving you https://my-app.run402.com. The CLI accepts JSON in and JSON out, with an exit code on failure. For validation, use --check for local validation and --plan for gateway-reviewed intent before applying. The project resolution order is --project, .run402/project.json, manifest project_id, approved creation from --name, then approved active-project fallback. The --name flag is metadata only; it never renames an existing project. If the manifest defines verify.http[], run402 up verifies those URLs after deploy.

Paying with x402 and the receipt policy

run402 is paid with x402 USDC on Base, or Stripe credits, and the prototype tier is free on testnet. The README gives a concrete payment example: run402 pay https://seller.example/translate --method POST --body '{"text":"hello"}' --max-usd 0.05 --idempotency-key translation:1 --require-receipt. The SDK equivalent is r.pay.fetch(url, init, { maxUsdMicros, idempotencyKey, requireReceipt }). All three surfaces return the same x402-commerce-result.v1 settlement with movement, replay, delivery, offer, merchant-receipt, signer-relationship, policy, and raw-evidence fields. Unpriced URLs pass through with payment: null. Requiring a receipt rejects before payment when no wallet-rooted offer is eligible. If a promised receipt cannot be verified after settlement, PaymentPolicyError retains the upstream response and paid result and tells the caller to reconcile, never to pay again. For a trusted Run402 PAYMENT_INTENT_PENDING, all three surfaces prescribe one recovery path: wait for Retry-After, then repeat the same request with the same payer and key. Never replace the key.

Limitations and failure modes

The most obvious limitation is that run402 is not a general-purpose backend. It is tightly coupled to the x402 payment ecosystem and to the run402 cloud. If you do not want to pay with USDC on Base, or if your application requires a human-operated dashboard, this is the wrong tool. The README also reveals a specific failure mode: custom or arbitrary sellers remain ambiguous and require reconciliation. The SDK and MCP can re-present an ambiguous proof while their process remains alive, but custom sellers do not get the same treatment. Another limitation is that the full backend lives in a separate repository, run402-core, under Apache-2.0. This repo holds only the agent surfaces. If you need to inspect or modify the backend, you must look there. The README does not document the internals of run402-core, so operational details like scaling, replication, and failover are not covered in this material.

Alternatives and how they differ

The README explicitly compares run402 to Supabase, Firebase, and Vercel. The difference is not in the feature set; it is in the interface. Supabase and Firebase are designed for humans: you sign into a dashboard, create a project, and copy an API key. run402 removes that entire step. An agent can provision a Postgres database and deploy a static site without any human-issued credential. Vercel deploys sites, but its workflow assumes a human initiates the deploy. run402's atomic deploy and autonomous payment are the differentiators. If you need a backend that an agent can drive end to end, run402 is built for that. If you are a human developer who prefers a dashboard and manual control, the traditional platforms are still more familiar and better documented. The choice depends on whether your primary operator is a person or a machine.

Maintenance, licensing, and what to verify first

The repository is under the MIT license, which is permissive and suitable for commercial use. The full backend in run402-core is Apache-2.0, which is also permissive but has different attribution requirements. The project is actively maintained: the last push was 2026-08-29, and releases v4.48.0, v4.49.0, and v4.50.0 came out on consecutive days. That suggests a fast release cadence, but it also means you should pin versions and watch for breaking changes. The README does not document an upgrade path or migration steps. Before adopting, verify that the CLI and SDK versions you plan to use are compatible with the run402 cloud, and check the run402-core repository for any operational constraints. The prototype tier on testnet is a good place to start, but do not assume production behavior matches the testnet experience.

Editorial conclusion

Adopt run402 if you are building autonomous agents or coding agents that need to provision and pay for their own backend resources without a human in the loop. Do not adopt it if you require a traditional dashboard, human-issued API keys, or a backend that operates outside the x402 payment ecosystem. Before adopting, verify the current state of the agent surfaces in this repo, check the run402-core repository for the full backend implementation, and confirm that the prototype tier on testnet meets your needs for real workloads.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes