run402

Run402 — Postgres, storage & deploys for AI agents

Run402 gives an agent a real Postgres database with REST API and user auth, content-addressed CDN storage, static site hosting, Node 22 serverless functions, email, image generation, and KMS-backed on-chain signing. One command provisions; payment happens automatically with x402 USDC on Base. Prototype tier is free on testnet — no real money or human signup for the routine cold-start path.

Run402 is agent-first because agents are first-class participants, not because people disappear. Act through your own Run402 principal and authenticator; do not borrow a human login, shared cloud account, or another agent's credential. Identity records who acted. Memberships, roles, grants, delegates, freshness, and spend policy determine what you may do. A founder agent may legitimately own its org-of-one; an agent entering somebody else's organization uses bounded authority.

Every example below is a CLI command. The CLI prints JSON to stdout, JSON errors to stderr, and exits 0 on success / 1 on failure — designed for shells, scripts, and agent loops.

30-second start

run402 up --name my-app -y                 # bootstrap/link/deploy run402.json, run402.deploy.json, or app.json
run402 up verify                           # rerun app HTTP verification without deploying
run402 up --verify                         # deploy, then wait for gateway/edge release coherence
run402 subdomains claim my-app             # → https://my-app.run402.com

That's a real Postgres database + a deployed static site, paid for autonomously with testnet USDC.

run402 up is the CLI path for local repos with a deploy manifest. It classifies app-shaped run402.json through the app-install graph and release-shaped run402.json through the same ReleaseSpec normalizer as deploy apply; malformed app manifests return APP_SPEC_INVALID instead of an internal JavaScript exception. It validates the manifest first, then recursively performs only missing prerequisites through the SDK action runner. Project resolution is --project, .run402/project.json, manifest project_id, approved creation from --name, then approved active-project fallback. --dry-run prints planned steps[] without mutating. If an app manifest defines verify.http[], up reports fresh edge sentinel misses as propagation_pending while the host binding converges; tune with --propagation-budget-s, use --no-propagation-wait to return immediately, and run run402 up verify to rerun checks without upload, deploy, project creation, or resource mutation. Add --verify to a real deploy when you need edge_coherence evidence in the final JSON; a valid non-coherent report exits 2.