OpenClaw Docker Deployment Security: Hardening Checklist • William OGOU Cybersecurity Blog

OpenClaw is a self-hosted gateway for AI agents. It can connect chat channels to a Control UI, sessions, skills, browser automation, files, and shell tools. Docker can reduce the blast radius of that runtime, but a default container is not a complete security boundary.

A prompt injection, malicious skill, stolen gateway token, or overly broad bind mount can still cause damage inside the permissions you provide. This guide explains how to harden an OpenClaw Docker deployment without confusing container isolation with authentication or authorization.

Important: This article is a security hardening guide, not a replacement for the current OpenClaw Docker documentation. OpenClaw and Docker change quickly. Verify image names, configuration keys, commands, and security behavior against the official documentation before deploying.

The short answer

A safer OpenClaw Docker deployment has these properties:

It uses a reviewed, versioned image from an official or controlled registry.
The gateway runs as a non-root user where supported, with no privileged mode.
The container has only the filesystem mounts, network paths, and credentials it needs.
The Control UI and Gateway are protected by strong authentication and are not directly exposed to the public Internet.
Agent tool execution is sandboxed and restricted separately from the gateway container.
CPU, memory, process, storage, logging, and restart behavior are bounded and monitored.
High-impact actions require approval, and untrusted messages, files, web pages, and skills are treated as data.

If you need remote access through Cloudflare, read OpenClaw on Cloudflare: Tunnel Deployment and Security Hardening. That article focuses on Cloudflare Workers, Sandboxes, Tunnel, Access, OAuth tokens, prompt injection, and exposed admin-panel response.

What Docker protects and what it does not

Docker uses namespaces and control groups to separate processes and limit resource consumption. Capabilities, seccomp, AppArmor, SELinux, read-only filesystems, and user namespaces can add more restrictions.

Those controls do not automatically protect the following:

A secret deliberately injected into the container.
A host directory deliberately mounted into the container.
A Docker socket that allows control of the host daemon.
A gateway port published to an untrusted network.
An account or chat channel that OpenClaw is allowed to control.
A skill, plugin, dependency, or tool that the agent is allowed to execute.
Data that a manipulated agent can read and send through an allowed network path.

The practical model is least privilege in layers: identity controls who can reach OpenClaw, OpenClaw policies control what the agent can request, and Docker limits the runtime environment if the agent or a dependency behaves unexpectedly.

Understand the two Docker boundaries

OpenClaw documentation describes two related but different deployment patterns:

1. The gateway container

The full OpenClaw Gateway runs in Docker. It owns configuration, sessions, channel connections, the Control UI, and the gateway process. The official Docker flow uses Docker Compose and a persistent state directory so configuration and authentication data survive container replacement.

The current official image runs as the node user with UID 1000. Bind-mounted directories must have compatible ownership, or the gateway may report permission errors. Do not switch to root merely to hide a mount or ownership problem; fix the host directory permissions instead.

2. The agent tool sandbox

OpenClaw can also run agent tools such as shell and file operations inside separate Docker sandbox containers while the Gateway remains in its own runtime. This is a different boundary from containerizing the Gateway.

The official sandbox defaults are intentionally restrictive: no network, a read-only root filesystem, dropped capabilities, temporary writable paths, and a non-root image user. Sandboxing is opt-in, so confirm the effective mode rather than assuming that running the Gateway in Docker automatically sandboxes every tool call.

A Gateway container that orchestrates Docker-backed agent sandboxes may need access to the Docker socket. That socket is a high-impact control interface. Never mount it into an agent tool sandbox or expose it to an untrusted process. Use it only when the deployment intentionally requires Docker-backed sandbox orchestration, and isolate the Gateway and host accordingly.

Use the official deployment path first

The official OpenClaw Docker guide recommends Docker Desktop or Docker Engine with Docker Compose v2. A source checkout can be initialized with the repository’s Docker setup script, while a controlled deployment may use an official image from GitHub Container Registry.

The exact commands change, but the security-relevant workflow is stable:

Review the current OpenClaw Docker documentation and release notes.
Choose an official image or build from a reviewed source checkout.
Record the source commit, image tag, digest, and build timestamp.
Run onboarding without installing a daemon inside the container.
Persist only the OpenClaw state and workspace directories you actually need.
Configure Gateway authentication and channel pairing before remote access.
Enable agent sandboxing for untrusted or non-main sessions.
Run the OpenClaw health checks and security audit before exposing the service.

For current installation details, see OpenClaw Docker installation, OpenClaw security, and the OpenClaw repository.

1. Control the image supply chain

An autonomous agent executes code from more than the OpenClaw package. The image includes an operating-system base, Node runtime, dependencies, plugins, browser components, and potentially skill or tool dependencies.

