部署边界
托管 Cloud 与自托管
ClawButler 当前只有两种真实运行方式：托管 Cloud 和自托管。治理主线不变，变化的是基础设施归属和运维责任。
运行方式#
托管 Cloud
使用托管控制面，然后接入 OpenClaw gateway 或配对 Runtime Host。ClawButler 负责共享控制面的运行和托管基础设施默认项。
自托管
把控制面部署在你自己的基础设施里。治理主线保持一致，但反向代理、密钥、备份和支撑服务都由你自己负责。
两种模式下不变的部分#
- OpenClaw 仍然是唯一完整 provider-native 支持的连接器路径。
- Hermes / Claude Code / Codex 仍然只通过 Runtime Host 获得部分支持：pair、discover、batch-add、attach-mode session sync，以及 experimental managed inspection。
- Web 仍然是参考控制台；CLI、Mobile、MCP 仍是正式能力面，但不会追求完全对称。
- 审批、审计、会话、成本、预算、配置安全、模板、Runbook 和 Evidence 仍然遵循同一条治理契约。
真正有差异的边界#
| Boundary | Cloud | Self-Hosted |
|---|---|---|
| 基础设施归属 | ClawButler 负责共享控制面和托管默认基础设施。 | 你负责 Web、API、数据库、缓存、反向代理、密钥和备份。 |
| 通知与认证配套 | 托管环境里的平台基础设施已预先接好。 | SMTP、Push、OAuth、加密和备份状态取决于你的本地配置。 |
| 自动化认证 | 人类操作继续用正常登录；MCP / 自动化优先用组织级 service token。 | Token 模型相同，但认证外围、密钥轮换和暴露边界由你自己负责。 |
| 升级与回滚 | 托管控制面侧处理。 | 你自己运行安装、升级、回滚，并对部署结果做验证。 |
| 支持边界 | 适合希望更低运维负担、快速开始的场景。 | 适合需要自有基础设施、反向代理和数据边界的场景。 |
如何选择#
适合 Cloud
你希望快速配对 Runtime Host、治理本地 coding runtime，并且不想自己运行控制面。
适合自托管
你需要把 API、Web、PostgreSQL、Valkey 和相关支撑基础设施放在自己的环境里。
先把边界说清
无论选哪种模式，当前产品契约都不变：OpenClaw-first 治理主线、Runtime Host 部分支持，以及不对 Hermes / Claude Code / Codex 做 provider-native 同权承诺。
两种模式之间的迁移#
Cloud → 自托管
- 先部署目标实例，并验证 health、capabilities 和 infrastructure status。
- 在目标环境里补齐你需要的认证、通知和反向代理边界。
- 重新接入 OpenClaw gateway 或重新配对 Runtime Host，再核对审批、会话和成本同步。
自托管 → Cloud
- 登录 Cloud，并切到目标组织上下文。
- 在托管控制面里重新接入 OpenClaw gateway，或重新配对 Runtime Host。
- 核对治理闭环是否恢复：dashboard、approvals、audit、cost、attach-mode sessions，以及你依赖的 managed projection 摘要。
选择运行边界，而不是历史矩阵
当前真正有意义的区别是托管还是自管基础设施，不是旧的 enterprise 打包叙事。