The complete OpenClaw playbook
A setup guide for OpenClaw, the open-source agent that acts on your machine with your user's permissions. It covers how the system is put together and how to deploy it on your own hardware or on a VPS. The second half ranks every containment technique by the effort it takes and the protection it buys.
Revisions26 · feb 09Read noteRevisions26 · feb 09Three days trying every containment setup I could find for OpenClaw. This began as the record of what worked and what I kept.
A personal note26 · mar 11Grown into the full setup guide, with containment now one chapter among several.
A personal note26 · oct 05Checked against the current docs, with sources beside each claim. The commands now use openclaw, the name the project took on 30 January (the clawdbot ones were already stale in March). Two corrections change the advice: an OrbStack machine sees your Mac's files and SSH agent unless you create it isolated, and Docker Desktop also keeps containers inside a Linux VM.
This is the companion piece to OpenClaw and the keys to your kingdom. That article covers why it matters: what full system access means and why a malicious skill proved the threat is real. This one covers how to deploy the stack 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, from running commands to 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, so the useful question is how to understand it and contain it.
Around 250,000 GitHub stars at the start of March 2026, when it passed React's all-time count a little over three months after its first commit1. High-memory Mac Mini configurations slipped to about six weeks' delivery in some markets because people were buying them to run this2. People are building businesses on it.
1Star History, OpenClaw surpasses React to become the most-starred software project on GitHub, 1 March 2026; it had passed 390,000 by October. 2unwire.hk, Mac mini shortage in Hong Kong, 9 February 2026.
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: it edits the file and saves it, or reads your inbox and sends the replies. It is 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.
Drive a browser, filling forms and extracting data from the sites it visits.
Send messages through iMessage, WhatsApp or Telegram on your behalf.
Read and draft emails, and manage your calendar.
Run scheduled tasks, a morning briefing for instance, without you asking.
If a capability doesn't exist yet, it can build its own skill for it.
What people are building with this
Support triageThe agent reads a shared inbox and drafts responses by urgency, routing complex issues to a person with the context attached.
Competitor intelligenceA weekly heartbeat scrapes competitor sites and tracks pricing changes, feature launches and job postings, with a structured report to Slack every Monday.
Content pipelineRSS feeds and topic lists become platform-specific drafts for X, LinkedIn and a newsletter, and the agent remembers previous output to avoid repetition.
DevOps monitoringDependencies, vulnerabilities and disk space become prioritized Telegram alerts, followed by SSH diagnostics when something fails.
Architecture
Four systems working together. This is what separates it from a chatbot or an automation tool.
GatewayWebSocket on port 18789Agent runtimeSkills platformChannelsthe inboxBrowser controlExternal APIsMessaging appsWhatsApp, Telegram, Discord, Signal, Slack, iMessage
GatewayThe control plane. A single long-running process that owns all channel connections and every session. Binds to ws://127.0.0.1:18789 by default^[OpenClaw, Gateway, OpenClaw docs, 2026.]. Never expose this to the public internet.
Agent runtimeThe brain. Sends each message through Claude and executes the tool calls it decides on. An incoming message is checked against the DM policy and routed to a session, whose context (its skills and memory) goes to the model with it.
Skills platformPlugin folders that teach the agent how to use specific tools. A skill is a markdown file with YAML frontmatter and instructions. Thousands are published on ClawHub, the npm for AI agents (Koi Security counted 2,857 at the start of February 2026^[The Hacker News, Researchers find 341 malicious ClawHub skills, February 2026.]).
ChannelsMessaging adapters. You can talk to it from Slack at work and iMessage on your phone, and the same memory 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. Newer releases spell the list as agents.entries.<id>, and openclaw doctor --fix migrates the old form.
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)
memory/YYYY-MM-DD.md: daily logs
The search layer mixes keyword matching (BM25, through SQLite's full-text index) with optional vector similarity through sqlite-vec, all in a local SQLite file1. Every conversation builds on every previous one.
1OpenClaw, Memory, OpenClaw docs, 2026.
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 (14-core CPU) 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 $599 ($499 education) 10–12 GB 8B models Personal / testing
VPS (Hetzner / DigitalOcean) $5–40/mo Varies API models only No hardware preferred
Those are Apple's US prices from early 2026; the M4 models have since been replaced by M6 and M5 Pro ones. The case for the Mac Mini rests on unified memory: GPU and CPU share RAM, so every GB counts. It also draws about 30W under a typical agent load (Apple rates the M4 at 4W idle and 65W at most, the M4 Pro at 5W and 140W1), roughly $6 a month of electricity, and it is silent and five inches on a side. macOS handles sleep/wake natively and gives you iMessage integration that no other platform can match.
1Apple, Mac mini power consumption and thermal output, 2026.
On the 48GB tier, generation speed is capped by the M4 Pro's 273 GB/s of memory bandwidth: a dense 32B model at Q4 (Qwen 3 32B, DeepSeek R1 32B), about 19 GB of weights, tops out near 14 tokens/sec, and an 8B model at Q4 runs several times faster. Community measurements on Apple Silicon are collected in llama.cpp's performance thread.
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 €5.49/month (CX23, €3.99 before June 2026) 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 24.16 or later (Node 22 sufficed when this was written; current releases no longer support it1).
1OpenClaw, Node.js, OpenClaw docs, 2026. Hetzner's new prices are in its price adjustment notice.
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 24 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_24.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 openclaw@latest openclaw onboard --install-daemon
# 5. Enable lingering: keeps the service running after SSH disconnect sudo loginctl enable-linger "$USER" systemctl --user daemon-reload systemctl --user enable --now openclaw-gateway.service
The wizard sets up authentication and your AI model (use the strongest current model; Claude Opus 4.5 when this was written), then installs the systemd service with an initial config. Verify with openclaw doctor and openclaw 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 (a subset).
Open WebUI Chat interface. Brandable with your own domain and logo.
n8n Workflow automation. Over 2,000 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.
Skills and channels
Skills decide what the agent can do and channels decide where you talk to it; both are configured as files.
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. When two share a name, workspace skills win, then the shared .agents/skills folders, then managed skills in ~/.openclaw/skills, and bundled skills lose to all of them1.
1OpenClaw, Skills, OpenClaw docs, 2026.
BASH Copy
# search, install, update (npm i -g clawhub) clawhub search "google workspace" clawhub install @steipete/gog clawhub update --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
self-improvement Agent can modify its own prompts
skill-creator Agent can build new skills
ClawHub security.
In February 2026, Koi Security found 341 malicious skills on ClawHub, most of them installing an infostealer. Snyk found critical issues (credential theft, remote code execution) in 13.4% of the 3,984 skills it audited across ClawHub and skills.sh1. OpenClaw partnered with VirusTotal to scan published skills, which catches known signatures and misses novel techniques. Use local skills only for production. No public registry pulls without reading the source.
1Snyk, ToxicSkills, 5 February 2026.
Creating a custom skill is a markdown file dropped into ~/.openclaw/skills/my-skill/SKILL.md:
MARKDOWN Copy
--- name: my-custom-skill description: What this skill does metadata: openclaw: requires: env: - MY_API_KEY ---
# 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, Socket Mode or HTTP
iMessage Hard macOS only, through the imsg plugin (the BlueBubbles bridge has been removed)
Signal Hard Requires linked device via signal-cli
All channels share the same agent and its memory. Configure each in ~/.openclaw/openclaw.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.
TailscaleVPSGateway, SkillsMacBlueBubbles serveriMessage
BlueBubbles runs on the Mac with iMessage signed in and its Private API enabled, and the VPS reaches it over Tailscale through OpenClaw's BlueBubbles channel. Your VPS-hosted agent then sends iMessages through your Mac. That bridge has since been removed from OpenClaw: iMessage now runs through the @openclaw/imessage plugin and imsg on the Mac itself1.
1OpenClaw, BlueBubbles and iMessage, OpenClaw docs, 2026.
Proactive features
The agent can reach out without being asked. Scheduled jobs are created from the CLI and kept by the Gateway1:
1OpenClaw, Managing jobs, OpenClaw docs, 2026.
BASH Copy
openclaw automations add --name "Morning briefing" --cron "0 8 * * *" \ --message "Summarize unread emails and today's calendar" --session isolated openclaw automations add --name "Weekly review" --cron "0 18 * * FRI" \ --message "Create a weekly summary of completed tasks" --session isolated
Heartbeat checks (every 30 minutes by default1) 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.
1OpenClaw, Heartbeat, OpenClaw docs, 2026; an hour when you sign in with Anthropic OAuth.
What's exposed on your machine
The rest of this guide is about what the agent could 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 logs anyone in as you.
Signal/Telegram DBs ~/Library/Application Support/Signal/ Message history. Signal Desktop kept its database key in plaintext until mid-2024.
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, and another app's first read triggers a system prompt1. 1Apple, Keychain data protection, Apple Platform Security.
Chrome saved passwords (macOS/Windows) Encryption key lives in Keychain or in DPAPI, the Windows Data Protection API, which binds it to the user account; on Windows Chrome adds App-Bound Encryption on top since version 1271. 1Google, Improving the security of Chrome cookies on Windows, 2024.
Kernel operations Installing drivers or extensions requires admin password elevation.
Hardware-backed keys TPM or Secure Enclave, a separate chip that holds keys and never releases them to software.
The containment goal is to keep the agent inside what the second table protects and away from everything in the first. Every technique below does some version of this.
Option 1: Docker
Running the agent in a Docker container cuts it off from your files and your network in a single command1. For most threat models, a malicious skill included, it's enough.
1A container is an isolated environment: the program inside gets its own filesystem and network, and 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, down to DNS. 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 or write anywhere 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, the special privileges containers get by default1.
1Docker, Running containers, Docker docs; the list is 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, and dropping them all leaves the process with 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, most of it adjusting the two volume paths.
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, if only to call an API. Docker's default bridge network gives internet access and LAN access together, so the agent can reach the internet but also scan every device on your home network. A custom network with iptables rules that block LAN access fixes it1:
1iptables is the Linux firewall: rules that filter traffic by source, destination, port and protocol, used here to block private IP ranges and allow everything else; Docker documents the DOCKER-USER chain as the place for your own rules.
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 or your partner's laptop. 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 of Linux's roughly 350 syscalls go directly to the host, so a kernel exploit inside the container can mean root on the host. This has happened (CVE-2019-5736 in runc, Dirty COW).
Google's gVisor, an open-source runtime that puts a user-space kernel called the Sentry between the container and the host, dramatically reduces this attack surface1:
1The Sentry re-implements 237 syscalls in user space and itself needs only 53 host syscalls without networking, 68 with it: gVisor, gVisor security basics, part 1, 2019.
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 on I/O-heavy workloads, but the kernel attack surface drops from about 350 syscalls to between 53 and 68. Google uses it in production for GKE Sandbox.
Setup time: 30 minutes, most of it installing runsc and registering it with Docker.
Option 2: Virtual machines
Docker is a room inside your house, with real walls on the same foundation. A VM is a separate house on a different street, with a kernel and memory of its own. 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 ~350 syscalls exposed A small hypervisor interface and a few emulated devices
Escape difficulty A kernel exploit reaches the host 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 (--isolated keeps your Mac out of reach): orb create --isolated ubuntu agent-sandbox orb -m agent-sandbox
# inside the VM: install what you need, run the agent # your macOS home directory, SSH keys and browser profiles stay invisible
The overhead is small enough to forget the VM is running: OrbStack claims less than 0.1% background CPU and under 10 MB of disk. The isolation is the part to get right. By default an OrbStack machine mounts your Mac's files at /mnt/mac, can run Mac commands and gets your SSH agent forwarded, so your credentials and files are only out of reach if you create the machine with --isolated1.
1OrbStack, Isolated machines, OrbStack docs, 2026.
Docker containers inside OrbStack get an extra layer: a container escape lands in the OrbStack Linux VM, which on an isolated setup is far from your Mac. Docker Desktop on macOS also runs containers inside a Linux VM, so the difference between the two is what that VM can reach of your Mac, and OrbStack's isolated machines make that explicit.
Setup time: 5 minutes. Install the app, create the VM.
macOS: UTM (15 minutes)
For maximum isolation, UTM wraps QEMU with a macOS-native GUI. It is a full VM that shares no state with the host, down to its own kernel and disk image.
It is heavier than OrbStack (~256 MB+ per VM) and slower to create, since you install 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 under 125ms, with under 5 MiB of memory overhead per VM. A companion program, the 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.
Apple Containers
Apple announced native containerization at WWDC 2025 for macOS Tahoe. Each container runs in its own lightweight VM instead of sharing a kernel the way Docker containers do. Each container starts in under a second with an IP of its own, on top of Virtualization.framework. It was a developer preview when this was written; version 1.0 shipped in June 2026, and on macOS 26 it is a serious candidate for the default answer.
Option 3: Cloud deployment
On a cloud server, none of your files are there. Your SSH keys stay on your laptop and your local network stays at home, so the agent's full access reaches 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, January 2026) 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://openclaw.ai/install.sh | bash exec bash
# 4. Run the onboarding wizard with daemon mode openclaw 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
The gateway then runs as a systemd service that survives SSH disconnects and reboots. You chat through WhatsApp, the TUI (openclaw 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 riskThe droplet doesn't have your SSH keys, browser sessions, or personal documents.
No LAN accessThe server sits in a datacenter, away from your home network, so your NAS, cameras, and smart home are unreachable.
Easy to destroyIf something goes wrong, delete the droplet. Your local machine is untouched.
Snapshots and backupsDigitalOcean Snapshots, or scp the ~/.openclaw/ directory for state backup.
Firewall at the VPC levelCloud 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, email triage or web research for instance, the agent doesn't need your local files at all. A file-heavy workflow such as managing a photo library would need specific directories synced to the server, which partially defeats the purpose.
DigitalOcean's own guide warns that giving a third party agent framework access to your local machine introduces a lot of security risks, so use Moltbot at your own risk, and recommends deploying it in an isolated environment with no 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 openclaw logs --follow
And back up the agent's state, which holds its memory and conversation history:
BASH Copy
# from your local machine: weekly backup scp -r clawd@YOUR_DROPLET_IP:~/.openclaw ~/openclaw-backup-$(date +%Y%m%d)
Networking
There are three ways to reach your Gateway remotely. The most secure is an SSH tunnel:
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.
The second, recommended when several devices need access, is Tailscale:
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:
VPS100.x.y.1 · Gateway, SkillsMac100.x.y.2 · iMessage bridgeMobile100.x.y.3 · App
The third is an Nginx reverse proxy, only if you absolutely need HTTPS and 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.
The Gateway broadcasts via mDNS for local device discovery. In full mode the broadcast carries your CLI path (which can reveal your username) and SSH port; the default, minimal, leaves them out1. To switch discovery off entirely:
1OpenClaw, Bonjour discovery, OpenClaw docs, 2026.
```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.
This isn't as robust as VLANs, which add per-port control and firewall rules, but it's a real improvement over a flat network where everything can talk to everything.
VLANs (half a day to a weekend)
VLANs give you real network segmentation with firewall rules between zones1.
1802.1Q virtual LANs carve one physical network into multiple isolated virtual segments: devices on VLAN 10 cannot talk to devices on VLAN 20 unless an explicit firewall rule allows 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
OpenClaw's security layer
OpenClaw has built-in access controls. They decide who may message your bot and do nothing about 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 a mention1:
1OpenClaw, Groups, OpenClaw docs, 2026.
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 (the default), only for your personal agent
non-main Every session but the agent's main one runs in a container
all All tool execution in a container
workspaceAccess sets what a container sees of the workspace (none, ro or rw), and scope decides how containers are shared1:
1OpenClaw, Modes, scope and backend, OpenClaw docs, 2026.
agentOne container per agent, the default.
sessionOne per session, the strictest.
sharedOne for all sandboxed sessions.
Security audit
BASH Copy
openclaw security audit # basic openclaw security audit --deep # with live Gateway probe openclaw security audit --fix # auto-fix common issues
The --fix flag turns open group policies into allowlists and tightens the permissions of the state, config and credential files; it never rotates credentials or changes network exposure1.
1OpenClaw, security, OpenClaw CLI docs, 2026.
Model choice matters
Use the latest-generation, best-tier model for any bot with tools enabled (Claude Opus 4.5 when this was written). Smaller models (Sonnet, Haiku) are more susceptible to prompt injection, crafted content that manipulates the model into doing something the operator didn't intend1. OpenClaw's docs cite a test in which attacks succeeded 0.5% of the time against Opus 4.5 and more often against smaller models2.
1It doesn't require public DMs: any untrusted content the bot reads, a web page or an email, can carry adversarial instructions. 2OpenClaw, Prompt injection, OpenClaw docs, 2026.
Incident response
If you suspect compromise:
Contain: systemctl --user stop openclaw-gateway.service Rotate: Gateway auth token, browser control token, API keys, OAuth tokens Audit: check logs (/tmp/openclaw/openclaw-*.log), review session transcripts (~/.openclaw/agents/*/sessions/*.jsonl), grep for unusual tool calls Re-scan: openclaw security audit --deep
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 keysssh-keygen -p -f ~/.ssh/id_ed25519 adds a passphrase. 30 seconds per key.
Git credential storegit config --global credential.helper osxkeychain switches from a plaintext file to the encrypted keychain.
Stale .env filesMove production .env files off any machine that runs an AI agent and use a secrets manager (1Password CLI, Doppler, Vault) instead.
Firefox cookiesUse a separate browser profile for sensitive sessions (banking, email) and keep the agent machine's browser clean.
Cost
What a team of five pays for cloud AI tools in a month, against what the same work costs on your own hardware.
Cloud AI (team of 5, monthly)
Service Cost
ChatGPT Business (formerly Team) $150
Claude Pro $20
Zapier $20–70
Notion Business (AI included) ~$100
API credits $50–250
Total $340–590 a month, $4,080–7,080 a year
The seat prices are from the vendors' pages: Claude Pro is $20 a month and Zapier Professional starts at $19.99. Notion keeps its AI for the Business plan, which is why the table prices that tier.
OpenClaw infrastructure
Item Cost
Mac Mini M4 16GB $599 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 $599 model: 2–4 months. On the $1,999 model: 6–10 months.
What you keep is control: nobody charges you per seat, and nobody trains on your data.
Claude Pro/Max subscription.
Using a Claude Pro or Max subscription instead of metered API billing is dramatically cheaper for heavy usage, with a flat monthly fee against per-token billing. OpenClaw's docs still recommend an API key for shared production automation, since that use draws on the subscription's limits and Anthropic can change them1.
1OpenClaw, Anthropic, OpenClaw docs, 2026.
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 ~350 to 53–68 syscalls
Full VM (UTM / Firecracker) 15 min–weekend Maximum isolation, separate everything
The first seven rows.
They take under an hour combined and close most of the exposure on a home machine. The rows after them are real protection with diminishing returns. If you only do one thing, make it guest WiFi; Docker comes second, and the credential audit after it.
Why the supply chain matters, and what Moltbook suggests about where this is heading, is the subject of the thread this guide grew out of: OpenClaw and the keys to your kingdom.