Your backend shipsas fast as your prompt.

Get a real backend online — APIs, database, auth — instantly wired into every other service on the mesh. Fast, scalable, and free to start.

claude code
> Build me a bookmarks API with CRUD endpoints
I'll create a bookmarks API with full CRUD. Let me scaffold the Rust project and write the handlers.
Created src/lib.rs + boogy.toml — Router, store + auth
Compiled wasm32-wasip2, deploying...
✓ Deployed. Live at /my-app/api/bookmarks
> Add a search method that filters by tag
I'll add a GET /bookmarks/search?tag= endpoint with a store filter query.
Updated src/lib.rs — search_by_tag, building...
✓ Redeployed. New endpoint live.
$ curl https://boogy.ai/my-app/api/bookmarks/search?tag=rust
[{"id":3,"url":"https://doc.rust-lang.org","tags":["rust"]}]
Two prompts. Two deploys. Zero infrastructure. 🤠

Vibe a node. Get a mesh.

Each API is a node in the mesh — call any other like a function in your own code: yours, a teammate's, or a built-in. No setup, no glue code. Snap things together and ship fast.

  • Dirt cheap, pay as you growPennies at scale — pay only for what you actually use, never for idle capacity.
  • One transaction, many servicesA write across services commits or rolls back as one.
  • Protocol-fluidMix and match REST, JSON-RPC, and MCP — one service, every protocol.
  • Compose at native speedCall any service in-process — no network hop, no rate limit.
01 / The Runtime

A planetary-scale runtime
for API’s, apps & agents.

Every API you deploy is a node anyone can call. Services call services, agents call APIs, apps stitch them together — and because calls dispatch in-process, not over the network, hops are microseconds, not milliseconds.

 Identity, permissions, and audit ride every message automatically, so the whole mesh composes safely. A runtime that gets more powerful with everything shipped on it.

  • Unified identity — humans, agents, and services share one token format
  • In-process composition — cross-service calls are function calls, not hops
  • Organic growth — deploy one API today, a mesh of fifty tomorrow
  • Federation — the runtime spans machines without configuration changes
02 / Developer Experience

From idea to API
in minutes.

1 — Vibe your API
// A JSON-RPC handler — every // call arrives authenticated, // no plumbing fn place_order( o: OrderReq, ) -> Result<Order> { let buyer = auth::current_principal()?; // One ACID transaction across // the mesh: your storage write // and a call into another // dev's service commit // together, or all roll back let order = tx(|| { let id = store::insert( "orders", &o, )?; let warehouse = "boogy://acme/services/warehouse"; peer::fetch( warehouse, Req::post("/reserve") .json(&o.lines), )?; Ok(Order::new(id, buyer, &o)) // ← all one commit })?; // After it commits, reach // off-mesh to any third-party // API over HTTP let labels = "https://api.parcelhub.io/v1/labels"; outbound::fetch( Req::post(labels) .json(&order), )?; Ok(order) }
2 — Declare your manifest
# boogy.toml [api] id = "orders" # grant exactly what the handler uses [capabilities] store = true auth = true peer = true outbound_http = true [ingress] mode = "authenticated" [outbound] allowed_hosts = ["api.parcelhub.io"]
3 — Build & deploy
# Build cargo build \ --target wasm32-wasip2 \ --release # Publish + provision live in one call curl -X POST \ https://boogy.ai/v1/modules \ -F manifest=@boogy.toml \ -F wasm=@orders.wasm \ -F provision=true # → versioned module, # provisioned live under your handle { "module": "boogy://my-app/modules/orders@1.0.0", "provisioned": true }

— That's a deployed backend with its own database, auth, ingress policy, and metrics.

05 / Data

Every service gets a database.
You run none of them.

Fast, strictly-consistent storage is built into every service you deploy — no server to run, no shards to manage, no schema ceiling. It scales as you grow, and you pay only for what you use.

Strictly serializable

The strongest consistency guarantee there is, on by default. Every read and write behaves as if it ran one at a time, in order — no anomalies.

Transactions across services

A write that spans multiple services commits or rolls back as a single unit — consistency that survives your entire call graph.

Scales as you grow

Capacity grows on its own. A trickle or a flood, you never provision, resize, or shard.

Atomic migrations

Schema changes run as a single transaction. A failed migration rolls back completely — it never leaves a half-migrated database.

No schema ceiling

Tables, columns, and indexes grow as freely as your app does. No table-count limits, no bigger box to add a feature.

Crash-safe & durable

Every committed write is durable. A crash or restart never loses acknowledged data — your service comes back exactly where it left off.

03 / Auth That Flows

Every call carries identity.
Every boundary checks it.

Log in once, and you're authenticated across every service and app in the mesh. One global identity — passkeys, keypairs, or service credentials — all produce the same cryptographically signed, tamper-proof token. At the same time, each API can issue its own scoped keys for fine-grained access control within its own boundaries.

Global Identity

One login, every service. Your identity follows you across the entire mesh — no per-service auth, no session juggling.

Principal vs. Actor

API-A calls API-B on behalf of Alice. B sees Alice as principal, A as actor. Authorization keys off who the request is for — not who's making it.

Scoped Delegation

Services delegate on your behalf with capped permissions. 'Acting for Alice, requesting notes:read.' Scopes can't escalate.

