/home/node/.openclaw
像家里的文件柜。配置、token、账号资料都应该放这里，并挂到宿主机卷上。
Install 导读
Docker VM 安装：哪些东西重启会丢，哪些不会
本页是 GCP、Hetzner 等 VPS 上 Docker 部署的共享步骤。先看“Bake required binaries into the image”——所有技能依赖的外部二进制（如 gog、wacli）必须在构建镜像时安装，运行时安装会在容器重启后丢失。最容易搞错的是“What persists where”表格：配置、认证、工作区等通过宿主机卷挂载持久化，而二进制和运行时文件只存在于镜像中，重启后必须重新构建。
先讲这一页到底在解决什么
Docker VM 安装：哪些东西重启会丢，哪些不会
本页是 GCP、Hetzner 等 VPS 上 Docker 部署的共享步骤。先看“Bake required binaries into the image”——所有技能依赖的外部二进制（如 gog、wacli）必须在构建镜像时安装，运行时安装会在容器重启后丢失。最容易搞错的是“What persists where”表格：配置、认证、工作区等通过宿主机卷挂载持久化，而二进制和运行时文件只存在于镜像中，重启后必须重新构建。
第一站
🔧 先把这件事想成“工具要在出门前装进车里”
官方开头非常直白：不要把必须的二进制工具放到运行时再装。因为那样重启一次就容易忘。
🚫 运行中再装，是个坑
像你路上才想起要去买轮子。车已经开了，装不进去，还可能一重启就没了。
🏗 要在 build 阶段装
像先把工具放进车厢，再让车上路。这样以后重启，工具还在。
🧰 三个例子
gog、goplaces、wacli 只是三个样本。官方意思是：凡是 skills 需要的外部工具，都该用同样方式提前 bake 进去。
⭐ 先记一句
必须的工具，别放到运行时补；要在镜像构建时就焊好。
第二站
🍳 示例 Dockerfile，其实是在讲“先把厨房备齐，再开始做饭”
官方给的 Dockerfile 并不是要你死记，而是想让你看到一个稳定顺序：先装基础工具，再装外部二进制，再装依赖，最后才 build 整个项目。
FROM node:24-bookworm像先选一辆底盘合适的车。整个箱子得有一个稳定起点。
apt-get install -y socat像先把常用小扳手放进工具箱。
curl ... | tar -xz -C /usr/local/bin像把外部 CLI 直接搬进车厢里的固定工具位。
pnpm install --frozen-lockfile像按着锁定的菜单准备材料。锁文件不变，就不要随便乱换菜谱。
第三站
🚚 Build and launch，就是“先装好，再把车开出去”
这一段最朴素，也最重要。官方就是想让你把镜像 build 出来，然后把网关容器跑起来。
docker compose build像先把整辆车组装完，确认轮子、引擎、座椅都在。
docker compose up -d openclaw-gateway像把车推到路上，让 OpenClaw 真正开始上班。
🧠 为什么会提 137
如果构建时被杀掉、退出码 137，通常不是命令写错，而是 VM 内存太小，像车还没开出去就先卡死了。
🔎 怎么确认真的跑起来
官方让你看 which gog 这类命令，意思就是先确认工具到底有没有被装进车里，再看 gateway 日志里有没有“我正在听”的那句。
第四站
💾 持久化这一块，讲的是“车里的抽屉和后备箱要固定住”
Docker 版最容易误会的地方，是以为容器就是家。其实容器更像车，真正应该留下来的东西，要挂到稳定的卷上。
/home/node/.openclaw/workspace
像工作台。代码和临时产物都应该留在这里，不要塞进易失的容器层里。
镜像里放什么
Node 运行时、系统包、外部 binaries 这些，像焊在车身上的零件。要改，就得重建镜像。
容器里放什么
容器本身是会换的。真正不能丢的，是那些挂到卷里的长久状态。
第五站
🧾 表格那一页，其实是在帮你分清“谁住车里，谁住仓库”
官方用一张表把持久化说得很明白。你只要记住：有些东西要跟着卷走，有些东西只存在于镜像里。
📁 Host volume mount
像把抽屉固定在车外。配置、模型账号、workspace、session 数据都属于这类。
🧱 Docker image
像车体本身。系统包、Node runtime、外部 binary 都应该 bake 进去，而不是每次上路前再去买。
🪵 容易长胖的地方
media、日志、workspace 这些地方会慢慢堆东西。官方特地提醒你，是怕磁盘悄悄被吃满。
🎈 这节一句话
长期状态挂卷，短期运行放镜像。
第六站
🔁 更新的时候，别只想着“拉代码”，还要想“重建车身”
这页最后的更新部分也很朴素：你不是只改源码，还要让 Docker 重新把车装一遍。
git pull像先把最新的设计图拿回来。
docker compose build像按新设计图重新造一遍车身。
docker compose up -d像把重建好的车重新开上路。
📌 为什么这一步很重要
因为 VM 里的 Docker 不是“改了文件就自动变新”。你得明确让镜像和容器跟上更新。
最后总结
🎈 把 Docker VM Runtime 压成一句话
这页就是在教你：在云主机上的 Docker 里，哪些东西必须提前焊进镜像，哪些状态必须挂到卷上，才能让 OpenClaw 重启后还认得自己。
如果你下一页只想继续看一页，我建议看 /install/fly 或 /install/hetzner 这种真正部署页。因为这页讲的是 VM 里的通用规则，不是某一家云厂商的按钮。