Back to Index
OpenClaw /

部署方案详解

Docker、Podman、Remote Gateway、Tailscale、Nix 与云部署完整指南

18 min read Part of OpenClaw 龙虾篇 · Ch. 7
← 上一层级：学习路径 · Part 04 · OpenClaw 实战

🦞 从本地安装到云端部署，从 Docker 到 Tailscale——部署不是“把服务跑起来”这么简单，而是要在可达性、隔离性、维护成本与安全边界之间做选择。

部署方案详解

flowchart LR
  A["部署方案详解"]
  A --> B["分类：OpenClaw"]
  A --> C["关键词：OpenClaw"]
  A --> D["关键词：部署"]
  A --> E["关键词：Docker"]
  A --> F["关键词：Tailscale"]

前文介绍了 OpenClaw 的工具与自动化能力。到了真正落地时，问题会立刻变得更工程化：Gateway 应该跑在哪台机器上？是放在本机、家里的常开设备、VPS，还是容器里？客户端如何连？认证怎么做？浏览器控制、移动节点、远程会话这些能力，又应该如何分布在不同机器上？

这篇文章不只是罗列安装方式，而是把 OpenClaw 常见部署路径放到同一张“架构图”里看。你读完之后，应该能回答三个实际问题：

  1. 我的 Gateway 最适合跑在哪儿
  2. 我应该如何把它安全地暴露给别的设备
  3. 当我从“自己用”走向“长期运行”时，需要补哪些工程护栏

先建立一个部署心智模型

在进入具体方案之前，先明确 OpenClaw 的一个核心事实：Gateway 是常驻控制平面。

它通常以一个长期运行的进程存在，负责持有状态、消息连接、控制接口与事件平面；客户端、WebChat、移动节点以及部分工具调用，都围绕它来组织。当前 Gateway 默认绑定在本机 loopback 端口（默认 18789），并通过同一个端口同时承载 WebSocket 控制面与 HTTP 路由，而不是再拆成一个独立的“聊天 UI 端口”。(OpenClaw)

这意味着，部署 OpenClaw 时真正的决策不是“装在哪”，而是下面这三个更本质的问题：

  • 状态归属在哪台机器：哪台机器持有配置、会话、工作区与长期运行的 Agent
  • 访问路径如何建立：本机直连、SSH 隧道、Tailscale tailnet、还是公网入口
  • 能力如何分布：Gateway 在哪里，节点设备在哪里，浏览器控制在哪台机器执行

一旦这三个问题想清楚，Docker、Podman、Tailscale、Nix、云部署都只是实现手段。

本地安装：最快起步，但也是理解系统的最佳入口

如果你只是想先跑起来，最直接的方式仍然是本地安装。官方当前推荐的整体安装路径其实是安装脚本；如果你已经自行管理 Node，则也可以直接使用 npm/pnpm 全局安装。官方当前建议 Node 24，兼容支持 Node 22 LTS；在 macOS、Linux 与 WSL2 上都可用。(OpenClaw)

npm install -g openclaw@latest
openclaw onboard --install-daemon

如果你走脚本安装，等价思路是：

curl -fsSL https://openclaw.ai/install.sh | bash

本地安装的优势不是“简单”，而是反馈快：

  • 配置文件、日志、工作区都在自己可见的环境里
  • 排错路径最短，适合先理解 Gateway、认证、频道、节点这些概念
  • 对于单用户、单设备、低风险场景，本地安装通常已经足够

但它也有明显边界：

  • 你的笔记本休眠时，Gateway 就不在线
  • 你换设备时，需要重新考虑远程连接和认证
  • 如果后续要接移动节点、远程控制或云端常驻，部署形态往往还会演进

所以更准确地说，本地安装适合的是学习期、实验期、个人轻量使用；它不是“低级方案”，只是通常不是长期架构的终点。

首次配置与日常维护：不要把“能启动”误认为“可运维”

安装之后，通常会先运行：

openclaw onboard

或者在首次安装时直接：

openclaw onboard --install-daemon

onboard 不只是一个新手向导，它实际上也会把一些关键的运行前提串起来，包括 Gateway 认证、服务安装等。文档也明确提到，在 --install-daemon 场景下，和令牌相关的配置会被额外校验，以避免把敏感信息用不合适的方式持久化。(OpenClaw)