Per-API Keys

Each API issues its own sk_* keys — like Stripe tokens. Use them to guard specific resources, routes, or actions. Scoped to that API, revoke independently.

Five ingress modes

Every API declares how it wants to be reached. The runtime enforces auth before your code runs — no middleware, no guards, no boilerplate. Pick the mode that fits each API.

public
Anyone can call. No token required.
authenticated
Valid token required. Deny-by-default.
allowlist
Named agents only. Explicit trust.
internal
Service-to-service only. Allow the whole mesh with ["*"].
mixed
Different rules per route.

All enforced before Wasm instantiates. Denials never touch your code.

04 / Secrets Without Compromise

Your code requests a secret by name.
Wasm never sees the value.

The runtime injects secrets at the wire edge. They flow from your vault to the host to the outbound request — never entering Wasm linear memory. Even a fully compromised component can only reach manifest-allowlisted hosts.

07 / Background Jobs

Durable work,
beyond the request.

Kick off work from any handler — an HTTP request, a cron tick, or another job. Every job runs to completion: automatic retries with backoff, failed jobs set aside for inspection, and near-instant pickup. And it runs as you — same principal, same scopes, same auth model as your synchronous code.

Identity Replay

Handlers execute with the enqueuer's frozen principal and scopes. auth::current_principal() works identically to sync code.

Multi-Tenant Fairness

Per-tenant depth caps prevent queue flooding. Per-tenant in-flight caps prevent execution starvation. No noisy neighbors.

Cron Scheduling

6-field cron expressions in the manifest. Cluster-wide advisory lock election — exactly one tick per interval, self-healing.

Cancellation

Pending jobs cancel instantly. Running jobs cancel via heartbeat + epoch interruption — bounded latency, no collateral.

<1s
dispatch latency
3
trigger sources
∞
retry + backoff
0
single points of failure
08 / Zero Trust, Zero Boilerplate

15 lines of TOML.
No middleware. No gateway. No secrets manager.

Every API ships with a boogy.toml manifest that declares what it can do, who can call it, and how it behaves. Capabilities, ingress policy, rate limits, secrets, delegation rules, storage engine — all in one file. The runtime reads it and enforces everything before your code runs. No middleware to wire up. No gateway to configure.

[capabilities] store = true auth = true peer = true outbound_http = true [ingress] mode = "authenticated" rate_limit = { rpm = 600 } [ingress.delegation] allow_actor = ["boogy://my-app/services/gateway"] max_delegated_scopes = ["notes:read"] [outbound] allowed_hosts = ["api.stripe.com"] secret_headers = [["authorization", "stripe-key"]]
What this gives you
  • +Database with ACID transactions
  • +Caller identity on every request
  • +Cross-API calls with delegation
  • +Outbound HTTP to Stripe only (SSRF firewall blocks all else)
  • +API key injected at the wire edge — Wasm never sees it
  • +600 req/min per principal
  • +Only boogy://my-app/services/gateway can delegate
  • Denials enforced before code runs
  • Misconfigurations fail safe.

Declare it in the manifest. The runtime handles the rest.

Everything from background jobs to encryption to cross-API routing is configured in TOML — no code, no infrastructure.

Schedule background jobs
[background_jobs.handlers.cleanup] cron = "0 */6 * * *" max_attempts = 3
Encrypt tables at rest
[store.encryption] tables = ["users", "payments"] key_ref = "db-encryption-key"
Sandbox memory & CPU
[limits] memory_mb = 64 timeout_ms = 10000
Cross-API routing
[routing] path = "/api/orders" methods = ["GET", "POST", "DELETE"]
Enable vector search
[capabilities] vector = true store = true
Allow peer-to-peer calls
[capabilities] peer = true outbound_http = true
09 / Three Protocols, One Component

REST. JSON-RPC. MCP.
Same Wasm, same data, same auth.

Browsers hit REST. Internal services use JSON-RPC. LLMs use MCP. One handler, three surfaces. Your API is already a tool Claude can use.

Request
$ curl GET /my-app/api/notes
Response
[ { "id": 1, "title": "Deploy guide" }, { "id": 2, "title": "Auth patterns" } ]
11 / Pricing

Simple, transparent,
pay for what you use.

Pay only for what you use, metered on five transparent dimensions: compute, occupancy, storage, egress, and requests. Calls between your own services run in-process, so they cost compute but never egress. A real prototype runs free — you pay only on the dimension you outgrow.

Free
$0
Explore, prototype, learn.
  • +~50 compute-minutes / month
  • +~1,000 GB-seconds occupancy / month
  • +1 GB-month database storage
  • +5 GB egress / month
  • +1M requests / month
  • +Full API surface — same capabilities
Pro
Pay as you grow
Everything in Free, then pay past each line.
  • +Compute — per compute-second
  • +Occupancy — per GB-second
  • +Storage — per GB-month
  • +Egress — per GB out (internal calls free)
  • +Requests — per million
How metering works
Five dimensions, each a real measured signal — no hidden bundles.
Computecompute-seconds
OccupancyGB-seconds
StorageGB-month
EgressGB out
Requestsper million
Calls between your services run in-process — compute only, no egress. Heavy DB usage and transaction conflicts carry small guardrail surcharges.
Pay only on the dimension you outgrow.