use case · Teams shipping agent infrastructure to production

Run AI agents in production on Rust

openclaw-rs is a runtime, not a toolkit: an append-only event store, OS-level sandboxing, and an axum JSON-RPC gateway ship in one binary built for production.

  • Event sourcing (sled)
  • Platform sandboxing
  • axum JSON-RPC 2.0 gateway
The problem
  • Agent toolkits leave you to assemble the runtime, gateway, sandbox, and storage yourself.
  • Node-based runtimes bring GC pause tails and heavy deployments to production.
  • Auditing what an agent did is hard when state lives in ephemeral memory.
How openclaw-rs solves it
A runtime, not a toolkit
openclaw-rs ships the gateway, agent runtime, sandbox backends, event store, and CLI in one workspace — you deploy it, you don't assemble it.
Event-sourced by default
Sessions are append-only SessionEvent logs in sled, so every run is replayable and auditable — the rendered conversation is just a projection.
Sandboxed tools per OS
Tool execution runs under bubblewrap on Linux, sandbox-exec on macOS, and Job Objects on Windows, at None, Relaxed, or Strict levels.

Most agent frameworks are toolkits: they hand you SDK primitives and leave the runtime, gateway, sandbox, and storage as an exercise. openclaw-rs takes the opposite position — it is a production-focused runtime you deploy, built around an append-only sled event store, last-write-wins CRDT projections, and defence-in-depth security.

The JSON-RPC 2.0 gateway runs on axum as HTTP and WebSocket in a single binary, with per-client rate limiting, auth middleware, and CORS. It exposes session.create, session.message, session.history, session.end, agent.list, agent.status, tools.list, and tools.execute. Tool execution is sandboxed per operating system — bubblewrap on Linux, sandbox-exec on macOS, Job Objects on Windows — at your choice of None, Relaxed, or Strict.

Because sessions are event-sourced, production incidents are debuggable: replay the log, inspect every SessionEvent, and reconstruct exactly what the agent did. See the architecture page for the crate graph and message flow, and the security page for the full threat model.

How it works, step by step

  1. 1
    Install the runtime

    cargo install openclaw-cli gives you the gateway, runtime, sandbox, and CLI in one binary.

  2. 2
    Onboard

    Run openclaw onboard to configure providers and credentials interactively.

  3. 3
    Run the gateway

    openclaw gateway run starts the axum HTTP + WebSocket JSON-RPC 2.0 gateway with rate limiting and auth.

  4. 4
    Choose a sandbox level

    Set the SandboxConfig to None, Relaxed, or Strict; the runtime picks the right OS backend automatically.

FAQ

Is openclaw-rs a library or a runtime?
A runtime. It ships the gateway, agent runtime, sandbox backends, event store, providers, channels, plugins, CLI, and an embedded dashboard in one workspace — you deploy it rather than assemble it.
How do I audit what an agent did?
Every session is an append-only log of SessionEvent values in sled. It is replayable and auditable — the conversation you see is a projection over that log.
next

Ship it on one binary.

openclaw-rs is MIT-licensed and one cargo install away. Install it, or read the architecture first.