后续维护中，最值得养成习惯的两个命令是：

openclaw doctor
openclaw gateway status

以及升级后的：

openclaw update
openclaw doctor
openclaw gateway restart

其中 doctor 的价值，不在于“检查一下有没有问题”，而在于它承担了配置迁移、风险提示、服务状态校验等“安全更新”角色。OpenClaw 当前仍处于快速演进阶段，官方也明确建议把更新当作一条完整流程：更新 → 检查 → 重启 → 验证，而不是单纯执行一次包升级。(OpenClaw)

Gateway 守护进程：把“命令行工具”变成“长期在线系统”

对大多数实际使用场景来说，OpenClaw 不应该只是你打开终端时才跑的一个前台进程。更合适的做法，是把 Gateway 作为系统托管服务长期运行。

openclaw onboard --install-daemon

或者显式安装服务：

openclaw gateway install

在 macOS 上，它会以每用户的 launchd LaunchAgent 形式运行；在 Linux 上，则是 systemd user service。官方文档也提到，macOS 配套应用本身不再捆绑 Gateway 运行时，而是连接或管理一个外部安装的 CLI 与其 launchd 服务。(OpenClaw)

这一步看起来只是“开机自启”，但它背后的工程意义很大：

  • 生命周期交给系统管理器：异常退出后更容易被拉起
  • 日志与状态更可预期：排障路径更稳定
  • 客户端可以把 Gateway 视为稳定依赖：而不是假设“用户当前开着一个终端窗口”

这里一个常见误区是：很多人会先用 openclaw gateway 前台跑着，觉得没问题，就长期维持这种状态。短期可以，长期通常不划算。因为一旦你要做远程访问、自动恢复、版本更新、日志检查，前台进程会显著提高运维摩擦。

部署选择的分界线：你到底是在部署“本地控制台”，还是“远程中枢”

可以用一个简单的判断方法来选部署方向：

适合本机常驻的情况

  • 你主要在一台电脑上使用
  • 不要求 24/7 在线
  • 更重视本地浏览器/文件/桌面能力
  • 还在探索配置与工作流

适合远程中枢的情况

  • 你希望 Agent 长时间在线
  • 你会从手机、平板、另一台电脑访问
  • 你有家庭服务器、NAS、树莓派或 VPS
  • 你希望把“运行状态”和“使用终端”分离

一旦进入第二类，Remote Gateway 架构通常会比单纯“在本机装个 App”更合理。

Remote Gateway：把状态放到一台常在线机器上

Remote Gateway 的核心思想并不复杂：让一台专用主机持有 Gateway 的状态与控制平面，其他客户端通过网络连接到它。

官方文档对这一点说得很清楚：远程使用的基本模型，是在一台专用主机上运行单个 Gateway，让客户端和节点连接到它；对于操作员设备，SSH 隧道是通用回退方案，而在更顺滑的场景中，推荐使用 Tailscale 或其他 tailnet/VPN。(OpenClaw)

可以把这个架构理解成：

组件典型运行位置主要职责
Gateway家庭服务器 / VPS / 树莓派 / 常开桌面持有状态、消息连接、控制平面
客户端macOS App / WebChat / CLI连接 Gateway，进行交互与控制
节点（iOS/Android 等）各自设备本地提供外围能力，被 Gateway 调用
浏览器控制可在 Gateway 主机或另一台节点主机承担浏览器相关操作

这里最重要的一点是：Gateway 是“系统大脑”，节点是外围执行体。节点并不取代 Gateway，也不应该被误解成“每台设备都跑一个完整 OpenClaw”。

这种架构为什么更适合长期运行

因为它把两个天然冲突的诉求拆开了：

  • 稳定性：交给常在线设备
  • 交互性：交给你手上的各种客户端

你的手机、笔记本、平板都可以断断续续上线；而 Gateway 持续运行，不需要跟随某一台操作终端的开关机状态。

这种架构的代价是什么

代价主要不是“更难部署”，而是网络、认证和能力边界需要更清楚：

  • 远程访问必须明确走 SSH、tailnet 或其他受控路径
  • 非 loopback 绑定必须有认证护栏
  • 设备能力不再默认“都在一台机器上”，你要知道某个动作到底在哪台机器执行

