要点
- 自托管意味着应用、数据库与 AI 运行在您控制的基础设施上。
- 通常的理由是驻留、隔离，或一张不能访问公共互联网的网络。
- 多数“本地 CRM”仍把 AI 提示发到云模型。把这个问题单独问。
- Qivity runs on Docker with PostgreSQL and Redis. Lilly is an optional add-on that then runs on your infrastructure, with egress optional.
自托管 CRM 是您运行在自己控制的基础设施上的软件： 您的虚拟机、您的 Kubernetes 集群、您的私有云。应用、数据库，以及——如果产品诚实——AI 助手，都住在那里。
它与“我们在孟买有一个数据中心区域”不是一回事。SaaS 数据库的驻留有用。那不是自托管。
何时自托管 CRM 是正确选择
- 监管或客户合同对处理位置的点名，比供应商区域能满足的更紧。
- 网络是气隙的，或出口本身就是事故。
- 您已经在运营 PostgreSQL，宁愿扩展它，也不愿打开一块新的 SaaS 攻击面。
- 采购不会接受基础模型子处理方，而 CRM 的助手仍必须继续工作。
如果这些都不成立，一套运转良好的托管部署更简单。自托管是运维选择，不是徽章。
AI 的陷阱
许多本地 CRM 仍会调用托管模型。那您就是为私有数据库和公开提示付了钱。 私有 AI CRM 把推理留在同一边界内。Qivity 的自托管选项 包含运行在本地模型上的 Lilly。 架构对比 是短版本。
您实际要运营什么
Qivity 的占地刻意无聊：Docker、PostgreSQL、Redis。备份就是数据库备份。升级就是拉取镜像。没有专有一体机，也不需要合作伙伴来“把组织立起来”。
您仍需要一个能跑容器并恢复数据库的人。如果那个人不存在，不要把自托管当成政治姿态。使用托管，把 AI 留在部署本地，等团队就绪再回头。
该问供应商的问题
- AI 是否在同一套安装里运行，并且可以关闭出口？
- 我们拥有哪套数据库，能否转储？
- 不需要一周专业服务的升级路径是什么？
- SSO、审计导出、备份保留——在产品里，还是作为定制构建？
如果自托管是要求而不是偏好，联系我们。 带上约束（气隙、区域、DPA），而不是一句笼统的“我们要本地部署”。约束决定安装方式。