OpenClaw Docker Security Hardening

1. Why Docker Security Matters for OpenClaw

OpenClaw is an autonomous agent that can run shell commands, read and write files, and call external APIs. In a container, that power is constrained only by what you expose: volumes, network, and capabilities. A compromised or misconfigured container could:

• Escape the container and control the host (e.g. via docker.sock)
• Access sensitive host paths if you mount too much
• Exhaust host resources (CPU, memory) without limits
• Reach the gateway or other services if the network is too permissive

Hardening your Docker setup reduces these risks while still letting OpenClaw do its job. The practices below follow the guidance in our Security Best Practices and align with standard container security advice (minimal privileges, isolation, resource limits).

2. Never Mount the Docker Socket

The Docker socket is the API that the Docker CLI and other tools use to talk to the Docker daemon. Anyone with access to it can start, stop, and modify containers; pull images; and effectively take over the host. Because OpenClaw can execute commands and may run user-provided or skill-driven code, giving it access to docker.sock creates a direct path for container escape and host compromise.

What to do:

• Omit any volumes entry that maps /var/run/docker.sock (or docker.sock) into the OpenClaw service.
• If a skill or tutorial suggests mounting the socket “to manage Docker,” treat it as high-risk and avoid it for production. Prefer out-of-band tooling (e.g. run Docker commands from the host or a dedicated management container with strict access control).

For network and gateway isolation in general, see Network Isolation.

3. Use Minimal Volume Mounts

Mount only the directories the application needs. For OpenClaw, that typically means:

• Config and data: A single volume (e.g. openclaw-data:/root/.openclaw) for config, state, and session data. Use a named volume or a bind mount to a dedicated directory-not /, /home, or other broad host paths.
• Avoid: Mounting the entire home directory, /etc, or host project directories unless you have a clear, minimal use case. Each extra mount increases the attack surface and the damage an attacker could do from inside the container.

Example of a minimal volume setup in docker-compose.yml:

services:
  openclaw:
    image: openclaw/openclaw:latest
    volumes:
      - openclaw-data:/root/.openclaw
    # No docker.sock, no host paths like /home or /etc

volumes:
  openclaw-data:

If you need to inject a config file, prefer a small bind mount of that file or a read-only mount of a config directory. For full deployment steps, see Docker Deployment.

4. User Namespace Isolation

By default, containers often run as root (UID 0) inside the container. If an attacker breaks out (e.g. via a vulnerability), they might be able to leverage that to access host resources. User namespace remapping maps container UIDs to non-root UIDs on the host, so a root user inside the container is not root on the host.

What to do:

• On the Docker daemon, enable user namespace support (e.g. in /etc/docker/daemon.json with "userns-remap": "default" or a dedicated user). This is a host-level setting and affects all containers; read the Docker documentation on userns-remap for your platform.
• Alternatively, run the container as a non-root user if the image supports it (e.g. user: "1000:1000" in the service). Ensure the mounted volume has correct ownership so OpenClaw can write config and state.

User namespaces add a layer of defense; combine them with minimal mounts and no docker.sock for a stronger posture.

5. Resource Limits

Set CPU and memory limits so a runaway process or abuse cannot starve the host or other containers. In Docker Compose (v3), use deploy.resources:

services:
  openclaw:
    image: openclaw/openclaw:latest
    deploy:
      resources:
        limits:
          cpus: '2'
          memory: 1G
        reservations:
          memory: 256M

Adjust values to your workload: light use may be fine with 512M–1G memory; heavy use (many channels, memory-hungry skills) may need more. Limits both protect the host and make resource issues easier to diagnose. For sizing guidance, see Performance Optimization.

6. Network Isolation and Gateway Binding

Keep the OpenClaw gateway off the public internet. In Docker:

• Bind the gateway to localhost only: Publish the port as 127.0.0.1:1618:1618 so the gateway is reachable only from the host, not from other machines. Never use ports: - "1618:1618" on a host with a public IP unless you put a reverse proxy and auth in front.
• Use a dedicated bridge network: Create a custom network (e.g. networks: openclaw-net: { driver: bridge }) and attach only the OpenClaw service (and any trusted sidecars). Avoid attaching it to a network that exposes ports to the internet.

For remote access, use Tailscale, SSH port forwarding, or a VPN-not an open gateway port. Details: Network Isolation and the Golden Rule in Security Best Practices.

7. Read-Only Filesystem and Non-Root (Where Possible)

Additional hardening options:

• Read-only root filesystem: Some images support read_only: true with a writable tmpfs or a single writable volume for /root/.openclaw. This limits an attacker from writing to system paths inside the container. Test thoroughly-OpenClaw may need to write to temp or cache directories.
• Run as non-root: If the image supports a non-root user, run the container with that user to reduce the impact of compromise inside the container. Ensure your data volume has the correct ownership.

These are optional; prioritize “no docker.sock,” minimal volumes, resource limits, and gateway binding first.

8. Security-Optimized Base Image and Dockerfile

If you build a custom image instead of using the official one:

• Use a minimal, maintained base image (e.g. Alpine or distroless) and keep it updated.
• Use multi-stage builds so the final image does not contain build tools or secrets.
• Do not bake API keys or secrets into the image; use environment variables or secrets at runtime (see Credential Management).
• Pin the base image tag and rebuild periodically for security patches.

For most users, the official OpenClaw image plus the hardening steps above is sufficient; custom Dockerfiles are only needed for special environments.

9. Docker-Specific Issues and Solutions

For more problems, see the Troubleshooting Guide and Docker Deployment.

10. Quick Reference: Hardened Compose Snippet

A minimal hardened example (no docker.sock, minimal volume, resource limits, gateway on localhost):

services:
  openclaw:
    image: openclaw/openclaw:latest
    container_name: openclaw
    restart: unless-stopped
    env_file: .env
    volumes:
      - openclaw-data:/root/.openclaw
    ports:
      - "127.0.0.1:1618:1618"
    deploy:
      resources:
        limits:
          cpus: '2'
          memory: 1G

volumes:
  openclaw-data:

Add user namespace or read-only options as needed for your environment. After deployment, run through the Security Checklist.

Related Resources

• Security Best Practices - Full hardening guide
• Network Isolation - Firewall and gateway binding
• Credential Management - API keys and secrets
• Docker Deployment - Installation and compose setup
• Security Checklist - Post-install checklist
• Security Hub - All security topics

Next Steps

After hardening your Docker setup:

• Complete Post-Installation Setup and configure your first channel.
• Review Skills Security before installing third-party skills from ClawHub.
• Set up Monitoring & Logging for audit and anomaly detection.