也正因为如此，Remote Gateway 是“更成熟”的部署方式，但不是“更省心”的前期方案。

SSH 隧道：最保守、也最可靠的远程接入方式

如果你不想一上来就引入 Tailscale，那么 SSH 隧道是最稳妥的起点。

官方文档当前给出的典型方式是把远程主机上的 Gateway loopback 端口转发到本地：

ssh -N -L 18789:127.0.0.1:18789 user@host

然后本地客户端通过 ws://127.0.0.1:18789 连接远程 Gateway。(OpenClaw)

这种方式的优点很明确：

  • 不需要把 Gateway 直接暴露到公网
  • 不需要额外引入公开入口
  • 安全边界相对清晰：远程端仍然只监听 loopback
  • 适合作为“远程访问的保底方案”

它的缺点也同样明显：

  • 使用体验更偏工程化，需要先建隧道
  • 多设备访问时，运维动作会变多
  • 不如 tailnet 方案自然，尤其在移动设备场景下

因此，SSH 隧道更像一个最小可信远程通路。在很多环境里，它不是最终形态，但几乎总是一个值得保留的回退路径。

Tailscale：让远程访问从“打洞”变成“同一内网”

如果你的目标是“多设备都能顺畅访问同一个 Gateway”，那么 Tailscale 往往是比 SSH 更接近生产体验的方案。

OpenClaw 当前对 Tailscale 的支持并不只是“你自己装个 VPN 就行”，而是支持围绕 Gateway 自动配置 tailscale serve 与 tailscale funnel。文档明确指出，这两种模式都允许 Gateway 继续绑定在 loopback，由 Tailscale 提供 HTTPS、路由，以及在 serve 模式下的身份头。(OpenClaw)

三种模式分别代表什么

模式含义适用场景
off不做 Tailscale 暴露完全本地，或改走 SSH / 自己的网络层
serve仅在 tailnet 内通过 HTTPS 暴露个人多设备、团队内网式访问
funnel通过公网 HTTPS 暴露必须从公网直接接入，但仍想利用 Tailscale 自动化

示例配置：

{
  "gateway": {
    "bind": "loopback",
    "tailscale": {
      "mode": "serve"
    }
  }
}

为什么官方强调 loopback

这是一个非常重要的安全边界。使用 serve 或 funnel 时，推荐保持 Gateway 绑定在 loopback，由 Tailscale 代理对外暴露，而不是自己直接监听公网或局域网端口。这样做的本质是把“应用监听地址”和“外部可达路径”解耦：应用继续保守，网络入口交给专门的网络层。(OpenClaw)

这类设计的好处在于：

  • 少犯“服务一不小心绑定 0.0.0.0”的错误
  • 认证和可达性更集中地放在 Tailscale 侧管理
  • 远程排错时，问题边界更清楚：是 Gateway 配置问题，还是 tailnet 暴露问题

serve 不只是“内网访问”，它还牵涉认证语义

原始理解常常是：

  • serve = 内网
  • funnel = 公网

这个理解没错，但不够完整。对 OpenClaw 来说，serve 模式下还可以利用 Tailscale 注入的 identity headers 做身份判断；当 gateway.auth.allowTailscale 启用时，合法的 Serve 代理请求可以借此完成认证，而不一定需要显式再提供 token/password。OpenClaw 会结合本机的 Tailscale 守护进程信息去校验这些头，而不是盲目信任它们。(OpenClaw)

这意味着：

  • serve 模式体验更顺滑，但你要理解它是在利用 tailnet 身份体系
  • 如果你想强制所有客户端都显式提供凭证，可以关闭相关允许项或改用更严格的认证模式
  • “在 tailnet 内”不等于“不需要认证设计”，只是认证方式可以更自然

funnel 真正危险的地方，不是“它是公网”，而是“你可能误以为它跟 serve 差不多”

OpenClaw 文档明确要求：当 tailscale.mode = "funnel" 时，如果没有配置 password 认证，将拒绝启动，以避免把 Gateway 公开暴露出去。(OpenClaw)

