Dify 企业私有化部署实战：从 Docker 到生产级知识库的完整路径
引言
对制造企业来说，大模型的诱惑很直接：把几十年沉淀的工艺文件、设计规范、设备手册变成一个"随问随答"的智能助手。但真正卡住落地的，往往不是模型能力，而是一句话——这些图纸和工艺数据，绝对不能出内网。
Dify 作为开源的 LLM 应用开发平台，恰好解决了这个矛盾：它支持完整的私有化部署，能把数据、模型密钥、知识库全部留在企业自己的服务器上。本文不重复讲 Dify 的工作流怎么编排（那部分见 AI Agent 工作流设计实战），而是聚焦部署本身——从 Docker Compose 起一套环境，到接入本地模型与向量库，再到达到生产级可用的完整路径。
说明：Dify 迭代很快，本文给出的是可落地的整体路径与要点，涉及具体版本号、镜像标签、配置字段的细节，请以 Dify 官方文档 为准。
一、为什么制造业必须私有化
在动手部署前，先说清楚"为什么不直接用云端 SaaS"，因为这决定了整个部署的架构取向。
- 数据是核心资产：图纸、工艺文件、BOM、客户与订单信息，是制造企业最敏感的资产。走公有云 SaaS，意味着这些数据要上传到企业不可控的第三方边界。
- 合规红线：国企、军工、涉密及很多大型制造集团，明确禁止核心数据出内网。私有化不是"更安全"的选项，而是"唯一可行"的选项。
- 成本可控：知识库规模大、调用频繁时，按 token 计费的云端 API 成本会快速累积；私有化 + 本地模型在长期高频使用下更经济。
私有化部署的目标可以概括为一句话：模型能力进内网，企业数据不出内网。 后面所有的部署决策，都围绕这个目标展开。
二、Docker Compose 部署步骤
Dify 官方推荐用 Docker Compose 部署，这是启动最快、最适合企业内网的方式。
环境准备
一台 Linux 服务器（建议 Ubuntu / CentOS），安装好：
- Docker 与 Docker Compose（较新版本的 Docker 已内置 compose 插件）
- 资源：仅跑 Dify 应用本身，官方最低要求约 2 核 4G，生产环境建议 8 核 16G 以上，并为知识库、日志预留足够磁盘。若要在同机跑本地大模型推理，需额外 GPU 资源。
拉取代码并启动
Dify 官方仓库自带 docker 目录和 Compose 配置，标准流程如下：
# 1. 克隆官方仓库（也可下载指定 release 版本，生产环境不建议直接用 main 分支）
git clone https://github.com/langgenius/dify.git
cd dify/docker
# 2. 复制环境变量模板
cp .env.example .env
# 3. 按需编辑 .env（关键项见下）
# 修改数据库密码、密钥、对外访问地址等
# 4. 启动全部服务
docker compose up -d
# 5. 查看服务状态
docker compose ps
启动完成后，通过浏览器访问服务器地址（默认经 nginx 暴露在 80 端口），首次访问会引导设置管理员账号。
.env 关键配置要点
.env 是私有化部署的核心，几个必须关注的方向：
- 密钥与密码：务必修改默认的
SECRET_KEY、数据库密码等，不要用示例值直接上生产。 - 对外访问地址：正确设置
CONSOLE_API_URL、APP_WEB_URL等，否则前端会出现接口地址错误。 - 数据持久化：确认数据库、向量库、文件存储都挂载到宿主机卷或指定存储，避免容器重建后数据丢失。
- 向量库选择：Dify 支持多种向量数据库，通过环境变量切换（详见下一节）。
具体的变量名与默认值以官方 .env.example 为准，升级时也要对照新版模板检查是否有新增项。
三、接入本地模型与向量库
这是"数据不出内网"落地的关键一步——推理和向量化都必须在内网完成。
接入本地大模型
Dify 通过模型供应商机制接入模型，且兼容 OpenAI 接口规范。内网私有化的典型做法：
- 在内网 GPU 服务器上，用 Ollama 或 vLLM 部署开源模型（如 Qwen、DeepSeek 等），对外暴露一个 OpenAI 兼容的 API 端点。
- 在 Dify 控制台的"设置 → 模型供应商"中，选择 OpenAI 兼容类型的供应商，填入内网 API 地址与密钥。
- 分别配置对话模型（Chat/LLM）和 Embedding 模型（用于知识库向量化）。
这样一来，用户提问、模型推理、文档向量化的全过程都在内网闭环，没有任何数据流向第三方。
选择向量库
RAG 知识库的向量存储是另一个数据落点，Dify 支持多种向量数据库：
| 向量库 | 适用场景 |
|---|---|
| 内置 / pgvector | 中小规模知识库，部署最简单，随 PostgreSQL 一起管理 |
| Qdrant | 中大规模，性能与易用性均衡，社区活跃 |
| Milvus | 大规模、高并发，功能完整但运维成本较高 |
选型建议：从小场景起步优先用内置或 pgvector，验证效果后再按知识库规模决定是否迁移到 Qdrant / Milvus。 无论选哪个，都部署在内网，保证知识库内容不外流。切换向量库通过 .env 中的相关变量配置，具体字段以官方文档为准。
四、生产级部署要点
从"能跑起来"到"敢在生产用"，还差这几步治理工作。
权限与审计
- 账号权限分级：按角色控制谁能访问哪些应用、哪些知识库，避免所有人都是管理员。
- 操作审计：保留操作与访问日志，关键操作可追溯，满足合规审计要求。
备份
私有化部署下数据主要落在三处，都要纳入备份：
- PostgreSQL：应用配置与元数据，定期
pg_dump或卷快照。 - 向量数据库：按所选向量库自身的备份方案处理。
- 文件存储卷：上传的原始文档，定期快照或同步到备份存储。
所有备份留在内网并做访问控制。升级前必须先完整备份一次。
监控
- 监控容器与服务健康状态（
docker compose ps、健康检查）。 - 监控 CPU、内存、磁盘、GPU 资源占用，知识库和日志增长会持续吃磁盘。
- 关注模型调用的响应时延与错误率，及时发现推理服务异常。
升级
Dify 迭代快，跨版本升级偶有数据库结构变更。稳妥流程：
- 升级前完整备份（数据库 + 向量库 + 存储卷）。
- 先在测试环境用生产数据副本跑一遍升级，验证工作流、知识库、Agent 都正常。
- 确认无误再上生产，并保留回滚方案。
切忌在生产环境直接拉 latest 镜像覆盖。 生产环境应锁定明确的版本号。
五、制造业典型落地场景
部署只是底座，价值来自场景。以下是几个数据现成、容错空间大、适合先落地的制造业场景：
- 工艺问答：把工艺文件、SOP、作业指导书做成 RAG 知识库，一线人员用自然语言查"这道工序的参数是多少""这个材料怎么处理"，答案带原始文档出处。
- 设计规范与标准检索：把企业设计规范、国标/行标、内部技术手册向量化，设计工程师在设计时随手查证，减少翻文档的时间。
- 设备手册 RAG：设备操作、维护、故障排查手册做成问答助手，缩短售后与运维的响应时间。
- 质检与报告文本生成：辅助生成质检报告、工艺文件、周报的初稿与摘要，人工复核后定稿。
落地建议：从"知识问答"这类数据现成、不直接触碰生产系统的场景切入，用私有化部署跑通"数据不出内网 + 回答有据可查"的闭环，再逐步扩展到与 ERP / PLM 联动的场景。
总结
Dify 私有化部署为制造业提供了一条清晰的 AI 落地路径：用 Docker Compose 快速起一套内网环境，接入本地大模型与向量库让数据全程闭环，再补齐权限、备份、监控、升级这几项生产级治理，就能在"数据不出内网"的前提下，把工艺、规范、手册这些沉淀多年的知识变成随问随答的智能助手。
真正的难点不在于跑起一个 Demo，而在于把它做成安全、可维护、能持续迭代的生产系统——这需要对制造业业务和私有化落地都有经验的团队。青岛辰时提供制造业 AI Agent 与 Dify / N8N 的私有化落地服务，覆盖从场景梳理、私有化部署、本地模型与知识库接入，到系统集成与上线后的持续优化。技术咨询免费，欢迎发邮件至 info@qdchenshi.com，或访问 联系我们 说明你的场景与内网环境，我们帮你把落地路径规划清楚。
延伸阅读：
- AI Agent 工作流设计实战：用 Dify 构建智能自动化系统 — Dify 的工作流与 Agent 编排
- CAD 二次开发外包怎么选 — 如果你还有 CAD 侧的定制需求
