OpenClaw Ecosystem: Compare Five Self-Hosted Agent Frameworks

A September 3, 2026 snapshot of five self-hosted agent frameworks, comparing deployment, extensions, security boundaries, and operational cost.

These projects should not be ranked only by which one is lighter. A personal assistant on one laptop, an always-on gateway on constrained hardware, and a shared automation service solve different problems. The useful questions are: who can invoke tools, where those tools run, how credentials cross the boundary, and whether failures remain auditable.

Information snapshot: September 3, 2026. These projects change quickly. Recheck official documentation and the target release before deployment.

Short answer

OpenClaw fits users who need broad channels, Skills, Plugins, and device capabilities. Define the Gateway and host-tool boundary before exposing it.
ZeroClaw fits teams that want a Rust single binary, explicit risk policies, and OS-level sandbox choices. Rust alone is not a security policy.
PicoClaw targets constrained Linux, Android, and embedded devices. Its rapid development makes upgrade and permission regression tests mandatory.
Nanobot fits Python teams that want a readable base with MCP, memory, multi-agent work, and automations.
IronClaw fits environments where tool isolation, credential boundaries, and auditability justify WASM, container sandboxes, and PostgreSQL operations.

Compare the deployment boundaries

Project	Main runtime shape	Extension points	Security boundary to inspect	Better fit
OpenClaw	TypeScript/Node.js; one Gateway connects UIs, channels, and device nodes	Tools, Skills, Plugins, Channels	Main-session tools may run on the host unless sandboxing is configured; remote access needs pairing and authentication	Feature-rich personal assistants and mutually trusted teams
ZeroClaw	Rust single binary with Agent, Gateway, Dashboard, and SOP engine	Providers, Channels, Tools, MCP, hardware traits	`supervised` risk policy, workspace boundaries, command policy, Landlock/Bubblewrap/Seatbelt/Docker	Teams prioritizing policy control and portable deployment
PicoClaw	Go single binary with Gateway, WebUI, and channels	MCP, Hooks, Providers, Channels, model routing	The project warns that rapid development may leave unresolved security issues; remote listeners and tools need hardening	Constrained devices, edge gateways, personal labs
Nanobot	Python with WebUI, terminal, Gateway, and OpenAI-compatible API	Tools, MCP, Skills, Subagents, Automations	Workspaces, tools, and long-term memory must match data sensitivity	Python customization and internal automation prototypes
IronClaw	Rust with local workers, Docker Sandbox, WASM tools, and Web Gateway	Built-in, MCP, WASM tools and channels	Capability permissions, endpoint allowlists, credential injection, leak detection, audit logs	Sensitive data and controlled tool execution

The table intentionally omits RAM, boot time, and line counts. Those numbers move with releases, build flags, enabled channels, memory backends, and observability. A README benchmark does not predict your deployment.

OpenClaw: draw the Gateway trust boundary first

OpenClaw centers on a Gateway. Control UI, CLI, TUI, messaging channels, and device nodes connect around it; Tools, Skills, and Plugins extend the system. The current project is a TypeScript/Node.js workspace, not a Python application.

Review two boundaries:

Who can send requests to the Gateway? The project supports a single operator or a team whose members trust each other. That is not a default multi-tenant isolation model.
Where do tools execute? The security guide states that main-session tools may run on the host unless sandboxing is configured. Messages and fetched web content are therefore untrusted inputs, not merely text to display.

OpenClaw is a good fit when the team accepts the work of maintaining channel connections, plugin versions, device permissions, and a clear network identity boundary around the Gateway.

ZeroClaw: policy and replaceable components matter more than Rust

ZeroClaw packages the runtime as a Rust single binary while keeping clear extension points for providers, channels, tools, memory, the Gateway, and SOP workflows. It also supports MCP and hardware peripherals; it is not a CLI-only chat shell.

