How to Securely Set Up and Configure ClawdBot

Most ClawdBot setup guides get you running fast and secure never. This one does both. We'll walk through a complete installation with security as the default, not an afterthought.

What is ClawdBot?

ClawdBot is the managed/hosted runtime for OpenClaw. Think of OpenClaw as the engine and ClawdBot as the car — it packages everything you need: the runtime, web interface, agent management, and MoltBow platform.

Phase 1: Secure the Host

Create a dedicated system user (clawdbot), lock down SSH (port 2222, no root login, key-only auth), and enable automatic security updates with unattended-upgrades.

Phase 2: Environment Configuration

Set up a structured directory at /opt/clawdbot/ with separate folders for config, secrets (chmod 700), data, and logs. Create a clawdbot.yml config with security-first defaults: localhost binding, CORS restrictions, rate limiting, agent sandboxing, and encrypted storage.

Use Docker Secrets for API keys, run containers as non-root with read-only filesystem, drop all Linux capabilities, and set resource limits.

Phase 3: Authentication and Access Control

Require API key auth on every request. Create per-user keys for granular access control. Lock CORS to known domains only — never use origins: ["*"].

Phase 4: Agent Sandboxing

The most important security layer. Enable container-level sandboxing with restricted network access (only LLM API domains), blocked dangerous commands, filesystem isolation per agent, and resource limits including PID limits to prevent fork bombs.

Phase 5: Logging and Auditing

Use JSON structured logging with secret redaction. Enable audit trails for auth events, agent operations, and config changes. Set up log rotation to prevent disk exhaustion.

Phase 6: Start and Verify

Verify: container runs as non-root, filesystem is read-only, auth is required, port is not externally exposed.

Ongoing Maintenance

Monthly: rotate keys, review audit logs, update ClawdBot, check spending. Quarterly: full security audit, pen testing, backup restore test, dependency audit.

For teams that want agents without becoming security engineers, RunAgents handles all of this.

Rather not become a part-time security engineer? RunAgents gives you managed OpenClaw hosting with task management, team collaboration, and agent debugging built in. Get started free →

Related Guides

• How to Secure Your ClawdBot Deployment — Firewall, rate limiting, and network-level security for your agent

• How to Deploy OpenClaw on a Linux VPS — Provider-agnostic deployment guide with security best practices

• ClawdBot Complete 2026 Guide — Everything you need to know about ClawdBot in one place

Frequently Asked Questions

What permissions should my ClawdBot container run with?

Run as non-root (user: "1000:1000"), drop all Linux capabilities with cap_drop: ALL, use a read-only filesystem, and enable no-new-privileges. Only mount specific directories the agent needs (config, data, logs) and set them with the tightest permissions possible (chmod 700 for secrets).

What firewall rules do I need for a secure ClawdBot setup?

Allow only SSH (preferably on a non-default port like 2222), HTTP (80), and HTTPS (443). Deny all other incoming traffic. ClawdBot should bind to localhost only — never expose port 3000 directly. Use nginx as a reverse proxy with rate limiting and security headers.

How often should I update ClawdBot for security patches?

Check for updates weekly and apply them monthly at minimum. Enable unattended-upgrades for the host OS to get critical security patches automatically. For ClawdBot itself, use an update script with automatic rollback on failed health checks so you don't break production.

Can multiple users share a ClawdBot instance securely?

ClawdBot is fundamentally single-user by design. You can create per-user API keys for basic access separation, but there's no built-in RBAC, audit trails per user, or permission scoping. For true multi-user setups with proper access control, RunAgents provides team collaboration with role-based permissions out of the box.

How do I prevent agents from accessing sensitive files on the host?

Use Docker's filesystem isolation — mount only specific directories the agent needs, use read-only mounts where possible, and enable container-level sandboxing in ClawdBot config. Restrict network access to only LLM API domains and block dangerous shell commands. PID limits prevent fork bombs from exhausting system resources.