Linux or macOS, x86_64 or aarch64. The only runtime dependency is the language
you choose — Bun for TS, node,
python3, a compiled Rust binary, or nothing at all for WASM.
curl -fsSL https://riz.dev/install | sh riz new typescript-bun my-app && cd my-app riz run # headless; use `riz --dev` for the live TUI dashboard # second shell: curl localhost:3000/hello claude mcp add riz --transport http http://localhost:3000/_riz/mcp
# installer (release binaries) $ curl -fsSL https://riz.dev/install | sh # or from source (Rust toolchain) $ cargo install --git https://github.com/24X7/riz # or: github.com/24X7/riz/releases
$ riz new typescript-bun my-app
$ cd my-app
# see all templates:
$ riz new --list
$ riz run # headless (JSON logs). live TUI dashboard: riz --dev # http API + MCP server are both live: # http://localhost:3000/hello # http://localhost:3000/_riz/mcp
$ curl localhost:3000/hello
{"message":"hello, world", "functionName":"hello", …}
# health · metrics · function registry
$ curl localhost:3000/_riz/health
$ curl localhost:3000/_riz/metrics
$ claude mcp add riz --transport http \
http://localhost:3000/_riz/mcp
$ riz mcp inspect
✓ server riz 0.3 · protocol 2025-11-25
✓ 1 tool: hello (typed params, SSE open)
# in your agent: "call the hello tool"
One static binary, no Docker. The installer drops riz on your PATH;
or build from source with cargo; or grab a release artifact directly.
Official templates, one per runtime — typescript-bun, typescript-node, python,
rust, go, wasm-rust (a wasm32-wasip1 handler on the riz-wasm shim;
the WebSocket showcase lives in examples/lambdas/chat), plus a full-stack
typescript-todo (API + React/Vite client), and ai-chat
(React chat UI + a server-side agent loop through the LLM gateway — boots offline).
Each boots first try. Templates always load from a git location, never embedded — so
riz new owner/repo[/subdir] works for your own too.
riz run is headless (JSON logs, production-shaped).
riz --dev adds the live terminal dashboard — requests, logs, and
P50–P99 percentiles as you work. Edit the handler, save, the next request
hits the new code.
Same payloads AWS sends — path params, query strings, headers, cookies, binary bodies. If your handler ran on Lambda, it runs here; if it runs here, it'll run on Lambda.
This is the step other runtimes don't have. Your function is already a typed
MCP tool — wire up a client and ask it to call your API. Verify the whole
surface first with riz mcp inspect.
Go further: add an [agent] block and the binary itself becomes a
delegable A2A agent that reasons with your functions — test it with
riz a2a send, mesh it with other riz instances via
[agent.peers]. The agent layer →
riz doctor is the first command to run —
it validates your riz.toml, checks runtime binaries are on PATH,
confirms handler files exist, probes the port, and pings the MCP endpoint if riz is already up.
Typed schemas, streaming, progress frames, and the agent decision card.
The sandbox, the capability broker that reaches Postgres, DynamoDB, S3, and pinned HTTP origins, and fail-closed guards.
One base_url, provider routing, budget caps that fail closed, a cost ledger.