这背后反映的是一个更普遍的工程原则：

当入口从私有网络转向公网时，安全模型必须显式升级，而不是沿用内网默认值。

所以如果你只是个人多设备访问，serve 几乎总是优先于 funnel。funnel 更像一种有明确需求才启用的能力，而不是“更高级的 Tailscale”。

直接绑定 tailnet / LAN：能用，但通常不是首选默认值

除了 serve / funnel，OpenClaw 也支持直接绑定到 tailnet 等非 loopback 地址。文档提到，这类非 loopback 绑定必须带认证护栏，否则会被安全机制阻止启动。(OpenClaw)

这种方式不是不能用，而是你要清楚自己在交换什么：

  • 优点：路径更直接，没有额外代理层
  • 缺点：你自己承担监听地址暴露、认证配置、网络边界管理

对绝大多数用户而言，loopback + SSH/Tailscale Serve 是更稳妥的默认值。直接绑定到 tailnet/LAN，更适合那些已经明确知道自己为什么要这么做的人。

Docker：适合把运行环境“收口”，但不要误以为容器自动解决一切

OpenClaw 提供了完整的 Docker 路径，包括仓库内的 docker-compose.yml、docker-setup.sh，以及一套不同侧重点的 Dockerfile。官方文档也明确建议从仓库根目录运行 compose，并围绕 docker-setup.sh 生成额外的 compose 覆盖文件。(OpenClaw)

典型启动方式可以是：

./docker-setup.sh
docker compose up -d

或者先进入一次 CLI 容器完成配置：

docker compose run --rm openclaw-cli onboard
docker compose up -d openclaw-gateway

Docker 真正解决的是什么

很多人说“Docker 更适合部署”，但这个说法太宽泛。对 OpenClaw 而言，Docker 主要解决的是三件事：

  1. 运行时一致性 Node、依赖、系统包、浏览器环境等更容易固定下来。

  2. 环境隔离 特别是在你希望把 Agent 执行环境与宿主机隔开时，容器是自然手段。

  3. 可复制性 从 NAS 到 VPS，再到另一台服务器，迁移路径更清楚。

这对于长期运行、多人协作、或者你不想让宿主机被一堆依赖污染的场景非常有价值。

Docker 并不会自动帮你解决的事

它不会自动解决：

  • 认证设计
  • 网络暴露策略
  • 持久化与权限问题
  • 浏览器/系统依赖的完整性
  • 宿主机与容器之间文件能力的边界

这也是为什么，很多“容器化之后更稳定”的预期，在实践里会变成“容器里也能跑，但调起来更绕”。

OpenClaw 的 Docker 细节比“一个镜像”更讲究

文档里提到，官方镜像默认更偏安全优先：以非 root 的 node 用户运行，尽量缩小攻击面。这种默认设置意味着一些东西不会天然可用，例如运行时安装系统包、Homebrew、预装的浏览器能力等。对于更“功能完整”的容器，需要显式选择加入额外挂载、持久化 /home/node、或在构建期加入额外 apt 依赖。(OpenClaw)

这类设计很典型，也很值得注意：

  • 安全优先镜像 更适合长期运行
  • 功能完整镜像 更适合需要更多工具链、浏览器缓存、系统依赖的场景

两者没有绝对优劣，关键看你是在优化攻击面，还是优化能力完整度与使用便利性。

Docker 下最常见的失败模式

1. 权限问题

官方文档明确提示，镜像默认以 uid 1000 的 node 用户运行；如果你把宿主机目录挂载进来，而权限不匹配，就很容易出现 EACCES。(OpenClaw)

这类问题常被误判成“OpenClaw 配置坏了”，其实本质是宿主机文件系统权限与容器用户不一致。

2. 误以为容器重建后状态还在

如果没有正确挂载配置目录、工作区或命名卷，容器删掉重建之后，浏览器缓存、下载内容、某些持久状态就可能一起消失。官方也给出了 OPENCLAW_HOME_VOLUME、额外挂载等机制来处理这个问题。(OpenClaw)

3. 把“隔离”理解成“万能沙箱”

容器能提供边界，但并不代表你就获得了严格的多租户安全隔离。尤其在浏览器控制、挂载主机目录、加入更多系统包之后，容器的边界会逐渐变得更“工程方便”而不是更“绝对安全”。

