High Risk
Runs directly on your machine with full system-level access
The local setup runs OpenClaw natively on your PC or laptop. It has access to your files, browser, tokens, and can execute shell commands. Best for personal use with maximum control — but carries the highest risk profile of all four modes.
Windows (WSL2)
macOS
Linux
Prerequisites
Node.js v22+ (v24 recommended) and Git (optional but useful). The installer script handles Node.js automatically on all platforms.
Step-by-Step Installation
1
Run the Official Installer
Choose the command for your platform and run it in a terminal.
macOS / Linux / WSL2
curl -fsSL https://openclaw.ai/install.sh | bash
2
Complete Onboarding with Daemon
openclaw onboard --install-daemon
Follow the on-screen prompts to configure your model provider, skills, and hooks.
3
Verify Installation
openclaw --version
openclaw doctor
openclaw gateway status
Alternative Installation Methods
# npm
npm install -g openclaw@latest
# pnpm
pnpm add -g openclaw@latest
pnpm approve-builds -g
# bun
bun add -g openclaw@latest
Thousands of OpenClaw instances have exposed data publicly due to misconfiguration. Even Microsoft warns: treat OpenClaw like untrusted code.
Critical
File System Access
The gateway runs with your full user permissions. It can read, write, and execute anything your account can touch — no container boundary by default.
Critical
Credential Leakage
API keys, OAuth tokens, and session credentials stored in ~/.openclaw/ as plaintext. A compromised process reads them all instantly.
Critical
Prompt Injection
Agent can be manipulated via emails, documents, or web content it reads. A compromised agent with local exec access can exfiltrate data silently.
Medium
Malicious Plugins
Skills and plugins extend agent capabilities. A malicious plugin from an untrusted source has the same access level as the agent itself.
Medium
Remote Access via Port
If the gateway port is exposed to the network — even accidentally — it becomes a remote code execution endpoint for anyone who can reach it.
Low
mDNS Broadcast
By default the gateway broadcasts its presence on your LAN via mDNS, revealing install location and hostname to anyone on the network.
Hardening Recommendations
Never do this
- ✕ Run as root
- ✕ Expose gateway port publicly
- ✕ Hardcode API keys in config
- ✕ Install unverified skills/plugins
Always do this
- ✓ Use a separate OS user account
- ✓ Block gateway port via firewall
- ✓ Store API keys in .env only
- ✓ Use minimal permissions
- ✓ Monitor logs continuously
# Set file permissions immediately after install
chmod 700 ~/.openclaw
chmod 600 ~/.openclaw/openclaw.json
# Run the built-in security audit
openclaw security audit
openclaw security audit --fix
Low Risk
Fully isolated environment — best choice for beginners and experimentation
Sandbox Mode runs the OpenClaw agent inside an isolated Docker container or cloud-hosted environment. No access to your local system. The simplest and safest way to start using OpenClaw without putting your machine at risk.
Setup Options
A
Platform-Based (Easiest — No CLI Required)
Go to a sandbox platform like SandboxClaw, click Deploy, select your runtime (OpenClaw / NanoClaw etc.), add API keys, and you're done.
B
Docker Sandbox (Manual)
docker run -it openclaw/openclaw
Runs the full OpenClaw environment inside a container. Agent tool operations are isolated from your host filesystem entirely.
Why it's safer
- ✓ Fully isolated environment
- ✓ Zero access to your local system
- ✓ No CLI setup required
- ✓ Easy to reset and start fresh
Remaining risks
- ⚠ Cloud provider access to your data
- ⚠ API key leakage within sandbox
- ⚠ Malicious tasks running inside container
- ⚠ Cost abuse from auto-running tasks
- ✓ Use limited-scope API keys with usage caps
- ✓ Enable usage limits on your LLM provider dashboard
- ✓ Monitor activity logs regularly
- ✓ Rotate credentials frequently
- ✕ Never store sensitive files inside the sandbox
Medium Risk
Better than local, not perfect — significantly reduces blast radius
Running OpenClaw on a Virtual Machine separates the agent from your personal machine entirely. A good middle ground for active development — provides meaningful isolation while giving you full control over configuration.
Recommended VM Setup
1
Create a Virtual Machine
Use VirtualBox, VMware, or KVM. Install Ubuntu 22.04 (recommended). Allocate at least 2 GB RAM.
2
Set Up Environment Inside VM
sudo apt update
sudo apt install curl git -y
3
Install OpenClaw
curl -fsSL https://openclaw.ai/install.sh | bash
openclaw onboard --install-daemon
4
Access the Dashboard
Open http://localhost:PORT in a browser running inside the VM, or forward the port via SSH tunnel to your host.
Medium
VM Escape Vulnerabilities
Rare but real — a sufficiently sophisticated exploit could break out of the VM boundary and affect the host machine. Keep hypervisor software updated.
Medium
Misconfigured Shared Folders
Shared folders between VM and host create a direct data path. If OpenClaw can write to a shared folder, it can affect your host filesystem.
Medium
Port Forwarding Exposure
Port forwarding from VM to host, especially to 0.0.0.0, exposes the gateway to your local network and potentially the internet.
Low
Same API Key Risks
API keys stored in the VM are as sensitive as local ones. A compromised VM still leaks credentials to whoever compromised it.
Hardening Recommendations
Disable in VM settings
- ✕ Shared folders
- ✕ Clipboard sharing
- ✕ Bridged networking mode
- ✕ Port forwarding (unless secured)
Enable in VM settings
- ✓ NAT network (not bridged)
- ✓ Separate user accounts inside VM
- ✓ VM snapshots before experiments
- ✓ Full disk encryption on VM volume
Key insight: Running OpenClaw in a VM reduces blast radius significantly. Even if the agent is compromised, your personal files, tokens, and OS remain protected.
Medium–High Risk
If misconfigured — thousands of servers found exposed with no authentication
Deploy OpenClaw on a remote VPS (DigitalOcean, AWS, Hetzner, etc.) for always-on, production-grade deployments. Full control over your infrastructure, but carries significant risk if security hardening is neglected.
⚠
Golden rule: Never expose the OpenClaw dashboard publicly without an authentication token. An unauthenticated gateway is a remote code execution endpoint — no exceptions.
Step-by-Step Cloud Setup
1
Create an Ubuntu VPS
Provision any Ubuntu VPS (22.04+ recommended) with at least 2 GB RAM. Connect via SSH:
ssh user@your-server-ip
2
Install OpenClaw
curl -fsSL https://openclaw.ai/install.sh | bash
openclaw onboard --install-daemon
3
Set Up Domain + HTTPS
Use Nginx or Caddy as a reverse proxy. Add SSL via Let's Encrypt. Never serve the gateway directly over HTTP.
4
Secure the Gateway (Critical)
# Set a strong auth token immediately
openclaw config set gateway.auth.mode token
openclaw config set gateway.auth.token "$(openssl rand -hex 32)"
# Configure firewall — allow SSH, block gateway port from public
ufw allow 22
ufw deny 3000 # your gateway port
5
Verify Deployment
openclaw doctor
openclaw gateway status
openclaw security audit
Critical
Unauthenticated Public Exposure
Setting gateway.bind: "0.0.0.0" without auth is a remote code execution endpoint. Anyone reaching the port can send commands with full tool access.
Critical
Token Theft
Gateway auth tokens and API keys stored on the VPS. A server compromise exposes all credentials and allows full remote agent control.
Critical
Remote Command Execution
Any unauthorized access to the gateway API grants shell execution on the VPS. Without IP whitelisting, every internet host is a potential attacker.
Medium
Data Leaks from Logs
Session transcripts and tool outputs are stored in plaintext on disk. Log files often contain sensitive data from connected channels and API responses.
Medium
SSH Brute Force
VPS management SSH port is exposed by necessity. Without key-only auth, fail2ban, and port hardening, it's a persistent brute-force target.
Low
Docker Firewall Bypass
Docker bypasses UFW's INPUT rules via its own iptables chains. Published ports may be internet-accessible even when UFW blocks them.
Hardening Checklist
- ✓ Always enable authentication token before anything else
- ✓ Restrict access via IP whitelist
- ✓ Use HTTPS only via reverse proxy (Nginx/Caddy)
- ✓ Disable all public ports not needed
- ✓ Install fail2ban for intrusion detection
- ✓ Monitor logs continuously
- ✓ Use SSH key authentication only (disable password auth)
- ✕ Never expose dashboard publicly without auth
- ✕ Never use root for OpenClaw processes
First — What NemoClaw Really Is (in practice)
NemoClaw is typically:
- ✓ A minimal runtime / execution engine
- ✓ More focused on inference + controlled workflows
- ✓ Less “autonomous agent chaos” compared to OpenClaw
👉
Translation: OpenClaw = “AI that can do anything (risky).” NemoClaw = “AI that does specific tasks (safer if configured right).”
🔍 NemoClaw Across the Same Four Modes
🖥️ 1. Local setup (NemoClaw)
Better than OpenClaw — still risky
⚠️ Recommendation: manageable if you isolate the environment
Why it's safer: Less system-level autonomy; fewer background agents; typically no uncontrolled tool execution.
Still accesses local files, GPU/CPU, model weights & configs. If misconfigured → can still execute scripts.
Suggestion
Local is OK only if you are developing models, you isolate the environment, and you avoid root. Best setup: Python venv or Conda, no root access, separate workspace directory.
🧪 2. Sandbox mode (NemoClaw)
Best option
🟢 This is where NemoClaw shines
Why: Designed for controlled execution. Works well in Docker, cloud sandboxes, and GPU containers.
Risks
- ⚠ API key leakage
- ⚠ Model misuse (e.g. harmful outputs)
- ⚠ Resource abuse
Best practices
- ✓ Limit GPU usage
- ✓ Set execution timeouts
- ✓ Use read-only volumes where possible
Verdict: NemoClaw + sandbox = best balance of power + safety.
🖥️ 3. Virtual machine (NemoClaw)
Very good
🟡 VM isolation + reduced attack surface from NemoClaw
The VM adds isolation; NemoClaw reduces attack surface — together, much safer than OpenClaw in a VM.
Risks: GPU passthrough vulnerabilities (if used), shared-folder leakage, misconfigured networking.
Best setup: No shared folders, NAT networking, limited ports, snapshot before experiments.
Use cases: Model experimentation, offline inference, controlled pipelines.
☁️ 4. Cloud setup (NemoClaw)
Good if secured
🟡→🟢 Less exposed surface than typical OpenClaw cloud setups
Why it's often better than OpenClaw here: Smaller attack surface; no uncontrolled agents scanning APIs.
Risks
- ⚠ Public endpoint exposure
- ⚠ API misuse (LLM abuse)
- ⚠ GPU cost explosion
- ⚠ Model / data leaks
Best practices
- ✓ Private endpoints
- ✓ Authentication (JWT / tokens)
- ✓ Rate-limit APIs
- ✓ Monitor GPU usage
- ✓ Use VPC; avoid public IP when possible
Ideal split
Use NemoClaw for
- ✓ Video generation backend
- ✓ Controlled AI tasks
- ✓ API-based processing
Use OpenClaw only for
- ✓ Internal automation
- ✓ Experiments
- ✕ Never expose publicly
Suggested setup
| Context |
Setup |
| ✅ Production (safe) |
NemoClaw on cloud (private API) — Android app → API → NemoClaw → response |
| 🧪 Experimentation |
OpenClaw in VM (offline or restricted) |
| 🚫 Avoid |
OpenClaw on your main laptop; public OpenClaw without auth; mixing both in the same environment |
⚠
Final insight: The biggest danger is not the tool — it's the level of autonomy + exposure. OpenClaw “can act on its own” → dangerous. NemoClaw “waits for instructions” → controllable.
Simple rule: Want automation + agents → OpenClaw (isolated only). Want reliable backend processing → NemoClaw.