Run OpenClaw with Docker

Docker is useful for a headless host, a repeatable lab, or tighter filesystem boundaries. It does not make an unsafe configuration safe by itself: mounted folders, network access, and container privileges still define the agent’s reach.

Decide what must persist

Persist the OpenClaw state and workspace locations documented by the image you deploy. An ephemeral container without state mounts will lose configuration and pairing data when it is replaced.

Keep three concerns separate:

1. Image — the OpenClaw runtime version.
2. State — configuration, credentials, and service metadata.
3. Workspace — the files the agent is allowed to use.

Apply least privilege

Avoid mounting the Docker socket, the entire host filesystem, or a home directory into the container. Mount only the workspace directories the agent needs. Run as the image’s intended non-root user and correct host volume ownership instead of falling back to root.

Verify after startup

Execute the standard diagnostic ladder inside the running environment:

openclaw status --all
openclaw gateway status
openclaw gateway probe
openclaw doctor

Expected result

The Gateway reports a running runtime and successful connectivity. State remains present after a controlled container restart, and no mounted directory reports an ownership error.

If logs mention suspicious ownership or EACCES, fix the host mount ownership for the container user. Do not disable the ownership check simply to make the warning disappear.