The matrix below consolidates the most decision-relevant dimensions for secure self-hosting: licensing, GitHub health signals, release cadence, isolation model, access control, secret handling, container/deployment posture, observability, and supply-chain assurances. All values are derived from each project's repository pages, security docs, and release information collected on February 23, 2026.
| Dimension | PicoClaw | ZeroClaw | NanoClaw | nanobot | nullclaw | Moltis |
|---|---|---|---|---|---|---|
| License | MIT | MIT OR Apache-2.0 | MIT | MIT | MIT | MIT |
| Stars / Forks | ~18.3k / ~2.2k | ~17.3k / ~2k | ~12.8k / ~1.9k | ~23.6k / ~3.7k | ~1.8k / ~200 | ~1.4k / ~137 |
| Contributors | 75 | 98 | 23 | 73 | 10 | 6 |
| Recent commit activity (last 12 months) | ~447 commits (all history) | ~1,268 commits (all history) | ~181 commits (all history) | ~652 commits (all history) | ~176 commits (all history) | ~1,293 commits (all history) |
| Releases / cadence signal | 3 releases; latest Feb 17, 2026 | 4 releases; latest Feb 22, 2026 | No releases published | 6 releases; latest Feb 21, 2026 | 3 releases; CalVer; latest Feb 21, 2026 | 55 releases; latest Feb 21, 2026 |
| Primary isolation strategy | Allowlists + lightweight runtime; orchestration probes | Defense-in-depth: workspace isolation, command allowlist, container-hardening guidance | Containers are the primary boundary (mount allowlist; per-group trust) | Operator controls: restrictToWorkspace, blocked patterns, allowlists; can run in containers |
Sandbox configuration + runtime abstraction incl. docker/WASM | Sandboxed execution (Docker/Apple Container) + web-facing controls |
| Authn/Authz | Per-channel allowlist + mention-only option | Autonomy levels; encrypted auth profiles for subscription auth | Group-based privilege model; “built for one user” | Allowlist guidance; open-by-default warning | Not emphasized as RBAC; config-driven sandboxing | Password + passkey (WebAuthn), rate-limited |
| Encryption at rest | Not clearly documented in sampled docs | Secrets encryption + encrypted auth profile store | Not a core claim; focuses on isolation; credentials may be visible to agent | Notes keys may be plaintext; recommends OS keyring for production | Mentions “encrypted secrets” as a goal/claim in README excerpt; details not expanded in sampled sources | Secret-handling patterns + supply-chain signing; encryption specifics depend on deployment/TLS setup |
| Encryption in transit | Not highlighted; likely depends on channel/provider defaults | Not highlighted in sampled docs; focuses on sandboxing and container security | Not emphasized; container boundary is primary | Explicitly states external API calls use HTTPS by default | Not highlighted in sampled docs | Uses local TLS in docs and notes cloud TLS termination patterns |
| Observability & monitoring | Health endpoints for orchestration; broader integrations unclear | Prometheus + OpenTelemetry options | “Ask Claude” operational model; explicit integrations not emphasized | Logs and operational guidance in SECURITY.md; Docker logs workflow | Audit retention option in config | Web UI + events/hooks; signed artifacts and SBOM for ops governance |
| Kubernetes/Helm/operator | Not found in primary docs reviewed | Not found in primary docs reviewed | Not found in primary docs reviewed | Not found in primary docs reviewed | Not found in primary docs reviewed | Not found in primary docs reviewed; cloud deploy scripts exist |
| Performance claims/benchmarks | <10MB RAM, fast startup (table in README) | <5MB RAM, <10ms startup (benchmark snapshot) | No formal benchmark in sampled sources; emphasizes “small enough to understand” + isolation | Emphasizes ~4,000-line core + rapid iteration; security guidance includes dependency scanning | 678KB binary, ~1MB RAM, <2ms startup; extensive test count | Not benchmark-centric; emphasizes sandbox + auth + secure design patterns |
| Compliance posture (SOC2/GDPR relevance) | No certification claims; self-hosting can help GDPR data locality but depends on operations | No certification claims; stronger controls (encryption-at-rest, sandboxing, observability) can support compliance engineering | No certification claims; container isolation supports least-privilege narratives but single-user design limits enterprise alignment | No certification claims; provides practical operator security checklist and dependency auditing guidance | No certification claims; strong minimal-footprint story; compliance depends on surrounding controls | Strongest supply-chain story (signing, SBOM/provenance); still no certification claims |
The star and release counts below reflect GitHub “k-format” display values observed on February 23, 2026 (rounded).
xychart-beta
title "GitHub Stars (approx.) — Feb 23, 2026"
x-axis ["nanobot","PicoClaw","ZeroClaw","NanoClaw","nullclaw","Moltis"]
y-axis "Stars" 0 --> 25000
bar [23600,18300,17300,12800,1800,1400]
xychart-beta
title "Release Count — Feb 23, 2026"
x-axis ["nanobot","PicoClaw","ZeroClaw","NanoClaw","nullclaw","Moltis"]
y-axis "Releases" 0 --> 60
bar [6,3,4,0,3,55]
The following diagram abstracts the dominant security boundary each project emphasizes: in-process allowlists/workspace scoping vs container isolation vs supply-chain and interactive auth controls.
flowchart TB
subgraph A["In-process runtime + allowlists/workspace scoping"]
A1["PicoClaw: channel allow_from + mention_only"] --> A2["Agent loop"]
A2 --> A3["Workspace/files/tools"]
A4["nanobot: allowFrom + restrictToWorkspace"] --> A2
end
subgraph B["Defense-in-depth runtime policy"]
B1["ZeroClaw: autonomy levels (ReadOnly/Supervised/Full)"] --> B2["Workspace isolation + path traversal blocks"]
B2 --> B3["Command allowlisting + forbidden paths"]
B2 --> B4["Secrets encryption + encrypted auth profiles"]
B2 --> B5["Observers: Prometheus / OTel"]
end
subgraph C["OS/container isolation as primary boundary"]
C1["NanoClaw: host orchestrator"] --> C2["Per-invocation container"]
C2 --> C3["Mounted dirs only (mount allowlist)"]
C4["Moltis: web + runtime"] --> C5["Sandbox (Docker/Apple Container)"]
C5 --> C6["Auth: password + passkey + rate limits"]
C5 --> C7["Supply chain: signed artifacts + SBOM/provenance"]
end
If your main concern is that an agent could read or modify unintended files on the host or exfiltrate secrets, container-first designs provide the clearest boundary. NanoClaw documents container isolation plus an external mount allowlist and per-group trust boundaries, explicitly shifting risk control to “only what is mounted exists.” Moltis similarly emphasizes sandboxing via Docker/Apple Container but combines it with stronger interactive authentication (password + passkey) and rate limiting, which is materially closer to the access-control surface many businesses expect when multiple humans may interact with the system.
ZeroClaw is the most directly “security-engineered” runtime in the set: it publishes a vulnerability response timeline, enumerates concrete sandbox layers, documents container hardening via distroless nonroot images, and provides encrypted-at-rest storage for secrets/auth profiles plus observability hooks. For businesses aiming at internal productivity automation (ticket triage, lightweight on-call assistant in chat, internal devops helper) with tight operational constraints, this design is often easier to govern than ad-hoc scripts while still being smaller than a sprawling multi-service deployment.
PicoClaw, ZeroClaw, and nullclaw all pursue extreme efficiency. PicoClaw explicitly targets $10 hardware with <10MB RAM and supplies comparative benchmark tables; ZeroClaw targets <5MB RAM and <10ms startup; nullclaw claims a 678KB static binary and ~1MB RAM. For edge deployments, the decision is less about raw performance and more about which security boundary you trust: PicoClaw's and nanobot's in-process restrictions vs ZeroClaw's layered controls vs container-first boundaries.
None of the evaluated repositories claim SOC 2 certification, and open-source availability does not substitute for compliance controls. However, several features can materially reduce compliance engineering effort:
- Encrypted secret handling (ZeroClaw).
- Explicit vulnerability reporting timelines and supported-version policies (ZeroClaw, nanobot, nullclaw, Moltis).
- Supply-chain verifiability (Moltis: Sigstore signing + SBOM/provenance guidance).
- Operator-facing “secure defaults” documentation (nanobot: allowlists, permissions, non-root, dependency audit workflow).
For most businesses evaluating an OpenCLaw alternative in early 2026, a defensible approach is:
- Default pick (balanced security + extensibility): ZeroClaw, if its trait-based/runtime model matches your integration needs and you value defense-in-depth plus encrypted local secret storage.
- Strongest user-facing auth/supply-chain posture (but smaller community): Moltis, if a web UI with password/passkey and verified artifacts aligns with your operating model.
- Strongest “auditable single-user container assistant”: NanoClaw, when you explicitly want container isolation with minimal abstraction and accept WhatsApp-first and single-user constraints.
- Best “big ecosystem / fast iteration” competitor: nanobot, when rapid community-driven feature addition and breadth of channels/tools matter more than minimizing dependencies.
- Edge-focused experimentation with Go: PicoClaw, when you accept pre-1.0 stability limits and can invest in hardening and operational governance yourself.