ClawPanel + OpenClaw Gateway 一体化部署最终版（含微信插件与一键验收）

前言

这篇文章整理的是 2026 年 3 月 25 日当时那套 ClawPanel + OpenClaw Gateway 一体化部署方案，目标是把已经验证可用的一套 Docker Compose 部署方式固定下来，方便后续重建、迁移和复用。

当时重点关注的是：

• Gateway 容器重建后依赖容易丢失
• python3 缺失会影响微信插件链路稳定性
• OpenClaw CLI 每次启动时在线安装，速度慢且依赖网络
• ClawPanel 与 Gateway 需要继续共享同一份持久化数据
• 部署后需要一套一键验收手段

这篇旧文保留的就是当时那条发布思路本身。

↑ 返回目录

当前部署思路

建议将部署目录固定为 /opt/clawpanel-all-in-one/。

目录结构如下：

• Dockerfile.clawpanel
• Dockerfile.gateway
• docker-compose.yml
• verify-openclaw.sh
• README-weixin-fix.md

这套方案的核心设计思路是：

• clawpanel 与 gateway 分开构建镜像
• 两者继续共享同一个 openclaw-data 卷
• 在 gateway 镜像构建阶段直接安装 OpenClaw CLI
• 在 gateway 镜像中固化 python3、curl、ca-certificates
• 通过脚本一键验收微信插件与网关状态

↑ 返回目录

适用场景说明

• 已经具备 Docker / Docker Compose 运行环境
• 需要同时部署 ClawPanel 与 OpenClaw Gateway
• 希望保留 OpenClaw 的持久化数据、配置、插件状态与账号状态
• 需要继续使用 openclaw-weixin 微信插件
• 希望在后续重建、迁移或换机时减少重复手工补环境的操作

注意： 本文保留的是当时那版可运行方案，用于恢复旧文内容本身。

↑ 返回目录

最终版 Dockerfile.clawpanel

先看 ClawPanel 容器。它负责前台管理界面，本身要具备基础依赖，但它不是当时微信链路问题的主要病灶。

FROM node:22-slim

