$ ssh clawdbot.space --loading...
$ ssh clawdbot.space --loading...
Dockerコンテナ内でOpenClawを実行 — 初回pullから本番グレードのComposeスタックまで。
Dockerは本番環境でOpenClawをデプロイする推奨方法です。分離性、再現性、簡単なアップデートを提供します。このガイドでは、基本的なシングルコンテナ構成から、モニタリング、バックアップ、自動再起動を含む完全なマルチサービスComposeスタックまでを解説します。
docker pull ghcr.io/openclaw/openclaw:latest
mkdir -p ~/.openclaw && cd ~/.openclaw
docker run -d --name openclaw \ -p 127.0.0.1:18789:18789 \ -v ~/.openclaw:/app/data \ -e ANTHROPIC_API_KEY=sk-ant-xxx \ --restart unless-stopped \ ghcr.io/openclaw/openclaw:latest
docker logs -f openclaw
本番環境ではDocker Composeを使用し、リソース制限、ヘルスチェック、ログ管理を設定します。
version: "3.8"
services:
openclaw:
image: ghcr.io/openclaw/openclaw:latest
container_name: openclaw
restart: unless-stopped
ports:
- "127.0.0.1:18789:18789"
volumes:
- ./data:/app/data
- ./config:/app/config:ro
environment:
- ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
- OPENCLAW_TZ=Asia/Tokyo
- OPENCLAW_LOG_LEVEL=info
deploy:
resources:
limits:
memory: 4g
cpus: "2.0"
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:18789/health"]
interval: 30s
timeout: 10s
retries: 3
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"--read-onlyフラグを追加。一時ファイル用に/tmpをtmpfsでマウント。
--read-only --tmpfs /tmp:rw,noexec,nosuidコンテナに不要な全てのLinux権限を削除。
--cap-drop=ALLコンテナ内で非rootとして実行。
--user 1000:1000localhostのみにバインド。18789を0.0.0.0に公開しない。
-p 127.0.0.1:18789:18789/app/dataを必ずホストディレクトリにマウント。SOUL.md、メモリ、全エージェント状態を含みます。
:roフラグで設定ファイルをマウントし、エージェントの自己設定変更を防止。
docker cpまたはボリュームスナップショットを使用。cronで自動化：tar czf backup-$(date +%F).tar.gz ./data
ゲートウェイのコンテナ化は、どの状態をコンテナの外に置くかを決める作業がほとんどです。ここを誤ると症状は遅れて現れます。最初の再ビルドまではすべて動き、その時点でエージェントは自分が誰かを忘れます。
| ホストのパス | マウント先 | 省くと失われるもの |
|---|---|---|
| $HOME/.openclaw | /home/node/.openclaw | 設定とゲートウェイの状態。ペアリングも設定も再ビルドで消えます。 |
| $HOME/.openclaw/workspace | /home/node/.openclaw/workspace | エージェントの作業ファイルと、自作したスキル。 |
| $HOME/.openclaw-auth-profile-secrets | /home/node/.config/openclaw | リカバリキー。再生成できません。SSH秘密鍵と同じ扱いにしてください。 |
ドキュメントにある制約を1つそのまま引用します。誤りやすく、分かりにくい失敗を生むためです。ゲートウェイの状態は単一ファイルではなくディレクトリとしてマウントしてください。個別のJSONファイルをbind mountすると、何かがアトミックに書き換えるまでは動きますが、その後コンテナは古いinodeを掴んだままになり、編集内容が消えたように見えます。
リポジトリにcomposeファイルとセットアップスクリプトが同梱されているため、実際に必要な作業は自前のcompose定義を書くことではなく、その周辺の環境変数にあります。
# The three paths the container expects on the host: export OPENCLAW_CONFIG_DIR="$HOME/.openclaw" export OPENCLAW_WORKSPACE_DIR="$HOME/.openclaw/workspace" export OPENCLAW_AUTH_PROFILE_SECRET_DIR="$HOME/.openclaw-auth-profile-secrets" # Use the prebuilt image rather than building locally: export OPENCLAW_IMAGE="ghcr.io/openclaw/openclaw:latest" # lan is the normal setting; loopback restricts access further: export OPENCLAW_GATEWAY_BIND=lan
ローカルビルドの理由がなければビルド済みイメージを指定してください。ローカルビルドは本来ホストに不要なツールチェーンを引き込みます。`OPENCLAW_GATEWAY_BIND=lan` が通常値で、loopbackはより厳しく制限します。トンネル経由でのみ到達するならloopbackが妥当な既定値です。
./scripts/docker/setup.sh
これがサポートされた手順です。composeを自作することもできますが、その場合は上記のマウント仕様（ファイルかディレクトリかの罠を含む）を自分で引き受けることになります。
docker compose ps docker compose logs --tail=100 openclaw-gateway curl -fsS http://127.0.0.1:18789/healthz
`ps` はコンテナが起動していること、`logs` は起動が正常だったこと、healthzエンドポイントは実際にサービスを提供していることを示します。前2つを通過して3つ目で失敗することは実際にあり、それこそが「問題なさそうに見えて問題がある」状態です。
管理操作は、稼働中のコンテナにexecするのではなく、2つ目の短命コンテナ経由で行います。ゲートウェイのプロセスを乱さず、CLIとゲートウェイのバージョンも揃います。
docker compose run --rm openclaw-cli dashboard --no-open
ヘッドレスなホストでは `--no-open` が重要です。付けないとCLIが存在しないブラウザを起動しようとします。
docker compose run --rm openclaw-cli devices list docker compose run --rm openclaw-cli devices approve <requestId>
新しいデバイスはゲートウェイと通信する前に承認が必要です。心当たりのないリクエストが現れたなら、それは面倒ごとではなくセキュリティイベントです。
docker compose run --rm openclaw-cli doctor --json
ここでは `--json` を使う価値があります。コンテナのログは出力が交錯するため、構造化された出力の方がはるかに検索しやすくなります。
# Rebuilding without going through onboarding again: export OPENCLAW_SKIP_ONBOARDING=1 docker compose up -d --build
`OPENCLAW_SKIP_ONBOARDING=1` はウィザードの再実行と、その後カスタマイズした設定の上書きを防ぎます。このフラグは設定を一度失ってから知られることが多いものです。