Dify 私有化部署：装完才是开始

2026-09-12 更新 · 深圳市鼎铂智能科技有限公司

装 Dify 本身不难，官方文档三条命令的事。难的是装完之后接业务，下面这几件是我们在生产上真被咬过的。

先说安装：官方口径

官方给的最低机器要求是 CPU 至少 2 核、内存至少 4 GiB，并且需要 Docker 和 Docker Compose v2.24.0 以上。装法是拉下仓库后进 docker 目录：

cd dify/docker
cp .env.example .env
docker compose up -d

起来之后浏览器打开 http://localhost/install 做初始化。以上来自 Dify 官方仓库的 README。

要补一句现实：4 GiB 是「能启动」的下限，不是「能接业务」的配置。真正跑起来的时候，数据库、向量库和几个服务是同时在吃内存和磁盘的。

坑一：磁盘写满，向量库转只读，而前台一点报错都没有

我们遇到过一次：机器磁盘被别的东西写满，向量库自动进入只读状态。表现是——知识库页面一切正常，文档显示上传成功，但在对话里怎么问都搜不到新内容，全程没有任何报错。排查花的时间远远超过修复。

所以私有化部署第一件要配的不是模型，是磁盘水位告警。80% 就该叫，等到写满已经在丢数据了。

坑二：知识库「批准了却不上架」

这是两个互相独立的开关，很容易只做一半：文档本身要处于发布状态；这个知识库还要被挂进那个应用的检索范围里。只做前一件，内容永远搜不到，而后台看上去全是绿的。

验收动作要固定下来：上线前拿一个真实问题在应用里搜一次，确认召回结果里有这条新内容，不要只看知识库后台的对勾。知识库搜不到的原因不止这一个，另外四个在企业知识库搭好了却搜不到里。

坑三：第一轮能搜到，聊几轮之后就搜不到了

带查询改写的应用要特别留神这个现象。多轮之后，改写节点容易被前面的对话历史带偏，把用户这一轮的原话改写成另一个意思，检索自然落空。它不报错，只是悄悄召回不到。

排查办法很朴素：把改写之后的那句查询打进日志，拿真实的多轮对话跑一遍，肉眼比对改写前后。我们就是这么定位到一次线上「多轮之后知识库失灵」的。

坑四：备份到底要备哪几样

三样，少一份就等于没备份：数据库（应用配置、提示词、知识库元数据都在里面）、向量库的数据卷、以及 .env 文件——里面有密钥和加密盐，丢了之后旧数据解不开，光有数据库也恢复不了。

什么时候不该用 Dify

可视化编排的长处是快，而且能让业务同事自己看懂、自己改提示词，这在前期非常值钱。但当主链路复杂到需要版本管理、自动化回归、灰度和历史数据回放对比的时候，代码化更合适。

我们现在的分工是：Dify 用来验证流程、让业务同事改提示词；真正跑量的主链路落在代码里；两边共用同一套知识库和工具。这样既没丢掉可视化的便利，也不用在出事的时候对着一张流程图干瞪眼。