Postgres + Sites · x402 + MPP payments · Base, Tempo, Bitcoin Lightning

run402.com

Open-source backend infrastructure for AI agents. An agent provisions Postgres, auth, storage, serverless functions and hosting through an SDK, CLI or MCP server — no cloud console, no signup. Prototype tier is free. Production via x402 (USDC on Base) or MPP (pathUSD on Tempo, or sats over Bitcoin Lightning).

Humans — click here
See live examples →
↓ what this is, then the full docs (llms.txt)

What Run402 is

Run402 is open-source backend infrastructure for AI agents. It is a cloud backend — a backend-as-a-service — that an autonomous agent or a coding agent can provision, operate and pay for on its own, through a typed SDK, a CLI or an MCP server, without a human signing into a cloud console.

An agent calls Run402 and gets a full application backend: a PostgreSQL database with an auto-generated REST API and row-level security, user authentication (passwords and Google OAuth), content-addressed file storage on a CDN, serverless functions on Node 22, and static and server-rendered site hosting on a managed subdomain or a custom domain. Databases, auth rules, secrets, functions, assets and the site itself all ship in a single atomic deploy.

Capabilities

Get started

No account, no dashboard — the CLI does the whole thing. Humans start at Get started free; agents keep reading.

npm install -g run402
run402 init                   # wallet allowance + funding
run402 up --name my-app -y    # provision Postgres, deploy, go live

To drive Run402 from a coding agent over the Model Context Protocol:

claude mcp add run402 -- npx -y run402-mcp

Documentation for agents is at run402.com/llms.txt and docs.run402.com; the deep references are /llms-cli.txt, /llms-sdk.txt and /llms-mcp.txt. The machine-readable API contract is /openapi.json. Humans should start at /humans.

Runnable example applications, each one live on its own subdomain, are indexed at run402.com/examples; their source, with every file reproduced in each README, is at github.com/kychee-com/run402-examples.

Agent interfaces

Payment model

Agent-controlled prepaid infrastructure. The prototype tier is free. Paid usage settles machine-to-machine over x402 (USDC on Base) or MPP (pathUSD on Tempo, or sats over Bitcoin Lightning), against a wallet allowance the agent holds itself; Stripe credits are available for humans who prefer a card. There is no subscription to sign up for and no per-payment human click inside the agent's permitted budget. An agent can also hold its own budgeted Lightning wallet and pay for tiers and images in sats, and an organization's balance can be topped up in sats from any Lightning wallet.

Open source

Run402 is open source. The agent-facing surfaces — SDK, CLI, MCP server, functions runtime — are MIT-licensed at github.com/kychee-com/run402. The self-hostable server and runtime core are Apache-2.0-licensed at github.com/kychee-com/run402-core.

What makes it different

Every other backend assumes a person opened an account and clicked through a console. Run402 assumes the operator is software: the agent holds its own principal, its own credentials and its own budget, so it can create a project, migrate a schema, deploy code and pay the bill in one unattended session — and it ships database, auth, storage, functions and site as one atomic release rather than as five services you have to wire together and keep in sync.

Category

Infrastructure and backend platform for AI agents and coding agents. Comparable in surface to Supabase, Firebase, Vercel or Render, but addressed to a machine rather than to a person: no dashboard, no signup form, no human-issued API key. It is the backend an agent reaches for when it has been asked to build and ship a working application end to end.

Reference — the full agent cheatsheet (/llms.txt)

Run402 — your first deploy

Run402 is a full-stack platform a coding agent provisions, deploys, and pays for on its own: Postgres, REST, auth, storage, functions, and static hosting behind one CLI. A first deploy is one file and one command. Everything else — the project, the allowance, the free prototype tier, your name, the rehearsal of database changes — is derived or automatic.

1. Install

npm install -g run402@latest

2. Write run402.json

The manifest is the whole app: a migration, which tables the browser may reach, and the site. Wire fields are snake_case.

{
        "$schema": "https://run402.com/schemas/release-spec.v1.json",
        "database": {
          "migrations": [
            { "id": "001_init", "sql": "CREATE TABLE IF NOT EXISTS items (id serial PRIMARY KEY, title text NOT NULL);" }
          ],
          "expose": {
            "version": "1",
            "tables": [{ "name": "items", "expose": true, "policy": "public_read_write_UNRESTRICTED", "i_understand_this_is_unrestricted": true }]
          }
        },
        "site": {
          "replace": {
            "index.html": { "path": "index.html", "content_type": "text/html" }
          }
        }
      }

index.html reads its own keys from the host it is served on — never paste a key into HTML:

<!doctype html>
      <script src="/_run402/config.js"></script>
      <ul id="items"></ul>
      <script type="module">
        const { api_base, anon_key } = window.RUN402;
        const headers = { apikey: anon_key, "Content-Type": "application/json" };
        await fetch(`${api_base}/rest/v1/items`, { method: "POST", headers, body: JSON.stringify({ title: "hello" }) });
        const rows = await fetch(`${api_base}/rest/v1/items`, { headers }).then((r) => r.json());
        document.querySelector("#items").innerHTML = rows.map((r) => `<li>${r.title}</li>`).join("");
      </script>

window.RUN402 is { project_id, api_base, anon_key } for whatever project the page was loaded from — a branch copy or a transferred project stays correct without touching the HTML. The anon key is public by design; the service key is never served there.

3. Deploy

run402 up --name my-app -y

up creates a local allowance and funds it from the testnet faucet (the prototype tier is free), creates the project, names an unnamed agent principal from the detected client when available; human and unknown principals keep their names even with RUN402_AGENT_NAME set. The result separates authenticated identity.principal from identity.client. Promotion credit comes from the principal, and an intentional rename uses run402 org whoami --set-name <name>. It applies the manifest as one atomic release. Later deploys that change the database against a live project are rehearsed on a throwaway branch first and ship only if they pass; a first deploy has nothing to protect and just ships.

The result is JSON. Hand your human the two links it carries:

{
        "result": {
          "project_id": "prj_…",
          "identity": { "display_name": "claude-code", "source": "detected" },
          "deploy": {
            "status": "ready",
            "urls": { "site": "https://my-app.run402.app", "console": "https://console.run402.com/orgs/…/projects/prj_…" },
            "rehearsal": { "status": "skipped", "reason": "no_live_release" },
            "next_actions": [{ "type": "hand_to_operator", "credited_as": "claude-code", "why": "Show your human the site and the console link…" }]
          }
        }
      }

That is the whole first run. Run run402 up -y again after every change.

If you were given a promo code

run402 redeem <code>

Where to go next

By Kychee
Site links