OpenClaw Docker Security and Production Deployment Guide (2026)

Running OpenClaw in Docker provides filesystem isolation and non-root execution by default, but production deployments need more — firewalls, reverse proxies with TLS, agent sandboxing, secret management, and monitoring. This guide covers how to harden your OpenClaw Docker deployment for real-world use.

What Security Does OpenClaw Docker Provide by Default?

Out of the box, OpenClaw's Docker setup provides three layers of protection that form the foundation for production hardening.

1. Non-Root Execution

OpenClaw runs as the node user (UID 1000), not root. This limits what the agent can do inside the container — it cannot install system packages, modify system files, or escalate privileges without explicit root access.

2. Filesystem Isolation

Docker containers isolate the agent from your host filesystem. The agent can only access directories explicitly mounted as volumes: ~/.openclaw/ for configuration and state, and ~/.openclaw/workspace/ for agent-accessible files. Everything outside these mounts is invisible to the agent.

3. Network Default

The default network setting restricts outbound access. Internet connectivity must be explicitly enabled for the agent to reach external APIs.

These defaults are good but not enough for production. Below is how to harden your deployment.

How Does Agent Sandboxing Work in OpenClaw?

OpenClaw supports an additional sandbox layer that runs agent tool execution in separate isolated containers — a container within a container.

Enabling the Sandbox

export OPENCLAW_SANDBOX=1
./scripts/docker/setup.sh

Sandbox Modes

Sandbox Scope

For maximum security, use mode: "all" with scope: "session" — every conversation gets a fresh, isolated container.

How Do You Restrict Tools Per Agent?

In multi-agent setups, restrict what each agent can do with allow/deny lists. This gives your public-facing agent read and execute permissions only, while your trusted admin agent has full access. Combined with sandboxing, this creates defense in depth.

{
  "agents": {
    "list": [
      {
        "id": "public-facing",
        "sandbox": { "mode": "all", "scope": "session" },
        "tools": {
          "allow": ["read", "exec"],
          "deny": ["write", "edit", "apply_patch"]
        }
      },
      {
        "id": "trusted-admin",
        "sandbox": { "mode": "off" },
        "tools": {
          "allow": ["read", "write", "edit", "exec", "apply_patch"]
        }
      }
    ]
  }
}

What Network Security Should You Configure?

Firewall Configuration

On a production server, lock down ports:

# Allow SSH
sudo ufw allow 22/tcp

# Allow OpenClaw gateway (restrict to your IP if possible)
sudo ufw allow from YOUR_IP to any port 18789

# Enable firewall
sudo ufw enable

Best practice: Never expose port 18789 to the public internet without authentication and TLS.

Gateway Binding Modes

For remote access, Tailscale is the recommended approach — it provides encrypted, zero-config networking without exposing ports to the internet.

How Do You Set Up a Reverse Proxy With TLS?

For production deployments, put OpenClaw behind a reverse proxy with HTTPS.

Nginx Example

server {
    listen 443 ssl http2;
    server_name openclaw.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/openclaw.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/openclaw.yourdomain.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:18789;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Caddy Example (Automatic TLS)

openclaw.yourdomain.com {
    reverse_proxy 127.0.0.1:18789
}

Caddy handles Let's Encrypt certificate provisioning automatically.

What Is the Best Approach to Secret Management?

The default setup stores API keys in a .env file on disk. For production, this is insufficient.

Better Approaches

• Docker Secrets (Swarm mode): Mount secrets as files inside the container.
• Environment variable injection (CI/CD): Pass secrets at runtime without writing them to disk.
• External secret managers: Integrate with HashiCorp Vault, AWS Secrets Manager, or 1Password CLI.

What NOT to Do

• Never commit .env files to version control
• Never hardcode API keys in Dockerfiles or docker-compose.yml
• Never share API keys between agents if you need audit trails
• Never log API keys — check that your logging configuration excludes environment variables

How Do You Monitor and Log OpenClaw in Docker?

Container Logs

# Follow live logs
docker compose logs -f openclaw-gateway

# Last 100 lines
docker compose logs --tail 100 openclaw-gateway

Health Monitoring

# Liveness — is the process running?
curl -fsS http://127.0.0.1:18789/healthz

# Readiness — is the gateway ready to handle requests?
curl -fsS http://127.0.0.1:18789/readyz

Resource Monitoring

Track container resource usage with docker stats. Watch for memory creep, disk growth from media and session files, and CPU spikes that may indicate runaway agent loops.

What Should Your Backup Strategy Include?

# Stop gateway to ensure consistent backup
docker compose stop openclaw-gateway

# Create timestamped backup
tar -czf openclaw-backup-$(date +%Y%m%d).tar.gz ~/.openclaw/

# Restart gateway
docker compose start openclaw-gateway

What Is the Complete Container Hardening Checklist?

For production deployments, verify each of these:

• Non-root execution — container runs as node user (UID 1000), not root
• Read-only filesystem — mount the root filesystem as read-only where possible
• Minimal base image — use the official image, avoid adding unnecessary packages
• No privileged mode — never run with --privileged
• Resource limits — set memory and CPU limits in docker-compose.yml
• Network restrictions — limit outbound to required API endpoints only
• TLS enabled — HTTPS via reverse proxy for all external access
• Firewall configured — only necessary ports open
• Secrets managed — no plaintext API keys on disk in production
• Agent sandbox enabled — tool execution in isolated containers
• Tool permissions restricted — per-agent allow/deny lists
• Logging configured — centralized log collection, no secrets in logs
• Backups scheduled — automated daily backups of configuration and data
• Updates planned — process for pulling and deploying new images
• Health checks active — automated liveness and readiness monitoring

Frequently Asked Questions

Is Docker required for OpenClaw?

No, but it is the recommended installation method. You can install OpenClaw directly on your system, but Docker provides better isolation and dependency management.

Can I run OpenClaw Docker on ARM servers?

Yes. Pre-built images are available for both amd64 and arm64 architectures.

How do I restrict the agent's internet access?

Use Docker's network settings to limit outbound connections. Create a custom Docker network that only allows traffic to your API provider's endpoints.

Should I use Docker Compose or Docker Swarm?

Docker Compose is sufficient for single-server deployments. Use Docker Swarm (or Kubernetes) only if you need multi-server clustering, which most OpenClaw deployments do not require.

Can I run the sandbox without Docker-in-Docker?

The sandbox requires Docker access to spawn isolated containers. If Docker-in-Docker is not available (e.g., some CI environments), you can disable sandboxing and rely on the outer container's isolation instead.

*Last updated: March 2026. Published by the Remote OpenClaw team at remoteopenclaw.com.*