多租户托管
如果你要给多个客户或多个组织托管 OpenClaw，最重要的问题不是“怎么省几台机器”，而是：
text
彼此不互信的租户，边界到底划在哪里？OpenClaw 当前更推荐的答案是：
text
一个租户一套独立实例，不要把完全不互信的租户塞进同一个共享 Gateway。为什么不能只靠一个共享 Gateway
很多人会天然觉得：
- 不同用户是不是可以只靠 session 隔离
- 工具沙箱是不是已经够安全
- 一个大 Gateway 会不会更省事
但这三件事都不等于真正的租户隔离。
Session 解决的是会话隔离，不是敌对租户隔离。 工具沙箱可以降低工具执行风险，但也不是完整租户授权边界。
如果多个租户彼此不互信，更稳妥的做法是每个租户单独跑一套 OpenClaw cell。
Fleet 是这条路线的核心
OpenClaw 用 openclaw fleet 来管理多租户 cell。
每个 cell 通常都有自己单独的：
- Gateway 进程
- 容器
- 状态目录
- 密钥和凭证
- 通道账号
- loopback 端口
这意味着一个租户出问题时，不会天然拖着其他租户共沉一艘船。
最应该记住的安全边界
租户之间要隔离
如果是不同客户、不同组织或不同信任域，默认就该隔离。
宿主机和运维方仍然是高权限
Fleet 不是“对宿主机也不信任”的方案。 托管方和主机管理员依然拥有高权限，这点要对客户讲清楚。
默认不要公网裸露
cell Gateway 默认发布到本机 loopback 是正确做法。 如果需要远程访问，优先走：
- Tailscale / VPN
- SSH 隧道
- 明确做了认证和来源限制的反向代理
哪些场景值得上多租户
适合：
- 代运维多个客户的 OpenClaw
- 同一台宿主机上承载多个不互信组织
- 希望按租户拆分状态、凭证和账单边界
不一定适合：
- 自己单机使用
- 只有一个可信团队在用
- 还没有容器、备份和恢复能力
运维视角最容易忽略的事
1. 数据目录和密钥目录要分清
状态目录和密钥目录都很重要，不要只备份对话数据却漏掉认证材料。
2. egress 策略不是自动就安全
即使租户隔离了，容器默认出站网络通常还是可用的。 如果你有更严格的网络边界要求，还得结合 Podman / Docker 和宿主机策略做额外限制。
3. token 管理就是边界的一部分
租户 cell 的 Gateway token 不只是“一个参数”，它本身就是入口控制的一部分。
从哪里继续
如果你要实际落地，看这两页最直接：
如果你只是普通用户，不准备托管给别人，这一页先知道概念就够了。