RUN apt-get update && apt-get install -y python3 git ca-certificates && rm -rf /var/lib/apt/lists/*

RUN npm install -g @qingchencloud/openclaw-zh --registry https://registry.npmmirror.com

WORKDIR /app

RUN git clone https://github.com/qingchencloud/clawpanel.git . && npm install

RUN npm run build

EXPOSE 1420

CMD ["npm", "run", "serve"]

这个容器主要用于 ClawPanel，本身已经具备 python3 等基础依赖，但真正需要重点固化的，是 gateway 这一侧的运行环境。

↑ 返回目录

最终版 Dockerfile.gateway

这一段是当时旧版方案里最关键的部分：把 OpenClaw CLI 和微信链路依赖固化到镜像层，尽量减少重建容器后的环境漂移。

FROM node:22-slim

ARG OPENCLAW_VERSION=latest

RUN apt-get update && apt-get install -y python3 curl ca-certificates && rm -rf /var/lib/apt/lists/*

RUN if [ "$OPENCLAW_VERSION" = "latest" ]; then npm install -g @qingchencloud/openclaw-zh --registry https://registry.npmmirror.com; else npm install -g @qingchencloud/openclaw-zh@"$OPENCLAW_VERSION" --registry https://registry.npmmirror.com; fi

WORKDIR /root

CMD ["sh", "-c", "openclaw init 2>/dev/null || true && openclaw gateway"]

这份 Dockerfile 的目的，是把微信插件相关关键依赖和 OpenClaw CLI 固化到镜像层，避免重建容器后重复手工补环境。

↑ 返回目录

最终版 docker-compose.yml

接下来是编排层。这里的重点不只是把两个容器跑起来，更重要的是保留它们共享同一份 OpenClaw 数据的结构。

version: "3.8"

services:
  gateway:
    build:
      context: .
      dockerfile: Dockerfile.gateway
      args:
        OPENCLAW_VERSION: "latest"
    container_name: openclaw-gateway
    restart: unless-stopped
    ports:
      - "18789:18789"
    volumes:
      - openclaw-data:/root/.openclaw
    healthcheck:
      test: ["CMD", "curl", "-fsS", "http://localhost:18789/health"]
      interval: 30s
      timeout: 5s
      retries: 5
      start_period: 40s

  clawpanel:
    build:
      context: .
      dockerfile: Dockerfile.clawpanel
    container_name: clawpanel
    restart: unless-stopped
    ports:
      - "1420:1420"
    volumes:
      - openclaw-data:/root/.openclaw
    environment:
      - NODE_ENV=production
    depends_on:
      gateway:
        condition: service_healthy

volumes:
  openclaw-data:
    name: openclaw-data

这份 Compose 的核心点有三个：

• gateway 改为本地 build，而不是直接裸跑 node:22-slim
• ClawPanel 与 Gateway 继续共享同一个 openclaw-data 卷
• 通过 depends_on + service_healthy 控制启动顺序

这里使用 restart: unless-stopped，是因为它既能自动恢复异常退出的容器，也能在人工停机排障时保持克制，不会刚停掉又自己爬起来。

↑ 返回目录

一键验收脚本 verify-openclaw.sh

部署后不要直接凭感觉判断是否成功，先跑验收脚本。这样能最快确认 Gateway、依赖和微信插件状态是不是都正常。

#!/usr/bin/env bash
set -euo pipefail

cd /opt/clawpanel-all-in-one

echo "==> [1/5] docker compose ps"
docker compose ps

echo
echo "==> [2/5] gateway python3 version"
docker compose exec -T gateway python3 --version

echo
echo "==> [3/5] gateway curl version"
docker compose exec -T gateway curl --version | head -n 1

echo
echo "==> [4/5] openclaw status (inside gateway container)"
STATUS_OUTPUT="$(docker compose exec -T gateway openclaw status || true)"
echo "$STATUS_OUTPUT"

echo
echo "==> [5/5] checks"

if ! echo "$STATUS_OUTPUT" | grep -q "State.*OK"; then
  echo "❌ Gateway 状态不是 OK"
  exit 1
fi

if ! echo "$STATUS_OUTPUT" | grep -q "openclaw-weixin.*ON"; then
  echo "❌ openclaw-weixin 未显示为 ON"
  exit 1
fi

if ! echo "$STATUS_OUTPUT" | grep -q "accounts.*1/1"; then
  echo "❌ 微信账号未显示为 1/1"
  exit 1
fi

echo "✅ 验收通过：Gateway / 微信插件 / 账号状态正常"

只要这一步通过，基本就说明旧版方案的核心链路已经跑起来了。

↑ 返回目录

使用方式

下面给出最直接的使用顺序。

初次部署或重建

cd /opt/clawpanel-all-in-one
docker compose up -d --build

部署完成后验收

cd /opt/clawpanel-all-in-one
chmod +x verify-openclaw.sh
./verify-openclaw.sh

如果只是普通重启

docker compose restart

↑ 返回目录

已知事项与现实边界

• Docker 重建时会同时准备好 OpenClaw CLI
• gateway 中的 python3 不会再因为容器重建而丢失
• curl 与证书链依赖已固化
• ClawPanel 与 Gateway 继续共享同一个 openclaw-data 卷
• 微信插件的关键前置条件更稳定
• 部署后可以通过脚本进行一键验收

当前微信链路存在一条 warning：loaded without install/load-path provenance。当时已确认它不影响实际使用，属于后续可再处理的规范化问题。

↑ 返回目录

总结

如果你的目标是：保留这套 3 月 25 日当时已经跑通的部署思路，并且在以后重建、迁移时继续复用，那么这篇旧文保留的就是那版方案本身。

cd /opt/clawpanel-all-in-one
docker compose up -d --build
./verify-openclaw.sh

这样就够直接，也够省心。

↑ 返回目录