Use these controls:

Prefer ghcr.io/openclaw/openclaw or another registry you control. Avoid unofficial mirrors.
Do not deploy latest as an undocumented production dependency. Use a reviewed release tag and record its digest.
Deploy an immutable digest where your operational tooling supports it:

ghcr.io/openclaw/openclaw:<reviewed-tag>@sha256:<image-digest>

Review Dockerfile changes, lockfiles, plugin manifests, and build scripts before rebuilding.
Pin extra operating-system, Python, Node, and plugin dependencies to reviewed versions.
Scan images and dependencies for known vulnerabilities before release.
Generate and retain an SBOM and build provenance for images built in CI.
Test upgrades in a disposable environment before reusing production state.
Keep a rollback image and a tested restore procedure.

An image digest proves which image was selected. It does not prove that the image is safe, so provenance, source review, scanning, and controlled registry access still matter.

2. Do not run the agent as root

The official OpenClaw image uses a non-root node user. Preserve that default unless a documented requirement makes a different identity necessary.

On Linux hosts, consider Docker Rootless mode so both the Docker daemon and containers run without root privileges. Rootless mode has host prerequisites and operational trade-offs; test volume ownership, networking, device access, and resource limits before adopting it.

Avoid these shortcuts:

--privileged
--pid=host
--network=host
--ipc=host
Broad device access
Running the Docker daemon on an unauthenticated TCP socket
Granting the Docker group to untrusted operators

Docker documents that --privileged enables all capabilities, disables the default seccomp and AppArmor confinement, grants host device access, and can provide a path to host control. An agent container should not need it.

If an integration needs an elevated capability, identify the exact requirement and grant only that capability. Do not solve an application compatibility problem by giving the container full host privileges.

3. Restrict capabilities and privilege escalation

Start with the smallest capability set. For many agent workloads, dropping all capabilities is a reasonable target, although browser, networking, or device integrations may require careful exceptions.

Use the following principles:

Drop capabilities that the application does not explicitly require.
Set no-new-privileges so processes cannot gain additional privileges through set-user-ID binaries or similar paths.
Keep Docker’s default seccomp profile enabled unless compatibility testing proves a specific exception is required.
Use a custom seccomp profile only after measuring the required system calls.
Apply an AppArmor or SELinux profile on hosts that support it.
Do not use seccomp=unconfined or disable MAC confinement as a routine fix.

Docker’s default seccomp profile is an allowlist that blocks sensitive system calls. Treat a request to disable it as a security exception that requires review, documentation, and compensating controls.

4. Minimize filesystem mounts

The filesystem is often the most important OpenClaw boundary. Mount only the state, workspace, or data directories required for the workflow.

Never mount these paths into an agent runtime unless the risk is explicitly understood and the process is trusted:

/var/run/docker.sock or another Docker API socket
The host root filesystem
The entire home directory
~/.ssh
Cloud credential directories such as ~/.aws, ~/.config/gcloud, or ~/.kube
Password-manager, browser-profile, or personal application data
/proc, /sys, /dev, /etc, or unrestricted host paths

Use named volumes or explicit --mount entries instead of broad bind mounts. Prefer read-only mounts for reference data:

host-reference-directory:/reference:ro

Keep writable state separate from source and credentials. Back up the OpenClaw state directory as sensitive data because it can contain configuration, channel credentials, OAuth material, sessions, transcripts, and pairing records.

OpenClaw’s own sandbox bind validation blocks several system and credential paths by default. Do not weaken those checks simply to make a mount convenient.

5. Keep the Gateway off the public Internet

The default OpenClaw Gateway port is commonly 18789. A published Docker port can bypass assumptions made by a host firewall, and Docker may install forwarding rules that make the service reachable on more interfaces than expected.

Use the narrowest access pattern that meets the requirement:

Local use: keep the Gateway on loopback.
Private remote use: prefer SSH tunneling or Tailscale Serve.
Cloudflare remote use: keep the origin private and use a named Tunnel plus Cloudflare Access.
Organization access: use a correctly configured identity-aware reverse proxy with strict trusted-proxy settings.
Public exposure: treat it as exceptional and require TLS, identity-aware access, rate limits, allowlists, and sandboxed non-main sessions.

OpenClaw recommends avoiding direct public port forwarding. If Docker publishes a port, bind it only to the intended host interface and enforce the host’s Docker forwarding policy, including the DOCKER-USER chain where applicable.

Do not place gateway tokens in URLs, bookmarks, screenshots, analytics, referrer headers, or chat messages. Use HTTPS for remote Control UI access and verify the configured gateway.controlUi.allowedOrigins rather than using a wildcard outside tightly controlled testing.

6. Separate authentication from agent authorization