所以更准确的说法是：Docker 适合做运行环境治理，不等于自动带来完美安全模型。

Sandbox 容器：隔离的价值在于缩小爆炸半径

如果你需要让某些 Agent 运行在更隔离的环境中，容器化最大的价值并不只是“方便部署”，而是把失败和风险收束到一个可控边界里。

原文提到 agents.defaults.sandbox.mode: "non-main" 这样的策略，这个方向是合理的：让非主会话、非核心路径在容器里执行，尽量避免把所有能力都直接暴露在宿主环境上。

这种设计适合以下场景：

  • 你会让 Agent 处理不完全可信的输入
  • 你希望把工具执行与主控制面隔开
  • 你想降低“误操作波及主机环境”的概率

但要记住，隔离往往会换来三类代价：

  • 文件共享与结果回传更复杂
  • 浏览器、系统工具、缓存等能力需要额外配置
  • 排障链路更长，因为你多了一层容器边界

因此，隔离越强，默认体验通常越差；默认体验越顺，隔离通常越弱。这是部署里最典型的 trade-off 之一。

Podman：不是“Docker 的替身”，而是另一种偏好与约束的组合

如果你偏好 rootless 容器，或者所在环境没有 Docker，Podman 是一条很自然的路线。OpenClaw 官方文档提供了专门的 Podman 页面，并说明它会使用与 Docker 相同的镜像基础；同时也提供相应的 setup 脚本与 rootless 运行路径。(OpenClaw)

Podman 的价值主要体现在：

  • 更偏 rootless 的运行模型
  • 在某些 Linux 环境中更符合系统原生哲学
  • 不依赖 Docker daemon 的使用习惯

但这并不代表它天然“更先进”。它更像是另一组权衡：

  • 你可能获得更好的 rootless 体验
  • 同时也可能在某些 compose 兼容性、团队共识、已有运维脚本上付出迁移成本

如果你已经深度依赖 Docker 生态，强行改 Podman 未必划算；反过来，如果你的主机环境天然偏 Podman，继续沿着官方提供的 Podman 路径走就很好，不必为了“主流”再引入 Docker。

云部署：把 Gateway 放到一直在线的地方，但不要把它变成“裸奔公网服务”

OpenClaw 当前提供了 Fly.io 与 Render 的官方部署文档与配置入口，说明云部署已是被正式考虑的使用方式，而不是社区旁门左道。Render 侧也明确采用 render.yaml Blueprint 方式组织服务与基础设施。(OpenClaw)

云部署的真正价值在于“常在线”：

  • 你的笔记本睡眠不影响 Gateway
  • 你可以从多台设备访问同一个中枢
  • 节点、客户端、自动化流程都更容易围绕一个固定入口组织

但云部署最容易犯的错误是：把“上云”理解成“直接开公网端口”。

官方安装文档对 VPS/云主机的建议其实相当克制：优先使用干净的基础 OS 镜像，再用官方安装方式部署，而不是依赖第三方“一键市场镜像”。(OpenClaw)

这背后其实有两个信号：

  1. OpenClaw 更适合部署在你能理解和控制的主机上
  2. “一键跑起来”不等于“你知道它现在暴露了什么”

云部署时更稳妥的默认形态

如果你要在云上长期运行，一个更稳妥的默认组合通常是：

  • Gateway 继续绑定 loopback
  • 认证启用 token 或 password
  • 外部访问走 Tailscale serve 或 SSH
  • 把公网暴露视为最后一步，而不是第一步

这看起来没有“直接公网访问”那么方便，但在长期维护里，通常会更省心。因为你真正减少的，不是配置项，而是未来可能发生的安全事故和排障复杂度。

Nix：当你想管理的不是“一个程序”，而是“一套可重复环境”

如果你已经进入 Nix 生态，那么 OpenClaw 也提供了 Nix 路径。官方当前推荐使用 nix-openclaw，并以 Home Manager 模块的方式进行声明式管理，而不是仅仅给一个零散的安装命令。(OpenClaw)

