The complete OpenClaw playbook
The full OpenClaw stack: architecture, VPS deployment, skills, channels, security, and every containment technique ranked by effort and protection.
26 · feb 09(20d earlier) spent three days trying every containment setup I could find for OpenClaw. this is what worked, what didn't, and what I actually ended up using. 26 · mar 11(10d later) expanded this into the full setup guide. architecture, deployment, skills, cost — not just containment anymore.
This is the companion piece to OpenClaw and the keys to your kingdom. That article covers the why — what "full system access" means and why a malicious skill proved the threat is real. This one covers the what and the how: what the stack looks like, how to deploy it, and how to lock it down.
If you haven't read the thread: OpenClaw is an open-source AI agent that runs on your hardware and acts autonomously — reading files, running commands, accessing your network, sending messages on your behalf through WhatsApp or Telegram. It works. It's also a process running as your user with access to everything you have access to. A community skill was already found containing malware. The question isn't whether to use it — it's how to understand it and contain it.
290,000+ GitHub stars. 443 contributors. 175,000+ lines of TypeScript. Mac Mini delivery times pushed out to six weeks because people are buying them specifically to run this. The project passed React's all-time star count in roughly 60 days. This isn't a side project — it's infrastructure people are building businesses on.
1. What OpenClaw actually is
Regular AI is a brain in a jar. You ask it a question, it answers, and then you go do the thing. OpenClaw inverts that. You tell it what you want, and it does it — opens your files, modifies them, saves them. Connects to your email, reads your inbox, drafts responses, sends them. Three words: Claude with hands.
ChatGPT / Claude.ai OpenClaw
Lives in a browser tab Runs on your hardware
Resets every conversation Persistent memory across sessions
You come to it It comes to you (iMessage, WhatsApp, Telegram)
Can only talk Can execute — files, APIs, browser, shell
Cloud-hosted Self-hosted — your data stays local
What it can actually do: execute shell commands and manage files. Control browsers — navigate sites, fill forms, extract data. Send messages through iMessage, WhatsApp, or Telegram on your behalf. Read and draft emails, manage your calendar. Run proactive tasks — morning briefings, monitoring alerts, scheduled reports — without you asking. And if a capability doesn't exist yet, it can build its own skills.
What people are building with this
Support triage. Shared inbox → classify urgency → draft responses → route complex issues with context. Community members report ~70% of tickets handled without a human.
Competitor intelligence. Weekly heartbeat scrapes competitor sites, tracks pricing changes, feature launches, job postings. Structured report to Slack every Monday.
Content pipeline. RSS feeds + topic lists → platform-specific drafts. X, LinkedIn, newsletter. Remembers previous output to avoid repetition. One user reported saving 10+ hours/week.
DevOps monitoring. Dependencies, vulnerabilities, disk space → prioritized Telegram alerts → SSH diagnostics when something fails.
2. Architecture
Four systems working together. This is what separates it from a chatbot or an automation tool.
Copy
┌─────────────────────────────────────────────────────────────┐ │ YOUR SERVER │ │ │ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │ │ Gateway │───▶│ Agent │───▶│ Skills │ │ │ │ (WebSocket)│ │ Runtime │ │ Platform │ │ │ │ :18789 │ │ │ │ │ │ │ └────────────┘ └────────────┘ └────────────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │ │ Channels │ │ Browser │ │ External │ │ │ │ (Inbox) │ │ Control │ │ APIs │ │ │ └────────────┘ └────────────┘ └────────────┘ │ │ │ └─────────────────────────────────────────────────────────────┘ │ ┌─────────────────────┼─────────────────────┐ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ │WhatsApp │ │Telegram │ │ Discord │ │ Signal │ │ Slack │ │ iMessage│ └─────────┘ └─────────┘ └─────────┘
Gateway — the control plane. A single long-running process that owns all channel connections, handles session management, tool execution, and health monitoring. Binds to ws://127.0.0.1:18789. Never expose this to the public internet.
Agent runtime — the brain. Processes messages through Claude, decides what actions to take, executes tool calls. Each incoming message flows through DM policy → session routing → context loading (skills + memory + system prompt) → model → tool execution → response.
Skills platform — plugin folders that teach the agent how to use specific tools. A skill is a markdown file with YAML frontmatter and instructions. Over 3,200 published on ClawHub, the "npm for AI agents."
Channels — messaging adapters. Same AI, same memory, different interface. You can talk to it from Slack at work and iMessage on your phone — same context carries across.
Multi-agent routing
You can run multiple agents with isolated workspaces:
JSON Copy
{ "agents": { "list": [ { "id": "personal", "workspace": "~/claw-personal", "sandbox": { "mode": "off" } }, { "id": "work", "workspace": "~/claw-work", "sandbox": { "mode": "all" } } ] } }
Route different channels to different agents. Complete isolation between personal and work contexts.
Memory system
The agent doesn't reset between conversations. It maintains persistent memory through files:
SOUL.md — the AI's identity and personality
USER.md — who you are, your preferences, your role
MEMORY.md — long-term knowledge: decisions, context, history
daily/ logs — session transcripts
The search layer uses hybrid retrieval: vector similarity (0.7 weight) plus keyword matching (0.3 weight, BM25). Runs on SQLite or PostgreSQL with FastEmbed. Fully local — zero API calls for retrieval. Every conversation builds on every previous one.
3. Deployment
Two paths: run it on hardware you own, or run it on a VPS in the cloud. Both work. The tradeoffs are real.
Hardware: what to actually buy
Option Price Usable RAM for AI What it runs Best for
Mac Mini M4 Pro 48GB $1,999 40–44 GB 30B–70B parameter models Business deployments
Mac Mini M4 Pro 24GB $1,399 16–18 GB 8B–22B parameter models Small teams
Mac Mini M4 16GB $499 10–12 GB 8B models Personal / testing
VPS (Hetzner / DigitalOcean) $5–40/mo Varies API models only No hardware preferred
Why Mac Mini specifically: unified memory architecture (GPU and CPU share RAM — every GB counts), 30W power draw ($6/month), silent, 5×5 inches. macOS handles sleep/wake natively and gives you iMessage integration that no other platform can match.
Real benchmarks on the 48GB tier: Qwen 3 32B at Q4 quantization runs 15–22 tokens/sec. DeepSeek R1 32B at Q4: 11–14 tokens/sec. Llama 3.1 8B at Q4_K_M: 28–32 tokens/sec.
VPS setup
If you don't want hardware in your closet, a $5–20/month VPS does the job. The agent calls Claude's API for inference, so the server just needs to run the gateway and manage connections.
Provider Starting price Notes
Hetzner €4.50/month Best value, EU data centers
DigitalOcean $6/month Clean interface, published OpenClaw deployment guide
Linode $5/month Consistent performance
Railway ~$5–20/month One-click deploy
Minimum: 2GB RAM, 1 vCPU, 20GB SSD, Ubuntu 22.04+, Node.js 22+.
BASH Copy
# 1. SSH in, create a non-root user ssh root@YOUR_VPS_IP adduser clawdbot && usermod -aG sudo clawdbot && su - clawdbot
# 2. Install essentials + Node.js 22 sudo apt update && sudo apt -y upgrade sudo apt -y install git curl build-essential jq ca-certificates ufw htop curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash - sudo apt install -y nodejs
# 3. Add swap (important for 1-2GB VPS) sudo fallocate -l 2G /swapfile sudo chmod 600 /swapfile && sudo mkswap /swapfile && sudo swapon /swapfile echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
# 4. Install OpenClaw and run the onboarding wizard npm install -g clawdbot@latest clawdbot onboard --install-daemon
# 5. Enable lingering — keeps service running after SSH disconnect sudo loginctl enable-linger "$USER" systemctl --user daemon-reload systemctl --user enable --now clawdbot-gateway.service
The wizard configures your AI model (use Claude Opus 4.5), sets up authentication, installs the systemd service, and creates the initial config. Verify with clawdbot doctor and clawdbot health.
The full software stack
If you're going beyond the basic gateway, here's what a production deployment looks like:
Service What it does
Ollama Local LLM inference. Runs models on-device. OpenAI-compatible API.
Open WebUI Chat interface. Brandable with your domain, logo, colors.
n8n Workflow automation. 400+ integrations for triggers and actions.
Supabase PostgreSQL + pgvector, auth, file storage. Self-hosted.
Qdrant Vector database for document search and RAG pipelines.
Caddy Reverse proxy with automatic TLS/SSL.
Tailscale Encrypted mesh networking. Zero public ports.
Langfuse LLM monitoring — token usage, latency, error tracking.
All containerized with Docker. One docker compose up starts everything.
4. Skills and channels
The skills system
Skills are plugin folders that teach the agent how to use specific tools. Each skill is a SKILL.md file with YAML frontmatter and instructions. Precedence: workspace skills (highest) → managed/local skills → bundled skills (lowest).
BASH Copy
# search, install, sync clawdhub search "google workspace" clawdhub install steipete/gog clawdhub sync --all
Skill What it does
gog Google Workspace — Gmail, Calendar, Drive with domain-wide delegation
github GitHub — repos, issues, pull requests
notion Notion workspace access
slack Slack workspace messaging
bluebubbles iMessage bridge via Mac
self-improvement Agent can modify its own prompts
skill-creator Agent can build new skills
ClawHub securityIn February 2026, researchers discovered 341 malicious skills on ClawHub. 13.4% of audited packages had critical vulnerabilities — credential theft, remote code execution. OpenClaw partnered with VirusTotal to scan published skills, but that catches known signatures, not novel techniques. Use local skills only for production. No public registry pulls without reading the source.
Creating a custom skill is a markdown file dropped into ~/.clawdbot/skills/my-skill/SKILL.md:
MARKDOWN Copy
--- name: my-custom-skill description: What this skill does metadata: clawdbot: requires: config: - key: MY_API_KEY description: API key for the service ---
# My Custom Skill
Instructions for the agent on how to use this skill...
Messaging channels
Platform Setup Notes
Telegram Easy Create bot via @BotFather, paste token
Discord Easy Bot account, enable MESSAGE CONTENT INTENT
WhatsApp Medium Bridges your personal account via Baileys. QR code pairing.
Slack Medium Workspace app via Bolt
iMessage Hard macOS only, or BlueBubbles bridge (Mac + VPS via Tailscale)
Signal Hard Requires linked device via signal-cli
All channels share the same agent, memory, and context. Configure each in clawdbot.json:
JSON Copy
{ "channels": { "telegram": { "enabled": true, "botToken": "123456:ABC-xxxxx", "dmPolicy": "pairing" }, "discord": { "enabled": true, "botToken": "xxxxx", "dmPolicy": "pairing" }, "whatsapp": { "enabled": true, "dmPolicy": "pairing" } } }
iMessage integration
iMessage doesn't have an API. Two options: run OpenClaw directly on a Mac, or bridge through BlueBubbles.
Copy
┌────────────┐ Tailscale ┌────────────┐ │ VPS │◄───────────────────►│ Mac │ │ Gateway │ │ BlueBubbles│ │ Skills │ │ Server │ └────────────┘ └────────────┘ │ ┌─────▼──────┐ │ iMessage │ └────────────┘
Install BlueBubbles on your Mac, sign into iMessage, enable the Private API. Install the skill (clawdhub install steipete/bluebubbles), connect the VPS to the Mac via Tailscale. Now your VPS-hosted agent sends iMessages through your Mac.
Proactive features
The agent can reach out without being asked:
JSON Copy
{ "cron": { "jobs": [ { "id": "morning-briefing", "schedule": "0 8 * * *", "action": "Summarize unread emails and today's calendar" }, { "id": "weekly-review", "schedule": "0 18 * * FRI", "action": "Create a weekly summary of completed tasks" } ] } }
Heartbeat checks (default: every 30 minutes) monitor connected services and alert you proactively. Gmail Pub/Sub can trigger real-time reactions to incoming emails. Webhooks let external events (GitHub PRs, monitoring alerts) trigger agent actions.
A solo founder in the community runs four agents — strategy, dev, marketing, business — on a single VPS controlled through Telegram, with shared memory and scheduled daily tasks. Morning briefings, competitor monitoring, content scheduling. Zero manual triggers.
5. What's exposed on your machine
Everything above is what OpenClaw can do for you. Everything below is what it can do to you — and how to prevent it.
Before picking a containment strategy, you need to know what you're containing. Here's what a user-level process on your machine can access silently, without any prompt or password:
What Where Why it matters
SSH private keys ~/.ssh/id_ed25519 Passwordless access to every server that key authenticates to. Unencrypted by default.
Cloud credentials ~/.aws/credentials, ~/.kube/config Full access to your AWS account, Kubernetes clusters, etc. Plaintext.
Environment secrets .env files in every project API keys, database passwords, third-party tokens.
Firefox cookies ~/.mozilla/firefox/*/cookies.sqlite Unencrypted session tokens. A cookie for your bank = logged in.
Signal/Telegram DBs ~/Library/Application Support/Signal/ Message history. Signal's encryption key was stored in plaintext until recently.
Git tokens ~/.git-credentials If credential helper is store, your GitHub token is plaintext.
Local network Every device on your LAN NAS, cameras, smart home, partner's laptop — all reachable.
And what the OS does protect, even from same-user processes:
What Why it's protected
macOS Keychain passwords Encrypted by Secure Enclave 1 hardware. 1a physically separate chip that holds encryption keys and never releases them to software. First-time access from a new app triggers a system prompt.
Chrome saved passwords (macOS/Windows) Encryption key lives in Keychain or DPAPI 1. 1Windows Data Protection API. Binds encryption to the user account. Chrome adds "App-Bound Encryption" on top since version 127.
Kernel operations Installing drivers or extensions requires admin password elevation.
Hardware-backed keys TPM / Secure Enclave — physically cannot be extracted by software.
The containment goal: keep the agent's access to the green table. Block its access to the red table. Every technique below does some version of this.
6. Option 1: Docker
Docker does most of the work
Running the agent in a Docker container 1 gives you filesystem isolation, network isolation, and capability restriction in a single command. For most threat models — a misbehaving agent, a malicious skill, accidental data exfiltration — it's enough.
1a tool that creates isolated environments called containers. The program inside gets its own filesystem, its own process list, and its own network. It cannot see the host's files or network unless you explicitly mount a path or expose a port.
The full command
BASH Copy
docker run --rm -it \ --network=none \ --read-only \ --tmpfs /tmp:rw,noexec,nosuid,size=512m \ --cap-drop=ALL \ --security-opt=no-new-privileges \ --memory=4g \ --cpus=2 \ -v /path/to/project:/workspace:ro \ -v /path/to/output:/output:rw \ your-agent-image
Flag-by-flag:
--network=none — zero network access. No DNS, no HTTP, no LAN scanning. The container only has a loopback interface. This single flag blocks all exfiltration vectors.
--read-only — container's root filesystem is read-only. The agent can't install packages, modify system files, or write outside the mounted output directory.
--tmpfs /tmp:rw,noexec,nosuid,size=512m — writable temp space in RAM only (512 MB max), no executable binaries allowed.
--cap-drop=ALL — drops all 14 default Linux capabilities 1.
1special privileges containers get by default: CHOWN (change file ownership), DAC_OVERRIDE (bypass file read/write checks), FOWNER, FSETID, KILL, SETGID, SETUID, SETPCAP, NET_BIND_SERVICE, NET_RAW, SYS_CHROOT, MKNOD, AUDIT_WRITE, SETFCAP. Dropping them all means the process has zero special permissions.
--security-opt=no-new-privileges — prevents privilege escalation via setuid/setgid binaries. Even if the agent finds a SUID binary, it can't use it.
--memory=4g --cpus=2 — resource limits so the agent can't OOM the host or fork-bomb.
-v /path/to/project:/workspace:ro — mount only the directory you want the agent to work on, read-only.
-v /path/to/output:/output:rw — separate writable mount for output. The agent writes here and nowhere else.
Setup time: 5 minutes. Copy the command, adjust the two volume paths, run it.
One thing I learned the hard way: --network=none means none. The first time I ran this, the agent died immediately trying to resolve DNS for the Anthropic API. Obvious in retrospect. If your agent needs to call an API — and most do — you need the next section.
When the agent needs internet
--network=none is the safest option, but many agent tasks require internet access (API calls, web browsing, fetching dependencies). The problem: Docker's default bridge network gives internet access and LAN access. The agent can reach the internet but also scan every device on your home network.
The fix: a custom network with iptables 1 rules that block LAN access:
1the Linux firewall. Rules that filter network traffic based on source, destination, port, and protocol. We use them to block traffic to private IP ranges while allowing everything else.
BASH Copy
# create a custom network docker network create --driver bridge agent-net
# block all private IP ranges (your LAN) from containers on that network iptables -I DOCKER-USER -s 172.18.0.0/16 -d 192.168.0.0/16 -j DROP iptables -I DOCKER-USER -s 172.18.0.0/16 -d 10.0.0.0/8 -j DROP iptables -I DOCKER-USER -s 172.18.0.0/16 -d 172.16.0.0/12 -j DROP
# run the agent on the custom network docker run --rm -it \ --network=agent-net \ --read-only \ --cap-drop=ALL \ --security-opt=no-new-privileges \ -v /path/to/project:/workspace:ro \ -v /path/to/output:/output:rw \ your-agent-image
The agent gets internet. It cannot see your NAS, your partner's laptop, or your smart home hub. The iptables rules need to survive reboots (use iptables-save or a systemd unit).
Setup time: 30 minutes to configure and test. A weekend if you want to be thorough about it.
Networking modes compared
Mode Isolation LAN access Use for an agent?
--network=none Total. Loopback only. None Best for offline tasks
--network=bridge (default) Container gets private IP, NAT to host Yes — can scan your LAN Dangerous without iptables
Custom bridge + iptables Internet yes, LAN blocked No Best for online tasks
--network=host None. Shares host's network stack. Full Never use for untrusted agents
gVisor: fewer syscalls, smaller surface
Docker containers share the host's kernel. All 300+ Linux syscalls go directly to the host. A kernel exploit inside the container = root on the host. This has happened (CVE-2019-5736, Dirty COW).
Google's gVisor 1 dramatically reduces this attack surface:
1an open-source container runtime that interposes a user-space kernel (called Sentry) between the container and the host. Instead of 300+ syscalls hitting the host kernel, gVisor intercepts them and re-implements ~200 of them in user space. Only ~60 vetted syscalls ever reach the real kernel.
BASH Copy
# install gVisor's runsc runtime, then: docker run --runtime=runsc --rm -it \ --network=none \ -v /path/to/project:/workspace:ro \ your-agent-image
There's a performance overhead (10-30% on I/O-heavy workloads) but the kernel attack surface drops from 300+ syscalls to ~60. Google uses it in production for GKE Sandbox.
Setup time: 30 minutes. Install runsc, configure Docker, add the flag.
7. Option 2: Virtual machines
When Docker isn't enough
Docker is a room inside your house — real walls, locked doors, but same foundation. A VM is a separate house on a different street. Separate kernel, separate memory, separate network. If an agent escapes a container, it owns your host. If it escapes a VM... it doesn't. VM escapes exist (Venom/CVE-2015-3456) but they're far rarer and far harder than kernel exploits.
Property Container VM
Kernel Shared with host Separate guest kernel
Attack surface ~300 syscalls exposed ~30 hypercalls to hypervisor
Escape difficulty Kernel exploit = game over Need hypervisor exploit (much rarer)
Startup time Milliseconds Seconds (Firecracker: ~125ms)
Memory overhead ~10 MB 5 MB (Firecracker) to 256 MB (full)
macOS: OrbStack (5 minutes)
If you're on Apple Silicon, OrbStack is the path of least resistance. It runs a single, heavily optimized Linux VM on macOS using Virtualization.framework.
BASH Copy
# install OrbStack, then: orb create ubuntu agent-sandbox orb shell agent-sandbox
# inside the VM — install what you need, run the agent # your macOS home directory, SSH keys, browser profiles = invisible
I ran OpenClaw's core loop in an OrbStack instance for three days. Forgot it was running twice — the overhead is that invisible. Less than 0.1% background CPU, under 10 MB disk. My host machine's credentials and files were completely invisible to it, which is the whole point. This is what I actually use day to day.
Docker containers inside OrbStack get an extra layer: a container escape compromises the OrbStack Linux VM, not your Mac. That's a fundamentally different threat level than Docker Desktop, where an escape lands you on macOS directly.
Setup time: 5 minutes. Install the app, create the VM, done.
macOS: UTM (15 minutes)
For maximum isolation: UTM wraps QEMU with a macOS-native GUI. Full VM — its own kernel, its own disk image, its own network stack. Zero shared state with the host.
Heavier than OrbStack (~256 MB+ per VM), slower to create (you're installing an OS from an ISO), but the isolation is as real as it gets without a separate physical machine.
Setup time: 15 minutes for basic setup. Longer if you want a customized OS install.
Linux: Firecracker (weekend project)
AWS's microVM runtime, built for Lambda and Fargate. Boots in ~125ms, <5 MiB memory overhead per VM. The companion "jailer" adds cgroups, seccomp, and chroot around the VMM itself — isolation around the isolation.
The tradeoff: no Docker-style UX. You write JSON configs and manage VM lifecycle via API. Linux-only, requires /dev/kvm.
Setup time: a weekend. Powerful, but not plug-and-play.
Coming soon: Apple Containers
Apple announced native containerization at WWDC 2025 for macOS Tahoe. Each container runs in its own lightweight VM (not a shared kernel like Docker). Sub-second start times, dedicated IP per container, built on Virtualization.framework. Still in developer preview, but if you're on macOS 26, this may become the default answer.
8. Option 3: Cloud deployment
Your files aren't there
Here's the thing about running OpenClaw on a cloud server: your files aren't there. Your SSH keys, your browser sessions, your .env files, your messaging databases, your local network — none of it exists on the server. The agent has "full access" to... a clean Ubuntu box in a datacenter. That's a fundamentally different risk profile than a Mac Mini in your closet that also has your tax returns on it.
DigitalOcean published a deployment guide (by Amit Jotwani) that walks through the setup. Here's the security-relevant summary:
DigitalOcean setup
BASH Copy
# 1. Create a $12/month Droplet: Ubuntu 24.04, 2GB RAM, region near you
# 2. SSH in and create a dedicated user (don't run as root) ssh root@YOUR_DROPLET_IP adduser clawd && usermod -aG sudo clawd && su - clawd
# 3. Install OpenClaw curl -fsSL https://clawd.bot/install.sh | bash exec bash
# 4. Run the onboarding wizard with daemon mode clawdbot onboard --install-daemon # → configures your LLM provider (Anthropic, OpenAI, etc.) # → links WhatsApp/Telegram/iMessage via QR code # → installs a systemd service that runs 24/7
That's it. The gateway runs as a systemd service — survives SSH disconnects, reboots, everything. You chat through WhatsApp, the TUI (clawdbot tui), or a web dashboard (via SSH tunnel to localhost:18789). The WhatsApp QR linking is slightly unnerving — you're pairing your personal WhatsApp to a machine in a datacenter — but it works.
What the cloud gives you for free No local files at risk — the droplet doesn't have your SSH keys, browser sessions, or personal documents
No LAN access — the server is in a datacenter, not on your home network. Your NAS, cameras, and smart home are unreachable.
Easy to destroy — if something goes wrong, delete the droplet. Your local machine is untouched.
Snapshots and backups — DigitalOcean Snapshots or scp the ~/clawd/ directory for state backup
Firewall at the VPC level — cloud firewalls are more capable than your home router
Data leaves your network
Cloud deployment has one meaningful downside: your data leaves your network. Every instruction you send passes through Anthropic's API (this is true for local deployments too, but the local machine can also process local files without sending them anywhere). If the agent needs to read a file, that file has to be on the server. You're trading local-file convenience for a dramatically better security boundary.
For most use cases — task management, email triage, web research, code generation, scheduling — the agent doesn't need your local files at all. For file-heavy workflows (organizing downloads, managing a photo library, processing local data), you'd need to sync specific directories to the server, which partially defeats the purpose.
NoteDigitalOcean's own documentation includes this line: "giving a third party agent framework access to your local machine introduces a lot of security risks, so use Moltbot at your own risk. It is highly recommended to deploy it on an isolated environment that does not contain sensitive or private data." They're telling you what the right answer is.
Hardening the droplet
The base deployment works, but a few additions tighten it significantly:
BASH Copy
# enable the firewall — allow only SSH sudo ufw allow OpenSSH sudo ufw enable
# restrict outbound too (optional, advanced) # only allow traffic to Anthropic API + your messaging provider sudo ufw default deny outgoing sudo ufw allow out to any port 443 # HTTPS sudo ufw allow out to any port 53 # DNS
# set up automatic security updates sudo apt install unattended-upgrades sudo dpkg-reconfigure -plow unattended-upgrades
# monitor what the agent is doing clawdbot logs --follow
And back up the agent's state (memory, identity, conversation history):
BASH Copy
# from your local machine — weekly backup scp -r clawd@YOUR_DROPLET_IP:~/clawd ~/clawdbot-backup-$(date +%Y%m%d)
9. Networking
Accessing your Gateway remotely
Three methods, ranked by security:
1. SSH tunnel (most secure)
BASH Copy
ssh -L 18789:127.0.0.1:18789 clawdbot@YOUR_VPS_IP
Connect to ws://127.0.0.1:18789 locally. No ports exposed. Nothing to misconfigure.
2. Tailscale (recommended for multi-device)
BASH Copy
curl -fsSL https://tailscale.com/install.sh | sh sudo tailscale up
Access via Tailscale IP (e.g., 100.x.y.z:18789). Encrypted mesh network, zero public exposure. This is also how you connect a VPS-hosted Gateway to a Mac running BlueBubbles for iMessage:
Copy
┌────────────┐ ┌────────────┐ ┌────────────┐ │ VPS │ │ Mac │ │ Mobile │ │ 100.x.y.1 │◄──►│ 100.x.y.2 │◄──►│ 100.x.y.3 │ │ Gateway │ │ iMessage │ │ App │ │ Skills │ │ Bridge │ │ │ └────────────┘ └────────────┘ └────────────┘
3. Nginx reverse proxy (if you absolutely need HTTPS)
Only if you need public access. Requires strong authentication. I'm not going to pretend this is a good idea for most people — if you need it, you already know how to configure it.
TipThe Gateway broadcasts via mDNS for local device discovery. This can leak your username (via cliPath) and SSH port. Disable it:
```json
{ "discovery": { "mdns": { "mode": "off" } } }
```
LAN segmentation
If you're running the agent on a physical machine at home (not in the cloud, not in a container), network segmentation is what protects everything else on your LAN.
Guest WiFi (5 minutes)
The simplest option. Almost every router has a guest network that isolates devices from the main LAN by default.
Open your router's admin panel (usually 192.168.1.1) Enable guest WiFi if it's not already on Connect the agent's machine to the guest network
The agent gets internet access. It cannot see or reach any device on your main network. Done.
This isn't as robust as VLANs (no per-port control, no granular firewall rules, sometimes limited throughput), but it's a real improvement over a flat network where everything can talk to everything.
VLANs (half a day to a weekend)
VLANs 1 give you real network segmentation with firewall rules between zones.
1802.1Q virtual LANs. They carve one physical network into multiple isolated virtual segments. Devices on VLAN 10 cannot talk to devices on VLAN 20 unless you create an explicit firewall rule allowing it.
A practical home layout:
VLAN 1 (default): trusted devices — your daily laptop, your phone
VLAN 10 (lab): the machine running the AI agent. Firewall: internet yes, LAN no.
VLAN 20 (IoT): smart home devices. Internet yes, LAN no.
VLAN 30 (guest): guest WiFi. Internet only.
Router hardware VLAN support Setup effort Price range
Ubiquiti UniFi Full GUI, per-SSID VLAN assignment Half a day $100–$400
pfSense / OPNsense Full support, inter-VLAN firewall Half a day Free software + $100–$200 mini PC
OpenWrt Full support (flash existing router) Weekend Free
Most ISP routers No. Maybe guest WiFi. N/A Use guest WiFi instead
10. OpenClaw's security layer
OpenClaw has built-in access controls. They protect against other people messaging your bot, not against the agent itself. Different threat vector, still worth configuring.
DM access policies
Policy Behavior Use case
pairing Unknown senders get a pairing code, must be approved Recommended default
allowlist Only pre-approved contacts Strict control
open Anyone can message Never use this
disabled Ignore inbound DMs entirely Channel-specific lockdown
In group chats, always require mentions:
JSON Copy
{ "channels": { "whatsapp": { "groups": { "*": { "requireMention": true } } } }, "agents": { "list": [{ "id": "main", "groupChat": { "mentionPatterns": ["@clawd", "@jarvis"] } }] } }
Sandboxing
Run tool execution in Docker isolation:
JSON Copy
{ "agents": { "defaults": { "sandbox": { "mode": "all", "scope": "agent", "workspaceAccess": "ro" } } } }
Mode Behavior
off Tools run on host — only for your personal agent
all All tool execution in Docker container
agent Per-agent isolation
session Per-session isolation (strictest)
Security audit
BASH Copy
clawdbot security audit # basic clawdbot security audit --deep # with live Gateway probe clawdbot security audit --fix # auto-fix common issues
The --fix flag tightens open group policies, resets logging redaction, and fixes file permissions (~/.clawdbot → 700, config → 600).
Model choice matters
Use Claude Opus 4.5 for any bot with tools enabled. Smaller models (Sonnet, Haiku) are more susceptible to prompt injection 1. Opus 4.5 has better instruction-hardening and injection resistance.
1crafted messages that manipulate the model into doing something the operator didn't intend. Doesn't require public DMs — any untrusted content the bot reads (web results, emails, documents, pasted code) can contain adversarial instructions.
Incident response
If you suspect compromise:
Contain — systemctl --user stop clawdbot-gateway.service Rotate — Gateway auth token, browser control token, API keys, OAuth tokens Audit — check logs (/tmp/clawdbot/clawdbot-*.log), review session transcripts (~/.clawdbot/agents/*/sessions/*.jsonl), grep for unusual tool calls Re-scan — clawdbot security audit --deep
11. The credential audit
Do this regardless of which containment strategy you pick. 15 minutes that tells you exactly what's at risk. I ran these on my own machine while writing the thread and found four unencrypted SSH keys and two forgotten .env files with production credentials. Years of this, and I'd never once checked.
BASH Copy
# 1. SSH keys — are they passphrase-protected? head -2 ~/.ssh/id_ed25519 # "ENCRYPTED" in the header = has passphrase # no "ENCRYPTED" = plaintext key. fix: ssh-keygen -p -f ~/.ssh/id_ed25519
# 2. Cloud credentials — do they exist? ls -la ~/.aws/credentials ~/.kube/config ~/.docker/config.json 2>/dev/null # if they exist, they're almost certainly plaintext
# 3. Git credential helper git config --global credential.helper # "store" = plaintext tokens in ~/.git-credentials # fix: switch to "osxkeychain" (macOS) or "libsecret" (Linux) git config --global credential.helper osxkeychain
# 4. .env files — how many are on this machine? find ~ -name ".env" -type f 2>/dev/null | head -20 # each one is a plaintext file with production secrets
# 5. Browser cookies (Firefox — unencrypted) find ~/Library -name "cookies.sqlite" 2>/dev/null # macOS find ~/.mozilla -name "cookies.sqlite" 2>/dev/null # Linux
# 6. SSH agent — is it forwarding keys? ssh-add -l # if keys are listed, they're loaded in memory and available # to any process running as your user
Quick fixes Unencrypted SSH keys: ssh-keygen -p -f ~/.ssh/id_ed25519 — adds a passphrase. 30 seconds per key.
Git credential store: git config --global credential.helper osxkeychain — switches from plaintext file to encrypted keychain.
Stale .env files: move production .env files off any machine that runs an AI agent. Use a secrets manager (1Password CLI, Doppler, Vault) instead.
Firefox cookies: consider using a separate browser profile for sensitive sessions (banking, email) and keeping the agent machine's browser clean.
12. Cost
Cloud AI (team of 5, monthly)
Service Cost
ChatGPT Team $150
Claude Pro $20
Zapier $20–70
Notion AI $50
API credits $50–250
Total $300–500/month → $3,600–6,000/year
OpenClaw infrastructure
Item Cost
Mac Mini M4 16GB $499 one-time
Mac Mini M4 Pro 48GB $1,999 one-time
Electricity ~$6/month
Claude API (optional) $20–100/month
Everything else $0/month
Break-even on the $499 model: 2–4 months. On the $1,999 model: 6–10 months.
What you keep: no per-seat licensing, no vendor lock-in, no usage throttling, no training data leakage.
Claude Pro/Max subscriptionUsing a Claude Pro or Max subscription instead of metered API billing is dramatically cheaper for heavy usage. Community members report burning $300+ in two days on metered API. Flat monthly fee vs. per-token billing — the math isn't close.
13. The effort-to-protection matrix
Every technique in this guide, ranked. Start at the top, work down until the tradeoffs stop making sense for your situation.
What you do Effort What it buys you
Guest WiFi for agent machine 5 min LAN isolation — agent can't reach your other devices
Docker --network=none --cap-drop=ALL 5–10 min Filesystem + network + capability isolation
OrbStack VM (macOS) 5 min Separate kernel — escapes stay inside the VM
Passphrase on SSH keys 5 min/key Blocks silent key theft
Cloud deployment (DigitalOcean) 20 min No local files, no LAN, easy to destroy
DM policy: pairing + mention required 10 min Controls who can instruct your agent
Credential audit (SSH, AWS, .env, git) 15 min Know exactly what's exposed
Sandboxing mode: all 10 min Tool execution in Docker, not on host
Tailscale mesh network 30 min Encrypted access, zero public ports
VLANs (UniFi / pfSense / OpenWrt) Half a day Firewall rules between network zones
Docker + iptables LAN blocking Weekend Internet for the agent, no LAN scanning
gVisor (--runtime=runsc) 30 min Kernel attack surface from 300+ to ~60 syscalls
Full VM (UTM / Firecracker) 15 min–weekend Maximum isolation, separate everything
The 90% ruleThe first seven rows take under an hour combined and cover ~90% of the attack surface. Everything below the line is real protection but diminishing returns. If you only do one thing, make it the first row: guest WiFi. If you do two things, add Docker. If you do three, add the credential audit.
The full thread — what "full access" means, why the supply chain matters, and what Moltbook tells us about where this is heading — is here: OpenClaw and the keys to your kingdom.