Docker networking does not authenticate a user, and a reverse proxy does not decide what the agent may do after login.

Configure OpenClaw with layered controls:

Use a long, random Gateway token or password.
Keep the Control UI behind the intended private access path.
Use device pairing for new browsers, CLIs, nodes, and channel devices.
Prefer channel DM pairing or strict allowlists over open inbound messages.
Require mentions and group allowlists where group chats are enabled.
Use session.dmScope: "per-channel-peer" when multiple people can message the agent.
Keep DEV_MODE, insecure authentication switches, and debug routes off in production.
Run openclaw security audit after configuration changes and before exposure.

A valid Gateway token is an operator-level credential. Do not treat it as a narrow per-user or per-tool permission. Protect it like a root-equivalent control-plane secret.

7. Enable agent sandboxing for untrusted work

If OpenClaw reads external content or serves more than one trusted operator, enable sandboxing for non-main or all sessions. A useful starting point is:

{
  agents: {
    defaults: {
      sandbox: {
        mode: "non-main",
        backend: "docker",
        scope: "agent",
        workspaceAccess: "ro",
        docker: {
          image: "openclaw-sandbox:bookworm-slim",
          network: "none",
          readOnlyRoot: true,
          capDrop: ["ALL"],
          tmpfs: ["/tmp", "/var/tmp", "/run"],
        },
      },
    },
  },
}

This is a baseline to test, not a universal drop-in configuration. A coding workflow may need a writable workspace; a browser workflow may need a dedicated browser container and controlled egress. Widen one permission at a time and verify the effective sandbox with OpenClaw’s diagnostics.

Remember the escape hatches:

tools.elevated can intentionally run commands outside the sandbox.
Native plugins run with the Gateway trust boundary.
Additional bind mounts bypass the sandbox filesystem view.
A Docker socket can control the host daemon.

Deny or approval-gate exec, browser, file-write, network, gateway, cron, node, and session-spawn tools for agents that process untrusted messages or documents.

8. Protect secrets and OAuth credentials

Do not put API keys, bot tokens, OAuth refresh tokens, or Gateway passwords in a Dockerfile, image layer, source repository, public .env file, command history, or logs.

For Docker Compose, use service-scoped secrets where supported. Compose mounts a granted secret at /run/secrets/<secret_name> and only services that list the secret receive it. This is preferable to placing every credential in environment variables, although the application must support the file-based delivery pattern.

For OpenClaw specifically:

Keep ~/.openclaw directories mode 700 and sensitive files mode 600.
Store provider and channel credentials in the Gateway’s intended secret or auth-profile mechanism.
Give each integration a separate, narrowly scoped credential.
Request the smallest useful OAuth scopes.
Keep refresh tokens out of transcripts and tool input.
Never give the agent the Docker API socket, cloud administrator token, personal SSH key, or unrestricted cloud credentials.
Rotate Gateway, provider, channel, OAuth, and CDP credentials after suspected exposure.

Docker environment variables can be visible through container metadata and may be inherited by processes. Choose a secret delivery method based on the threat model, and verify that application logs do not print secret values.

9. Control outbound network access

An agent that can reach every destination on the Internet can send data to destinations you did not intend and can download unreviewed code or skills.

Use a default-deny network for sandboxed tool execution where the workflow allows it. For the Gateway container, permit only the provider, channel, update, DNS, telemetry, and control-plane destinations the deployment requires.

Add controls at more than one layer:

Docker network selection and egress policy.
Host firewall and DOCKER-USER rules.
DNS filtering or an egress proxy.
OpenClaw browser SSRF policy and host allowlists.
Tool-level domain and command allowlists.
Alerts for unusual destinations, data volume, token spend, and channel activity.

Browser automation is especially sensitive. Use a dedicated browser profile with no personal sessions, password manager, or unrelated cookies. Keep CDP endpoints private and authenticate them with a separate secret.

10. Bound resources and improve observability

An agent can consume resources accidentally or after prompt injection. Docker control groups can limit memory, CPU, process count, and block I/O.

Set limits appropriate to the workload and test failure behavior:

Memory and swap limits.
CPU quota or CPU count.
Process count (pids-limit).
Writable disk or volume quotas where available.
File descriptor and process limits.
Request, command, browser, and tool timeouts.
A restart policy that does not hide a crash loop.
Health checks for liveness and readiness.
Log rotation, retention, redaction, and centralized alerting.

Monitor container restarts, OOM kills, image changes, published ports, Docker daemon access, outbound connections, OpenClaw audit findings, channel pairings, unusual tool calls, and provider spend.

A health check tells you whether a process responds. It does not prove that the Gateway is authenticated, correctly configured, or safe to expose.

A practical pre-production checklist

Image and host

