How to Deploy OpenClaw with ClawDock

ClawDock is a shell-helper layer for Docker-based OpenClaw installs. It does not replace Docker; it gives operators shorter commands for the common day-to-day tasks that otherwise require longer Docker Compose invocations.

30-second answer

Use ClawDock when you run OpenClaw with Docker often and want quick helpers for start, stop, restart, status, logs, shell access, CLI commands, dashboard access, token repair, and device pairing. If Docker is not already set up, start with the official Docker install docs first.

Install helpers

mkdir -p ~/.clawdock && curl -sL https://raw.githubusercontent.com/openclaw/openclaw/main/scripts/clawdock/clawdock-helpers.sh -o ~/.clawdock/clawdock-helpers.sh
echo 'source ~/.clawdock/clawdock-helpers.sh' >> ~/.zshrc && source ~/.zshrc

The docs call this the canonical helper path. If you previously installed from the old shell-helpers path, reinstall from scripts/clawdock/clawdock-helpers.sh because the old raw GitHub path was removed.

Daily operations

The basic helpers are clawdock-start, clawdock-stop, clawdock-restart, clawdock-status, and clawdock-logs. Container access helpers include clawdock-shell, clawdock-cli <command>, and clawdock-exec <command>.

First-time flow

clawdock-start
clawdock-fix-token
clawdock-dashboard
clawdock-devices
clawdock-approve <request-id>

That flow starts the Gateway, fixes token wiring, opens the Control UI, lists pending device pairings, and approves a request. It is useful when setting up a Docker host that will be managed by a less technical operator later.

Config and secrets

The docs split state across clear files. Docker-specific values such as image name, ports, and gateway token live in the project .env. Provider keys and bot tokens live in ~/.openclaw/.env. Stored provider OAuth or API-key auth lives under the agent auth profiles path. Behavior config lives in ~/.openclaw/openclaw.json.

When to choose ClawDock

Choose ClawDock when Docker is the deployment shape and operators need reliable commands more than raw Compose flexibility. For larger hardened server installs, compare it with the Ansible path. For development, a host install may be simpler.

The OpenClaw Playbook recommends ClawDock for small Docker deployments where the biggest risk is not Docker itself but messy day-two operations: forgotten tokens, unknown container status, and operators who do not know which command to run.

Rollout plan

Treat How to Deploy OpenClaw with ClawDock as a workflow you roll out in stages, not a switch you flip once. Start with the smallest harmless proof: a status check, dry run, local-only call, private session, or read-only inspection. Confirm the documented behavior matches your installed OpenClaw version, then write the exact commands and expected output into the workspace so the next agent does not rely on memory or vibes.

For a production runbook, document installation state, service ownership, update cadence, rollback command, and the exact machine that owns the Gateway. Also write down what the agent may do alone, what requires approval, and what must stop immediately. That boundary is the difference between useful autonomy and a workflow that surprises the operator at the worst possible time.

Keep one rollback note beside the guide. It can be as simple as the command to disable a plugin, the channel to pause, the config key to revert, or the owner who must approve the next run. Include the proof that tells you rollback worked, and keep it visible near the production checklist for future maintainers. Agents are most useful when recovery is obvious.

After the first live run, review the transcript or logs while the details are fresh. Look for missing prerequisites, stale assumptions, broad prompts, confusing errors, and any external side effect that should have been gated. Tighten the guide, then repeat with one wider scope. The OpenClaw Playbook is built around this operating rhythm: cautious first proof, written runbook, verified automation, then gradual autonomy once the evidence is boring.