Rysh vs OpenClaw: one binary and a markdown file vs the gateway, the daemon, and the pairing codes
OpenClaw earned its 383k stars. This is about what a self-hosted assistant costs to operate — counted from the docs, not vibes.
Let's get one thing straight before the comparison: OpenClaw is one of the most impressive open-source projects of the last year. ~383k GitHub stars, ~80k forks, MIT-licensed, a huge plugin ecosystem, and a community that shipped a personal AI assistant you can genuinely run on your own devices, bridging Discord, iMessage, Signal, Slack, Telegram, WhatsApp and more to AI agents. Respect. Nothing below is a knock on the project or its people.
This post is about something narrower and, for teams, more decisive: what the architecture costs to operate. Every claim about OpenClaw here comes from its own docs.
The moving parts, counted from the docs
OpenClaw's own getting-started path, step by step:
- Node.js runtime (22.22.3+ / 24.15+ recommended)
curl … install.sh | bashornpm i -g openclaw- A provider API key
openclaw onboard --install-daemon— the onboarding wizard- A persistent gateway daemon — "one always-on process for routing, control plane, and channel connections" (macOS LaunchAgent with KeepAlive; Linux systemd user unit +
loginctl enable-linger; port 18789) - Real chat channels as plugins:
openclaw channels add+ gateway restart - QR login and pairing approval (
openclaw pairing approve … <CODE>— codes expire in an hour, max 3 pending) - Allowlist edits in
~/.openclaw/openclaw.json(JSON5)
That's roughly eight distinct moving parts before a real channel answers a real message. For remote management, the documented path is an SSH tunnel (ssh -N -L 18789:…) or Tailscale to reach the browser dashboard.
None of this is bad engineering — it's the honest price of a maximally flexible gateway. But it is a price, and their docs are upfront about who should pay it: OpenClaw positions itself for developers and power users, and the maintainer has said plainly that if the command line isn't your comfort zone, the project is too dangerous to run safely. The security docs say the same in architecture terms: the gateway is "not a hostile multi-tenant security boundary," and you should never expose it unauthenticated. Researchers, meanwhile, reported tens of thousands of exposed instances in a February scan — not because the project is careless, but because eight moving parts and a network daemon give operators a lot of rope.
The rysh answer: collapse the moving parts
Rysh starts from the opposite architectural bet: the assistant should be one self-contained binary — embedded NATS broker inside, no separate runtime, no standalone daemon to stand up (the session daemon is rysh) — and an agent should be one markdown file.
brew install rysh-ai/rysh/rysh
rysh work
##humanoid spawn ./support.md # contacts block wires Slack / email / website chat
The support.md skill file holds the system prompt and a contacts YAML with ${ENV_VAR} tokens for credentials. That file is the deployment. It lives in git.
And because the "assistant" is also a full terminal workspace, you get a surface a chat-bridge gateway doesn't have: live shared terminal panes.
##share pane view # a teammate watches your session from their terminal
##share pane control # or types into it
rysh send work "status of the deploy?" --mode prompt # headless, from any shell
OpenClaw's documented remote-admin story is tunnel-to-dashboard. Rysh's is: the session is shareable and addressable by design.
The honest table
| OpenClaw | rysh | |
|---|---|---|
| What it is | Self-hosted personal-assistant gateway | Agentic workspace + channel platform for teams |
| License / cost | MIT, free, huge community | Not open source. Self-hostable; private beta via design-partner program |
| Install | Node + installer + wizard + daemon + plugins + pairing | One brew binary |
| Channels | Discord, iMessage, Signal, Slack, Telegram, WhatsApp, more via plugins | Slack, email, website chat today; WhatsApp/phone on the roadmap, not live |
| Governance | Pairing + allowlists | Per-channel governance ai|human draft-and-confirm — live on email and website chat; Slack gate pending |
| Remote access | SSH tunnel / Tailscale to dashboard | rysh send / attach / detach, live pane sharing |
| Model | Bring your provider | Claude, your own key (provider layer pluggable) |
Read the channels row again — OpenClaw genuinely wins it today. If WhatsApp or Signal is your must-have channel right now, that's a real reason to choose it, and I won't pretend otherwise.
When to pick OpenClaw
- You want MIT-licensed, free, community-driven software — rysh is self-hostable but not open source, and that difference matters to a lot of people, legitimately.
- You need the long tail of channels (Signal, iMessage, Telegram, WhatsApp) today.
- You're a power user who enjoys owning the whole stack, plugins and pairing codes included. The project explicitly courts you.
When to pick rysh
- You're deploying for a team, and every moving part is something a colleague will page you about.
- You want draft-and-confirm governance in front of customers — a human approving each reply until the agent earns autonomy.
- You want the assistant and your terminal workspace to be the same governed thing: shared panes, approval gates, one audit surface, your infra, your keys.
The one-liner I keep coming back to: DIY assistant stacks are impressive — and a weekend of gateway configs, pairing codes, and channel plumbing. Rysh is one binary and a markdown file. Pick the price you'd rather pay.
Rysh is in private beta. Access is through the design-partner program — free access, direct founder line, roadmap influence → apply here.
More in this series: One binary, no daemon zoo · Humanoids: agents with a Slack handle and an email address