Nix 的价值，不在于“换一种包管理器”，而在于它改变了你对部署的抽象：

  • 你管理的不是一次安装，而是一份可重建的环境声明
  • 你追求的不是“当前机器能跑”，而是“下一台机器按同样定义也能跑”
  • 你更容易把 OpenClaw 纳入个人工作站或服务器的整体配置管理中

这对以下人群特别有吸引力：

  • 已经用 Home Manager / nix-darwin / NixOS 管理系统
  • 非常重视环境可重现性
  • 想把工作站、服务器、自动化环境统一到一套声明式配置里

但 Nix 也有它的门槛：它优化的是长期一致性，而不是第一次上手体验。如果你还没进入 Nix 生态，仅仅为了部署 OpenClaw 而引入 Nix，往往不是成本最低的选择。

不同部署方式，分别适合谁

可以把前面的讨论压缩成一张更实用的决策表：

方案最适合的人核心优点主要代价
本地安装 + 守护进程个人用户、刚开始使用上手快、排障短、体验直接依赖本机在线
Remote Gateway + SSH想远程但优先保守安全边界清晰、实现简单、可靠使用体验偏工程化
Remote Gateway + Tailscale Serve多设备个人使用的优先解体验顺滑、保持 loopback、安全性较好需要引入 tailnet
Docker想收口运行环境、长期运行一致性强、便于迁移与隔离权限/持久化/调试更复杂
Podman偏好 rootless 或无 Docker 环境更贴近 rootless 哲学团队与工具链兼容性需评估
云部署需要 24/7 在线常在线、跨设备访问方便网络与认证设计更重要
Nix已在 Nix 生态内的用户声明式、可复现、适合长期管理学习门槛高

一个更实用的推荐路径

如果你不想一开始就被选项淹没，可以按下面的节奏演进：

阶段一：先在本地跑通

目标不是“永久使用本地”，而是先理解：

  • Gateway 是什么
  • 配置与认证如何工作
  • 日志和 doctor 怎么看
  • 你的实际使用场景需要哪些能力

阶段二：把 Gateway 变成受管理服务

哪怕还是跑在自己电脑上，也先让它进入 launchd / systemd 的管理之下。这样你会开始用“服务”的视角而不是“临时命令”的视角来理解它。

阶段三：如果你确实需要远程，再迁移到常在线主机

这时优先考虑：

  • loopback + SSH：最保守的远程方案
  • loopback + Tailscale Serve：多数个人用户最均衡的方案

阶段四：当环境治理成为问题时，再引入 Docker / Podman / Nix

容器化和声明式配置都很好，但它们更适合解决“长期维护”和“环境一致性”问题，而不是替代前期对系统行为的理解。

当前版本、更新频道与升级策略

OpenClaw 当前提供 stable、beta、dev 等更新频道，官方文档也明确支持通过 openclaw update --channel <channel> 切换或跟随不同发布轨道。当前 GitHub Releases 中可以看到 2026.3.13 这一稳定 app 版本基线，同时后续修正发布已经推进到 2026.3.23-2 一类版本命名。(GitHub)

openclaw update --channel stable
openclaw doctor
openclaw gateway restart

这里最值得强调的不是版本号本身，而是升级策略：

  • 稳定环境优先 stable
  • 想尽早试新特性再考虑 beta / dev
  • 每次升级后都跑 doctor
  • 服务化运行时，优先用 openclaw gateway restart 之类的受控方式重启，而不是直接杀进程 (OpenClaw)

这不是繁琐，而是在快速演进的软件里，把“升级”从一次性操作变成一条可重复流程。

最后：部署不是安装后的附属环节，而是系统设计的一部分

OpenClaw 这类系统的部署，真正决定体验的往往不是“命令是否正确”，而是你是否选对了部署重心。

如果你把它当作一个偶尔运行的本地工具，那么本地安装就足够。

如果你把它当作一个会被多设备访问、会长期保有状态、会持续调用节点与工具的中枢，那么你就需要把它按一个小型长期运行系统来设计：明确 Gateway 所在地、认证方式、远程路径、隔离边界和更新流程。

从这个角度看，Docker、Podman、Remote Gateway、Tailscale、Nix、云部署并不是彼此竞争的清单，而是你在不同阶段、不同约束下可选的一组工程策略。