A Node OpenClaw deployment is a Docker image, a node_modules directory, a process manager, and a TLS layer.

A openclaw-rs deployment is a binary.

That’s the whole pitch. The consequences are bigger than they look.

What “one binary” actually contains

cargo install openclaw-cli produces a single executable that bundles:

  • The gateway (axum + WebSocket).
  • The JSON-RPC dispatcher.
  • The event store driver (sled).
  • The credential store (AES-256-GCM).
  • The provider clients (Anthropic, OpenAI).
  • The sandbox shims (bwrap on Linux, sandbox-exec on macOS, Job Objects on Windows).
  • The Telegram channel adapter.
  • The Vue 3 dashboard (embedded via rust-embed).
  • The CLI itself.

That’s the entire surface of openclaw-rs. There is no second process to start, no second deployment to coordinate.

Container builds

Alpine + glibc

FROM rust:1.85-alpine AS build
RUN apk add --no-cache musl-dev
WORKDIR /src
COPY . .
RUN cargo build --release --target x86_64-unknown-linux-musl

FROM alpine:3.20
RUN apk add --no-cache ca-certificates bubblewrap
COPY --from=build /src/target/x86_64-unknown-linux-musl/release/openclaw /usr/local/bin/
EXPOSE 18789
ENTRYPOINT ["openclaw", "gateway", "run"]

Result: a final image around 20 MB including bubblewrap.

Distroless

FROM rust:1.85 AS build
WORKDIR /src
COPY . .
RUN cargo build --release

FROM gcr.io/distroless/cc-debian12
COPY --from=build /src/target/release/openclaw /
ENTRYPOINT ["/openclaw", "gateway", "run"]

Distroless plus a single binary plus CA certs = a few MB on top of base. No shell, no package manager, no surface for an attacker.

Scratch (if you don’t need bubblewrap)

If you can disable the sandbox (you’ve reviewed every tool, you trust your plugins), a fully static musl build can run in a scratch image.

Cold start

openclaw gateway run starts and is serving requests in well under a second on modern hardware. Node OpenClaw’s equivalent path involves node, the V8 startup, and module resolution — typically a few seconds to first 200.

This matters most for:

  • Serverless deployments (Lambda, Cloud Run) where cold start is billable.
  • Auto-scaling fleets where new instances need to take traffic now.
  • Local development where you restart the gateway many times a day.

Memory baseline

A fresh openclaw-rs gateway with no sessions sits at < 20 MB resident. Adds a few MB per active session (the event store + projection state). Compares favourably to a Node OpenClaw baseline that starts higher and grows less predictably under GC pressure.

We aren’t going to publish a chart with specific numbers in this post — the project is young, the numbers will shift, and we’d rather you measure your own workload. The shape of the curve is what matters: predictable, flat, GC-free.

Cross-compilation

Building for a different target is cargo build --release --target <triple>:

  • Linux x64: x86_64-unknown-linux-gnu
  • Linux arm64: aarch64-unknown-linux-gnu
  • macOS x64: x86_64-apple-darwin
  • macOS arm64: aarch64-apple-darwin
  • Windows x64: x86_64-pc-windows-msvc

cross makes the Linux targets even easier — no toolchain dance, no Docker-in-Docker.

The Node bindings (openclaw-node) use the same napi-rs cross-build pipeline, so npm install picks the right pre-built binary on every platform.

Ops surface

What you stop worrying about:

  • node_modules/ size and audit warnings.
  • pnpm vs npm vs yarn lockfile drift.
  • Native module rebuilds when you bump Node.
  • Process-supervisor configs that need to know the Node version.
  • TLS termination running in a separate process because you didn’t want Node holding certs.

What you still own:

  • The bind address and port.
  • The systemd / launchd / NSSM unit (openclaw daemon install writes a sane default).
  • The reverse proxy if you don’t want axum to be your edge.
  • The TLS certs (axum-server can do TLS directly, or you proxy).

When this matters less

If you already have a polished Node deployment pipeline, the “single binary” pitch is a marginal benefit. The deeper wins come from:

  • Memory safety guarantees.
  • The event-sourced runtime.
  • The sandbox model.

But for teams setting up a new agent deployment, “deploy a binary, point a port at it” is hard to beat.