Its default risk model is the more useful comparison. In supervised mode, medium-risk operations require approval and high-risk operations are blocked. Workspace boundaries, command policies, and Landlock, Bubblewrap, Seatbelt, or Docker can add OS-level isolation.

Before deployment, verify which sandbox is active on the target OS, what shell and HTTP tools can reach, and whether any relaxed development mode is enabled.

PicoClaw: resource constraints do not remove security work

PicoClaw is written in Go and started from constrained hardware, but the current project includes a WebUI, Gateway, MCP, Hooks, model routing, vision input, and multiple channels. Describing it as only a forwarding hook is outdated.

It fits boards, old phones, and small Linux devices. The project also warns that it is evolving rapidly and may contain unresolved security issues. Before enabling a remote WebUI or Gateway, check bind addresses, authentication, configuration-file permissions, MCP server provenance, and tool-accessible paths.

If the device controls a door, camera, or operations workflow, the cost of a wrong tool call can exceed the resource savings.

Nanobot: a readable Python base with a wider current scope

Nanobot is no longer merely a small teaching core. It includes a WebUI, terminal client, long-term memory, MCP, model routing, multi-agent delegation, scheduled automation, chat channels, and an OpenAI-compatible API while keeping the main agent path readable.

It works well when a Python team needs to change the agent loop, tools, or memory behavior directly, or when an internal automation prototype should remain understandable before adopting a larger platform.

The tradeoff remains operational: Python dependencies, frontend assets, the Gateway, and memory data must be versioned and maintained together. Pin dependencies, isolate workspaces, and preserve tool-execution records.

IronClaw: treat tool execution as a security system

IronClaw uses Rust and supports built-in, MCP, and WASM tools. Its design includes capability permissions, HTTP endpoint allowlists, credential injection at the host boundary, request and response leak checks, and resource limits. Heavier work can run through a Docker Sandbox.

These controls reduce direct access to credentials and host resources, but they do not prove immunity to prompt injection. Broad allowlists, oversized credential scopes, and weak approval rules still create exposure.

The operational cost includes PostgreSQL, a WASM toolchain, and sandbox workers. That may be excessive for one user with a few read-only tools, but justified for a long-running service that needs isolation and evidence.

Run your own comparable test

Fix the following variables:

Same machine, OS, model provider, model, and network.
One message channel, one read-only tool, and equivalent memory behavior.
Clear process state before cold starts; reuse the same session for warm tests.
Record idle memory, peak request memory, first-response latency, tool completion time, and recovery time.
Measure package or image size separately from runtime memory.

Run four scenarios: plain chat, reading one allowed directory, calling one fixed-domain HTTP API, and restoring a session after restart. A framework that cannot explain permissions and failure logs should not win only because its memory number is lower.

Security acceptance checklist

Gateway binds to localhost or a controlled network by default; external access uses TLS, authentication, and rate limits.
Unknown senders cannot invoke tools directly; direct messages, groups, and webhooks use separate identity rules.
Shell, file, browser, MCP, and HTTP tools use least privilege and cannot read the entire home directory by default.
API keys never enter prompts, logs, workspace files, or plaintext tool arguments.
Outbound traffic uses domain or endpoint allowlists; sensitive operations require approval.
Tool records include actor, input, result, failure reason, and version.
Indirect prompt-injection tests cover malicious pages, email, and retrieved documents.
Upgrades start with configuration and data backups, followed by workflow replay in a test environment.

Selection rule

Start with the hardest constraint:

Need broad channels, device capabilities, and plugin combinations: evaluate OpenClaw.
Want a single binary with explicit risk policy and OS sandboxes: evaluate ZeroClaw.
Target constrained devices and can absorb rapid-release risk: evaluate PicoClaw.
Have a Python team that needs to modify agent, MCP, and automation behavior: evaluate Nanobot.
Handle sensitive data, complex tool permissions, and mandatory audit evidence: evaluate IronClaw.

Then rerun the same workload and security tests. Project names, implementation languages, and README metrics do not replace a deployment boundary.