企业私有化落地 Dify:从 Docker 部署到生产运维指南
Dify Docker部署教程|适合企业用户
随着大模型应用在企业内部的落地速度不断加快,越来越多团队开始关注如何快速构建 AI 应用、知识库问答、智能客服、流程自动化助手以及企业内部 Copilot。Dify 作为一款开源的大模型应用开发平台,提供了从 Prompt 编排、Agent 构建、知识库管理、工作流设计到 API 发布的一整套能力,非常适合企业用于搭建可控、可扩展、可私有化部署的 AI 应用平台。
对于企业用户来说,Docker 部署是目前最推荐的 Dify 部署方式之一。它相较于源码部署更简单,环境隔离更清晰,升级维护也更加方便。本文将围绕企业场景,详细介绍如何通过 Docker 部署 Dify,并补充生产环境中需要重点关注的配置、安全、存储、备份与运维建议。
一、Dify 简介
Dify 是一个开源的 LLMOps 平台,可以帮助开发者和企业快速构建基于大语言模型的应用。它支持多种主流大模型服务,包括 OpenAI、Azure OpenAI、Anthropic、通义千问、智谱 AI、Moonshot、DeepSeek、火山引擎、百度千帆等,也支持企业自建模型服务,例如通过 Ollama、Xinference、vLLM、LocalAI 等方式接入本地大模型。
Dify 的核心能力包括:
- 可视化应用编排:无需从零写代码,即可构建聊天助手、文本生成应用、Agent 应用等。
- 知识库管理:支持上传文档、分段、向量化、检索召回,适用于企业知识问答。
- 工作流能力:通过节点编排方式实现复杂业务逻辑,例如审批辅助、合同审查、客服分流等。
- 模型统一管理:集中配置不同模型供应商,方便企业内部统一调用。
- API 发布:每个应用都可以生成 API,方便与企业现有系统集成。
- 权限与团队协作:适合多人团队共同开发和维护 AI 应用。
- 私有化部署:企业可以将数据、应用和模型调用控制在自己的基础设施中。
对于注重数据安全、权限治理和成本控制的企业来说,Dify 私有化部署具有很高的实际价值。
二、为什么企业用户推荐使用 Docker 部署 Dify
Dify 支持多种部署方式,但对于多数企业用户而言,Docker 或 Docker Compose 是最适合的入门和生产部署方式。
1. 环境隔离清晰
Dify 依赖多个组件,例如:
- Web 前端
- API 后端
- Worker 异步任务
- PostgreSQL 数据库
- Redis 缓存
- 向量数据库
- Nginx 网关
- Sandbox 代码执行环境
- Plugin Daemon 插件服务
如果采用手动部署,需要分别安装和配置这些组件,容易出现版本冲突和环境不一致问题。Docker 可以将每个服务封装到独立容器中,降低部署复杂度。
2. 部署速度快
使用 Docker Compose 可以通过一条命令启动多个服务,非常适合快速搭建测试环境、预生产环境和小规模生产环境。
3. 便于升级和回滚
企业系统最忌讳升级不可控。Docker 镜像版本明确,配置文件可管理。如果升级后出现问题,可以较快回滚到旧版本。
4. 适合企业标准化交付
企业内部往往需要将部署过程文档化、自动化、标准化。Docker Compose 文件、环境变量文件和数据卷配置都可以纳入版本管理,便于运维团队接管。
三、部署前准备
在正式部署 Dify 之前,需要准备服务器、域名、系统环境以及必要的软件依赖。
四、服务器配置建议
Dify 的服务器配置取决于企业使用规模、知识库文档数量、并发访问量以及是否在本机运行大模型。
如果 Dify 仅作为应用平台使用,模型通过外部 API 调用,例如 OpenAI、Azure OpenAI、通义千问、DeepSeek 等,则服务器压力相对较小。
测试环境建议
| 配置项 | 建议配置 |
|---|---|
| CPU | 2 核及以上 |
| 内存 | 4GB 及以上 |
| 磁盘 | 30GB 及以上 |
| 系统 | Ubuntu 20.04/22.04 或 Debian/CentOS |
测试环境可以用于功能验证、模型接入测试和应用原型搭建。
小型企业生产环境建议
| 配置项 | 建议配置 |
|---|---|
| CPU | 4 核及以上 |
| 内存 | 8GB - 16GB |
| 磁盘 | 100GB SSD 及以上 |
| 系统 | Ubuntu 22.04 LTS |
| 网络 | 公网或内网稳定访问 |
适合 10-50 人团队使用,主要用于企业内部知识库、客服助手、办公助手等场景。
中大型企业生产环境建议
| 配置项 | 建议配置 |
|---|---|
| CPU | 8 核及以上 |
| 内存 | 32GB 及以上 |
| 磁盘 | 300GB SSD 起步 |
| 数据库 | 建议独立 PostgreSQL |
| Redis | 建议独立 Redis |
| 向量库 | 建议独立部署 |
| 部署方式 | 可考虑 Kubernetes |
如果企业需要承载多个业务部门、较高并发访问、海量知识库文档,建议将数据库、对象存储、向量数据库等组件拆分部署,避免所有服务集中在单台机器上。
五、基础环境安装
下面以 Ubuntu 22.04 LTS 为例进行说明。
1. 更新系统软件包
sudo apt update
sudo apt upgrade -y
2. 安装必要工具
sudo apt install -y git curl vim ca-certificates gnupg lsb-release
这些工具用于拉取代码、编辑配置文件、安装 Docker 以及排查问题。
六、安装 Docker
如果服务器尚未安装 Docker,可以使用官方方式安装。
1. 添加 Docker GPG 密钥
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
2. 添加 Docker 软件源
echo \
"deb [arch=$(dpkg --print-architecture) \
signed-by=/etc/apt/keyrings/docker.gpg] \
https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
3. 安装 Docker Engine 和 Docker Compose
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
4. 验证 Docker 是否安装成功
docker --version
docker compose version
如果能够正常输出版本号,说明安装成功。
5. 将当前用户加入 Docker 用户组
sudo usermod -aG docker $USER
执行后建议重新登录服务器,使用户组权限生效。
七、获取 Dify Docker 部署文件
Dify 官方提供了 Docker Compose 部署方案。进入服务器上的合适目录,例如 /opt:
cd /opt
sudo git clone https://github.com/langgenius/dify.git
cd dify/docker
如果服务器访问 GitHub 较慢,可以考虑通过企业内部代码镜像仓库同步 Dify 项目,或者提前下载后上传到服务器。
查看目录文件:
ls -la
通常可以看到如下文件:
docker-compose.yaml
.env.example
middleware.env.example
nginx/
volumes/
其中最重要的是:
docker-compose.yaml:定义所有容器服务。.env.example:环境变量模板。middleware.env.example:中间件相关配置模板。volumes/:持久化数据目录。nginx/:Nginx 配置目录。
八、配置环境变量
1. 复制环境变量文件
cp .env.example .env
部分版本中也需要复制中间件配置:
cp middleware.env.example middleware.env
然后编辑 .env 文件:
vim .env
Dify 的配置项较多,企业部署时建议重点关注以下内容。
九、企业用户重点配置项说明
1. SECRET_KEY
SECRET_KEY 是 Dify 用于加密敏感数据的重要密钥,生产环境必须修改,不能使用默认值。
可以通过以下命令生成随机密钥:
openssl rand -base64 42
然后在 .env 中配置:
SECRET_KEY=生成的随机密钥
企业环境中建议将密钥纳入统一密钥管理系统,例如 Vault、云厂商 KMS 或内部密钥平台。
2. 访问地址配置
如果企业希望通过域名访问 Dify,例如:
https://dify.example.com
需要关注以下配置:
CONSOLE_WEB_URL=https://dify.example.com
SERVICE_API_URL=https://dify.example.com
APP_WEB_URL=https://dify.example.com
不同版本的 Dify 配置项可能略有差异,建议以当前 .env.example 为准。
如果只是内网测试,可以先使用服务器 IP:
CONSOLE_WEB_URL=http://服务器IP
SERVICE_API_URL=http://服务器IP
APP_WEB_URL=http://服务器IP
3. 数据库配置
默认 Docker Compose 会启动 PostgreSQL 容器,适合测试环境和小规模部署。
常见配置类似:
DB_USERNAME=postgres
DB_PASSWORD=your_secure_password
DB_HOST=db
DB_PORT=5432
DB_DATABASE=dify
企业生产环境中,强烈建议修改默认密码,并定期备份数据库。
如果企业已有 PostgreSQL 数据库服务,可以改为外部数据库:
DB_HOST=your-postgres-host
DB_PORT=5432
DB_USERNAME=dify
DB_PASSWORD=your_password
DB_DATABASE=dify
同时需要在 docker-compose.yaml 中根据实际情况关闭内置数据库服务,或者保留但不使用。对于生产环境,外部数据库通常更易于备份、监控和高可用。
4. Redis 配置
Redis 用于缓存、队列等场景。默认 Compose 会启动 Redis 容器。
配置示例:
REDIS_HOST=redis
REDIS_PORT=6379
REDIS_PASSWORD=your_redis_password
生产环境中建议为 Redis 设置密码,并限制访问来源。如果 Redis 使用外部服务,应确保网络延迟较低。
5. 向量数据库配置
Dify 知识库功能依赖向量数据库。不同版本可能支持 Weaviate、Qdrant、Milvus、PGVector、Chroma 等。
小规模企业可以使用默认配置;如果企业有大量文档、知识库较多、召回并发较高,建议使用独立向量数据库。
例如使用 Qdrant 时,需要关注:
VECTOR_STORE=qdrant
QDRANT_URL=http://qdrant:6333
QDRANT_API_KEY=
如果使用外部 Qdrant:
VECTOR_STORE=qdrant
QDRANT_URL=http://your-qdrant-host:6333
QDRANT_API_KEY=your_api_key
企业在选择向量数据库时应考虑:
- 数据量规模
- 查询性能
- 运维复杂度
- 是否支持集群
- 是否支持备份恢复
- 是否满足合规要求
6. 文件存储配置
Dify 需要存储上传文件、知识库文档、应用资源等。默认可以使用本地存储,但生产环境更建议使用对象存储,例如:
- AWS S3
- MinIO
- 阿里云 OSS
- 腾讯云 COS
- 华为云 OBS
如果企业希望完全私有化,可以在内网部署 MinIO。
配置示例:
STORAGE_TYPE=s3
S3_ENDPOINT=http://minio.example.com:9000
S3_BUCKET_NAME=dify
S3_ACCESS_KEY=your_access_key
S3_SECRET_KEY=your_secret_key
S3_REGION=us-east-1
本地存储虽然简单,但在容器迁移、扩容和备份时不如对象存储灵活。
7. 邮件服务配置
企业用户通常需要邀请成员、重置密码、发送通知,因此建议配置 SMTP 服务:
MAIL_TYPE=smtp
SMTP_SERVER=smtp.example.com
SMTP_PORT=465
SMTP_USERNAME=notice@example.com
SMTP_PASSWORD=your_password
SMTP_USE_TLS=true
如果只是内部小团队使用,也可以先不配置邮件服务,但正式上线前建议补齐。
十、启动 Dify 服务
配置完成后,在 dify/docker 目录下执行:
docker compose up -d
首次启动会拉取多个镜像,时间取决于服务器网络情况。
查看服务状态:
docker compose ps
查看日志:
docker compose logs -f
如果只想查看某个服务日志,例如 API:
docker compose logs -f api
常见服务包括:
webapiworkerdbredisnginxsandboxplugin_daemon
当所有核心服务状态为 running 或 healthy 时,说明部署基本成功。
十一、访问 Dify 控制台
如果使用默认端口,可以在浏览器访问:
http://服务器IP
如果已绑定域名,则访问:
https://dify.example.com
首次访问时,Dify 会要求创建管理员账号。建议企业使用专用管理员邮箱,不要使用个人临时邮箱。
创建完成后,即可进入控制台,进行模型供应商配置、应用创建、知识库上传和团队成员管理。
十二、配置大模型供应商
进入 Dify 控制台后,可以在模型供应商设置中添加企业常用模型。
常见选择包括:
1. 使用公有云模型 API
例如:
- OpenAI
- Azure OpenAI
- 通义千问
- DeepSeek
- 智谱 AI
- Moonshot
- 百度千帆
- 火山引擎
这种方式部署简单,企业无需维护模型推理服务,但需要关注数据出境、合规、安全审计和调用成本。
2. 使用企业自建模型
如果企业对数据安全要求高,可以部署本地模型推理服务,例如:
- Ollama
- Xinference
- vLLM
- Triton
- LocalAI
- FastChat
然后在 Dify 中通过 OpenAI 兼容接口或自定义模型供应商方式接入。
企业常见架构是:
用户 → Dify → 内部模型网关 → vLLM/Xinference/Ollama → 本地大模型
这样可以通过模型网关实现鉴权、限流、审计和成本统计。
十三、配置 HTTPS 访问
企业生产环境不建议使用 HTTP 明文访问,应配置 HTTPS。
常见方式有两种:
方式一:使用外部 Nginx 或负载均衡器
如果企业已有统一网关,可以将 Dify 暴露为内网服务,再通过统一网关代理。
示例 Nginx 配置:
server {
listen 443 ssl;
server_name dify.example.com;
ssl_certificate /etc/nginx/cert/dify.example.com.pem;
ssl_certificate_key /etc/nginx/cert/dify.example.com.key;
client_max_body_size 100M;
location / {
proxy_pass http://127.0.0.1:80;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
}
这种方式适合企业已有负载均衡、WAF、安全网关或 API 网关的场景。
方式二:使用云厂商负载均衡证书
如果 Dify 部署在云服务器上,也可以通过云负载均衡绑定 HTTPS 证书,再将流量转发到 Dify 所在服务器的 HTTP 端口。
这种方式证书维护简单,也便于后续扩展多节点部署。
十四、生产环境安全建议
企业部署 Dify 不应只关注“能不能跑起来”,更应关注安全边界和权限控制。
1. 修改所有默认密码
包括:
- PostgreSQL 密码
- Redis 密码
- 向量数据库密码或 API Key
- MinIO 访问密钥
- Dify SECRET_KEY
默认密码是生产环境中的高危风险。
2. 限制管理后台访问范围
如果 Dify 只供企业内部使用,建议仅开放内网访问,或通过 VPN、零信任网关访问。
不要将数据库、Redis、向量数据库端口暴露到公网。
3. 配置防火墙
使用 UFW 示例:
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status
数据库、Redis、Qdrant、MinIO 等端口应仅允许内网访问。
4. 管理 API Key
Dify 应用发布后会生成 API Key,企业需要建立 API Key 管理规范,包括:
- 按系统或业务生成独立 Key
- 定期轮换
- 泄露后立即禁用
- 记录调用来源
- 配合网关做限流和审计
5. 避免敏感数据直接进入外部模型
如果使用公有云模型,建议企业制定数据分类策略。敏感数据、客户隐私、财务数据、合同机密等,不应直接发送到外部模型服务,除非已经过合规评估和脱敏处理。
十五、数据备份方案
生产系统必须建立备份机制。Dify 的关键数据主要包括:
- PostgreSQL 数据库
- 向量数据库数据
- 上传文件和知识库文件
.env配置文件- Nginx 配置和证书
- 对象存储数据
1. PostgreSQL 备份
如果使用内置 PostgreSQL 容器,可以执行:
docker compose exec db pg_dump -U postgres dify > dify_backup.sql
恢复时:
cat dify_backup.sql | docker compose exec -T db psql -U postgres dify
建议定期备份,并将备份文件同步到异地存储。
2. volumes 目录备份
在 dify/docker 目录下,可以备份 volumes:
tar -czvf dify_volumes_backup.tar.gz volumes/
如果使用对象存储,也应开启对象存储自身的版本控制或生命周期策略。
3. 备份频率建议
| 系统类型 | 建议频率 |
|---|---|
| 测试环境 | 每周备份 |
| 小型生产 | 每日备份 |
| 中大型生产 | 每日全量 + 小时级增量 |
| 核心业务系统 | 多地备份 + 定期恢复演练 |
备份不是目的,能够恢复才是目的。企业应至少每季度进行一次恢复演练。
十六、Dify 升级方法
升级前一定要备份数据库和配置文件。
1. 停止服务
cd /opt/dify/docker
docker compose down
2. 拉取最新代码
cd /opt/dify
git pull
cd docker
如果官方 .env.example 有新增配置项,建议对比后补充到现有 .env:
diff .env.example .env
3. 拉取最新镜像并启动
docker compose pull
docker compose up -d
4. 查看日志确认状态
docker compose logs -f
企业生产环境不建议直接升级到最新版本。更稳妥的流程是:
- 在测试环境验证新版本;
- 备份生产数据;
- 选择低峰期升级;
- 升级后进行核心功能检查;
- 保留回滚方案。
十七、常见问题排查
1. 页面无法访问
可以检查服务是否启动:
docker compose ps
检查 Nginx 日志:
docker compose logs -f nginx
确认服务器安全组、防火墙是否开放了 80 或 443 端口。
2. API 服务启动失败
查看 API 日志:
docker compose logs -f api
常见原因包括:
- 数据库连接失败
- Redis 连接失败
- SECRET_KEY 未配置
- 环境变量格式错误
- 数据库密码不一致
3. 知识库上传失败
可能原因包括:
- 文件大小超过限制
- 存储配置错误
- Worker 服务异常
- 向量数据库连接失败
- 文档解析服务异常
建议查看:
docker compose logs -f worker
docker compose logs -f api
4. 模型调用失败
常见原因包括:
- API Key 错误
- 模型供应商网络不可达
- 模型名称填写错误
- 账户余额不足
- 企业代理配置不正确
- 本地模型服务未启动
如果企业通过代理访问外部模型,需要在容器环境变量中配置代理。
十八、企业部署架构建议
对于企业生产环境,可以从简单到复杂逐步演进。
1. 单机 Docker Compose 架构
适合小型团队或试点项目:
用户
↓
Nginx
↓
Dify Web/API/Worker
↓
PostgreSQL + Redis + Vector DB
优点是部署简单、成本低。缺点是高可用能力有限。
2. 分离数据库与存储架构
适合正式生产:
用户
↓
负载均衡 / WAF
↓
Dify 应用服务器
↓
独立 PostgreSQL
独立 Redis
独立向量数据库
对象存储
这种架构更适合备份、监控、扩容和安全管理。
3. Kubernetes 架构
适合中大型企业:
用户
↓
Ingress / API Gateway
↓
Dify 服务集群
↓
云数据库 / Redis 集群 / 向量数据库 / 对象存储
Kubernetes 可以提供弹性伸缩、滚动升级、服务发现和资源隔离,但运维复杂度更高。企业应根据团队能力选择合适方案,不必一开始就上 Kubernetes。
十九、上线前检查清单
企业正式上线 Dify 前,建议按照以下清单逐项检查:
- [ ] 已修改所有默认密码;
- [ ] 已生成并配置安全的
SECRET_KEY; - [ ] 已配置 HTTPS;
- [ ] 已限制数据库、Redis、向量数据库公网访问;
- [ ] 已配置备份策略;
- [ ] 已完成一次备份恢复测试;
- [ ] 已配置模型供应商或本地模型服务;
- [ ] 已明确数据合规和脱敏规则;
- [ ] 已设置管理员账号和团队权限;
- [ ] 已配置日志采集或监控告警;
- [ ] 已制定升级和回滚流程;
- [ ] 已对 API Key 做权限和使用规范管理。
二十、总结
通过 Docker 部署 Dify,可以让企业以较低成本快速搭建私有化 AI 应用开发平台。对于试点项目,单机 Docker Compose 已经足够完成模型接入、知识库问答、应用编排和 API 发布等核心功能。对于正式生产环境,则应进一步关注数据库独立化、对象存储、HTTPS、安全隔离、备份恢复、监控告警和权限治理。
Dify 的价值不仅在于“把大模型接进来”,更在于让企业能够以标准化方式构建、管理和迭代 AI 应用。企业在部署完成后,可以从内部知识库问答、客服助手、合同审查、销售话术生成、研发助手、数据分析助手等场景切入,逐步沉淀提示词、工作流、知识资产和模型调用规范。
如果企业希望长期稳定使用 Dify,建议将其作为内部 AI 基础设施进行建设,而不是简单当作一个临时工具。只有把部署、权限、安全、成本、数据和运维体系一起考虑,Dify 才能真正成为企业 AI 应用落地的生产力平台。