The OpenClaw release, image digest, source commit, and build provenance are recorded.
The image and dependencies have been scanned, and an SBOM is retained.
Docker Engine, Docker Desktop, the host kernel, and security profiles are current.
Rootless Docker or user-namespace isolation has been evaluated.
The container is not privileged and does not share host PID, IPC, or network namespaces.
The container runs as the supported non-root user.

Runtime and filesystem

Capabilities are dropped to the minimum required set.
no-new-privileges and the default seccomp profile remain enabled.
AppArmor or SELinux is enabled where compatible.
The root filesystem is read-only where the application supports it.
Writable directories are explicit, narrow, and separately backed up.
No Docker socket, SSH key directory, cloud credential directory, browser profile, or host root is mounted.
The Gateway container and agent tool sandboxes have been reviewed as separate boundaries.

Access and agent policy

The Gateway is private, or every remote path has strong identity-aware access and TLS.
Published ports and Docker forwarding rules have been tested from an untrusted network.
Gateway authentication is enabled with a random secret.
Device pairing and channel allowlists are enabled.
DEV_MODE and unsafe debug or insecure-auth flags are disabled.
Non-main or untrusted sessions run in a sandbox.
High-impact tools are denied or require human approval.
Plugins and skills are reviewed, pinned, and explicitly allowlisted.

Secrets and operations

Provider, channel, OAuth, CDP, and cloud credentials are inventoried and scoped.
Secrets are not present in image layers, Git, URLs, logs, or chat transcripts.
Backups are encrypted, access-controlled, and tested for restoration.
openclaw doctor, openclaw security audit --deep, and openclaw health have been run.
Logs, spend, egress, pairings, restarts, and configuration changes are monitored.
A rollback and credential-rotation procedure is documented.

If the Docker deployment is exposed

Treat an exposed OpenClaw Gateway or Control UI as a potential security incident, not merely a firewall mistake.

Stop public routing and restrict the container to loopback or a private management path.
Stop the container if you cannot establish containment.
Rotate the Gateway token or password, provider keys, channel tokens, OAuth credentials, CDP secret, and any cloud credentials the agent could reach.
Remove unknown paired devices and channel sessions.
Preserve and review Docker, reverse-proxy, Gateway, channel, and host audit logs.
Inspect transcripts, configuration, mounted state, installed plugins, skills, image history, and outbound connections.
Rebuild from a reviewed source and immutable image; do not restore untrusted configuration blindly.
Re-run the security audit and test unauthorized access, direct-origin access, pairing, tool approval, and egress controls.
Restore integrations one at a time while monitoring spend and network activity.

For a Cloudflare-hosted instance, follow the incident workflow in OpenClaw on Cloudflare: Tunnel Deployment and Security Hardening.

Final perspective

Docker is valuable because it gives you practical controls over process namespaces, resources, capabilities, filesystems, and networks. It is not a substitute for OpenClaw authentication, channel policy, tool authorization, human approval, or careful secret management.

The safest deployment is not the one with the most flags. It is the one whose trust boundaries are explicit, tested, monitored, and narrow enough that a manipulated agent cannot immediately reach your host, personal accounts, cloud control plane, or every connected conversation.

To further enhance your cloud security and implement AI Security Best Practices, contact me on LinkedIn Profile or [email protected].

Frequently Asked Questions (FAQ)

Is Docker enough to secure OpenClaw?

No. Docker reduces runtime blast radius, but you still need Gateway authentication, device pairing, channel allowlists, least-privilege tools, secret isolation, controlled egress, and human approval for high-impact actions.

Should OpenClaw run as root inside Docker?

Prefer the supported non-root user. The official OpenClaw image runs as the node user with UID 1000. Fix mount ownership and permissions instead of switching to root.

Can I mount the Docker socket into OpenClaw?

A Docker socket can control the host Docker daemon and is therefore a high-impact privilege. Do not expose it to agent tool sandboxes. Use it only when the Gateway intentionally needs to orchestrate Docker-backed sandboxes, and isolate that Gateway and host accordingly.

How do I expose OpenClaw remotely from Docker?

Prefer loopback plus SSH or Tailscale for personal access. For Cloudflare, keep the origin private and use a named Tunnel with Cloudflare Access. Avoid direct public port forwarding to the Gateway.

Does running the Gateway in Docker enable agent sandboxing?

No. Containerizing the Gateway and sandboxing agent tools are separate configurations. Enable and verify OpenClaw sandbox mode for non-main or untrusted sessions, then review tool policies and any elevated escape paths.

What should I do after an exposed OpenClaw container?

Contain it, rotate every reachable credential, remove unknown pairings, preserve logs, inspect state and outbound activity, rebuild from trusted sources, and test unauthorized access before restoring integrations.