Dify 生产环境部署指南｜生产环境实测

Dify 是一款开源的 LLMOps 平台，集成了大模型应用开发、Prompt 编排、知识库、Agent、工作流、API 发布、日志观测等能力。相比单纯调用大模型 API，Dify 更适合在企业内部快速搭建 AI 应用，例如智能客服、知识库问答、数据分析助手、流程自动化机器人等。

很多人在本地用 Docker Compose 跑通 Dify 后，会发现真正上生产环境时还需要考虑很多问题：服务器配置如何选择？Docker 部署是否可靠？数据库和向量库要不要拆分？HTTPS 怎么配置？如何做数据持久化、备份、升级和监控？本文将以生产环境部署视角，整理一套较完整的 Dify 部署方案，适合中小团队、企业内部应用以及需要长期稳定运行的 AI 项目参考。

一、生产环境部署目标

本指南的目标不是“能跑起来”，而是“能稳定跑、可维护、可扩展、可恢复”。

生产环境部署 Dify 时，建议至少满足以下要求：

1. 服务可长期稳定运行

   • 容器异常后可自动重启；
   • 服务器重启后服务可自动恢复；
   • 各组件数据需要持久化。

2. 访问安全

   • 使用 HTTPS；
   • 后台管理入口做好访问控制；
   • 敏感配置不暴露；
   • API Key、模型 Key、数据库密码安全管理。

3. 数据可靠

   • PostgreSQL、Redis、向量数据库、上传文件等必须持久化；
   • 定期备份数据库和存储目录；
   • 升级前必须备份。

4. 具备扩展能力

   • 未来可将数据库、Redis、向量库迁移到独立实例；
   • 支持多用户、多应用、多知识库；
   • 支持接入不同大模型厂商。

5. 便于运维

   • 能查看日志；
   • 能快速定位问题；
   • 有明确升级和回滚策略。

二、服务器配置建议

Dify 本身并不一定要求非常高的机器配置，真正影响资源消耗的通常是以下因素：

• 是否本地部署大模型；
• 是否本地部署 Embedding 模型；
• 知识库文档数量和切片规模；
• 并发请求量；
• 工作流复杂度；
• 向量数据库规模。

如果只是调用 OpenAI、Azure OpenAI、通义千问、智谱、DeepSeek、Claude 等外部模型 API，Dify 服务器主要承担 Web 服务、API 服务、任务队列、数据库、向量检索等工作。

1. 小型生产环境

适合个人项目、小团队内部使用、低并发知识库问答。

2. 中型生产环境

适合企业内部多个应用、多知识库、中等访问量。

3. 大型生产环境

适合对外服务、高并发、多租户或企业级复杂场景。

如果你是第一次生产部署，建议先使用 Docker Compose 在单机上跑通，并把数据盘、备份、HTTPS、日志和升级流程做好。等业务量上来后，再逐步拆分数据库、Redis 和向量库。

三、部署前准备

本文以 Ubuntu 22.04 LTS 为例，使用 Docker Compose 进行部署。生产环境建议使用 Linux 服务器，不建议使用 Windows Server 作为主要部署环境。

1. 更新系统

sudo apt update
sudo apt upgrade -y

2. 安装基础工具

sudo apt install -y curl wget git vim unzip htop net-tools ca-certificates gnupg lsb-release

3. 安装 Docker

curl -fsSL https://get.docker.com | bash

启动 Docker 并设置开机自启：

sudo systemctl enable docker
sudo systemctl start docker

检查 Docker 版本：

docker version

4. 安装 Docker Compose

较新的 Docker 通常已内置 Compose 插件，可执行：

docker compose version

如果没有安装，可按 Docker 官方文档安装 Compose 插件。

5. 配置防火墙

如果使用 Ubuntu 的 UFW，可以开启基础端口：

sudo ufw allow 22
sudo ufw allow 80
sudo ufw allow 443
sudo ufw enable

如果服务器在云平台上，还需要在安全组中放行：

• SSH：22
• HTTP：80
• HTTPS：443

生产环境不建议直接暴露数据库、Redis、向量库端口到公网。

四、获取 Dify 部署文件

克隆 Dify 官方仓库：

git clone https://github.com/langgenius/dify.git
cd dify/docker

复制环境变量配置文件：

cp .env.example .env

之后主要修改 .env 文件。

五、生产环境核心配置说明

Dify 的 Docker 部署主要依赖 .env 文件控制配置。生产环境中，以下配置尤其重要。

1. 配置访问域名

假设你的域名是：

https://dify.example.com

需要在 .env 中配置类似内容：

CONSOLE_WEB_URL=https://dify.example.com
APP_WEB_URL=https://dify.example.com
SERVICE_API_URL=https://dify.example.com

部分版本配置项可能略有差异，实际以官方 .env.example 为准。原则是：所有前端和 API 对外访问地址都应使用正式 HTTPS 域名。

2. 设置强密码

生产环境一定要修改默认密码，例如：

DB_PASSWORD=your_strong_postgres_password
REDIS_PASSWORD=your_strong_redis_password

建议使用随机强密码，不要使用 123456、password、公司名、项目名等弱口令。

可以使用如下命令生成随机密码：

openssl rand -base64 32

3. 设置 Secret Key

Dify 中通常会涉及应用加密、Token、会话等安全配置，生产环境必须使用强随机值。

openssl rand -base64 42

然后将生成的值配置到 .env 中对应的 Secret 项。

4. 配置文件存储

Dify 支持本地存储和对象存储。小型部署可以先使用本地存储，但生产环境更推荐对象存储，例如：

• AWS S3
• 阿里云 OSS
• 腾讯云 COS
• MinIO
• 华为云 OBS

本地存储优点是简单，缺点是迁移和扩容不方便。如果文件较多、知识库文档较大，建议尽早使用对象存储。

5. 配置向量数据库

Dify 支持多种向量数据库，常见包括：

• Weaviate
• Qdrant
• Milvus
• PostgreSQL pgvector
• Elasticsearch 等

如果是中小规模知识库，Qdrant 或 Weaviate 都比较常见。生产环境需要注意：

1. 向量库数据必须持久化；
2. 不要暴露向量库端口到公网；
3. 大规模知识库建议独立部署向量库；
4. 升级前备份向量数据。

6. 配置模型供应商

进入 Dify 控制台后，可以配置模型提供商，例如：

• OpenAI
• Azure OpenAI
• Anthropic Claude
• Google Gemini
• DeepSeek
• 智谱 AI
• 阿里云通义千问
• 火山方舟
• 百度千帆
• Ollama
• Xinference

如果使用外部模型 API，需要确保服务器能够访问对应模型服务。如果服务器位于国内，访问部分海外模型服务可能需要网络策略支持。

六、启动 Dify 服务

在 dify/docker 目录下执行：

docker compose up -d

查看容器状态：

docker compose ps

查看日志：

docker compose logs -f

如果所有容器正常启动，可以通过服务器 IP 或域名访问。生产环境建议不要直接使用 IP 暴露，而是尽快配置反向代理和 HTTPS。

七、配置 Nginx 反向代理和 HTTPS

生产环境强烈建议使用 HTTPS。可以使用 Nginx + Certbot 申请 Let's Encrypt 免费证书。

1. 安装 Nginx

sudo apt install -y nginx
sudo systemctl enable nginx
sudo systemctl start nginx

2. 配置反向代理

创建配置文件：

sudo vim /etc/nginx/sites-available/dify.conf

示例配置：

server {
    listen 80;
    server_name dify.example.com;

    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 $scheme;

        proxy_read_timeout 300;
        proxy_connect_timeout 300;
        proxy_send_timeout 300;
    }
}

启用配置：

sudo ln -s /etc/nginx/sites-available/dify.conf /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

注意：如果 Dify Docker 中的 Nginx 已经占用了宿主机 80 端口，你需要调整 Docker Compose 的端口映射，避免和宿主机 Nginx 冲突。常见做法是让 Dify 内部服务映射到 127.0.0.1:8080，宿主机 Nginx 再反代到 8080。

3. 申请 HTTPS 证书

安装 Certbot：

sudo apt install -y certbot python3-certbot-nginx

申请证书：

sudo certbot --nginx -d dify.example.com

按提示完成后，Certbot 会自动修改 Nginx 配置并开启 HTTPS。

测试自动续期：

sudo certbot renew --dry-run

八、数据持久化与目录规划

生产环境中，数据目录不建议随意放在系统盘默认位置。更规范的方式是挂载独立数据盘，例如：

/data/dify
├── postgres
├── redis
├── qdrant
├── weaviate
├── storage
├── backups
└── logs

如果直接使用官方 Docker Compose，需要检查 docker-compose.yaml 中的 volume 映射，确认数据库、Redis、向量库和上传文件都持久化到了宿主机或 Docker volume 中。

可以查看 Docker volume：

docker volume ls

查看容器挂载：

docker inspect 

生产环境一定要明确：数据到底存在哪里。否则后续迁移、备份和故障恢复时会非常被动。

九、备份策略

Dify 生产环境至少需要备份以下内容：

1. PostgreSQL 数据库；
2. 向量数据库数据；
3. 上传文件和知识库原始文件；
4. .env 配置文件；
5. Docker Compose 配置文件；
6. Nginx 配置；
7. SSL 证书配置，或至少保留重新申请证书的能力。

1. PostgreSQL 备份

进入容器或使用 docker exec 执行：

docker exec -t  pg_dump -U postgres dify > /data/dify/backups/dify_$(date +%F).sql

实际数据库名、用户名需要以你的配置为准。

2. 备份配置文件

cp /path/to/dify/docker/.env /data/dify/backups/env_$(date +%F).bak
cp /path/to/dify/docker/docker-compose.yaml /data/dify/backups/docker-compose_$(date +%F).yaml

3. 定时任务

可以使用 crontab 每天凌晨执行备份脚本：

crontab -e

示例：

0 2 * * * /data/dify/scripts/backup.sh >> /data/dify/logs/backup.log 2>&1

4. 备份保留策略

建议：

• 本地保留最近 7 天；
• 对象存储保留最近 30 天；
• 重大版本升级前单独做一次完整备份；
• 定期演练恢复流程。

只备份不恢复是不完整的备份策略。至少每隔一段时间要在测试环境中验证备份是否可用。

十、升级 Dify 的正确方式

Dify 迭代速度较快，升级前要特别谨慎。生产环境不建议看到新版本就立即升级，而应遵循以下流程：

1. 阅读 Release Notes

先查看官方发布说明，重点关注：

• 是否有数据库迁移；
• 是否有环境变量变更；
• 是否有模型配置变更；
• 是否有向量库兼容问题；
• 是否有破坏性更新。

2. 备份数据

升级前至少备份：

• PostgreSQL；
• 向量库；
• storage 文件；
• .env；
• docker-compose.yaml。

3. 拉取新版本

cd dify
git fetch --all
git checkout 
cd docker

如果你直接跟随主分支，风险会更高。生产环境更建议使用稳定版本 Tag。

4. 对比配置文件

新版本的 .env.example 可能新增配置项，不能简单覆盖原 .env。

建议使用：

diff .env.example .env

或手动比对新增项，将必要配置补充到现有 .env 中。

5. 拉取镜像并重启

docker compose pull
docker compose down
docker compose up -d

观察日志：

docker compose logs -f

6. 验证业务

升级后需要检查：

• 控制台是否正常登录；
• 已发布应用是否正常访问；
• 知识库检索是否正常；
• 工作流是否正常执行；
• 模型调用是否正常；
• API Key 是否仍然可用；
• 文件上传是否正常。

十一、生产环境安全建议

1. 不要暴露内部端口

除 80、443、22 外，其他服务端口原则上不应暴露到公网。例如：

• PostgreSQL：5432
• Redis：6379
• Qdrant：6333
• Weaviate：8080
• Dify API 内部端口

这些端口应仅允许容器网络或内网访问。

2. SSH 安全

建议：

• 禁止 root 直接登录；
• 使用 SSH Key；
• 修改默认 SSH 端口；
• 使用防火墙限制来源 IP；
• 安装 fail2ban。

3. 管理后台访问控制

如果 Dify 只供企业内部使用，可以考虑：

• 通过 VPN 访问；
• 使用企业内网域名；
• 在 Nginx 前增加 IP 白名单；
• 使用统一身份认证；
• 对管理后台进行额外保护。

4. API Key 管理

Dify 应用发布后通常会生成 API Key。生产环境要注意：

• 不要把 API Key 写死在前端代码；
• 不要提交到 Git 仓库；
• 定期轮换；
• 泄露后立即删除并重新生成；
• 根据应用拆分不同 Key。

5. 日志安全

日志中可能出现用户输入、模型输出、接口调用信息，甚至可能包含敏感数据。应避免将日志随意外发，并对日志访问权限进行控制。

十二、常见问题排查

1. 页面打不开

排查顺序：

docker compose ps
docker compose logs -f
sudo nginx -t
sudo systemctl status nginx

同时检查：

• 域名解析是否正确；
• 云服务器安全组是否放行 80/443；
• Nginx 反向代理端口是否正确；
• Dify 容器端口映射是否冲突。

2. 登录后接口报错

可能原因：

• .env 中 URL 配置不正确；
• 前端地址和后端 API 地址不一致；
• HTTPS 反代缺少 X-Forwarded-Proto；
• 容器未完全启动；
• 数据库迁移未完成。

3. 知识库无法索引

可能原因：

• Embedding 模型未配置；
• 模型 API Key 无效；
• 向量数据库未启动；
• 文档过大；
• Worker 容器异常；
• Redis 队列异常。

可重点查看 worker 日志：

docker compose logs -f worker

4. 模型调用失败

检查：

• 模型供应商 API Key；
• 服务器网络是否能访问模型接口；
• 模型名称是否填写正确；
• 账户余额或额度；
• 供应商接口限流；
• 代理配置是否正确。

5. 文件上传失败

检查：

• client_max_body_size 是否过小；
• Dify 文件大小限制；
• storage 目录权限；
• 对象存储配置；
• 磁盘空间是否充足。

十三、生产环境实测经验总结

在实际部署中，Dify 的启动并不复杂，真正容易出问题的是以下几个方面：

1. 域名和 HTTPS 要尽早配置

很多接口异常、回调异常、前端跳转异常，本质都是 URL 配置混乱导致的。生产环境从一开始就应该使用正式域名和 HTTPS，不要先用 IP 跑一段时间再迁移。

2. 不要轻视 Worker

知识库索引、文档处理、异步任务都依赖 Worker。如果 Worker 异常，表面上控制台可能还能打开，但知识库构建、工作流执行等功能会出现问题。因此排查问题时不要只看 Web 容器，也要看 API、Worker、Redis、数据库和向量库。

3. 数据库最好尽早独立

单机 Docker Compose 适合起步，但如果 Dify 已经承载关键业务，PostgreSQL 最好迁移到独立数据库实例。这样备份、监控、扩容和恢复都更方便。

4. 知识库规模扩大后要关注向量库性能

小规模文档时，向量检索通常感受不到压力。但当知识库数量、切片数量、并发检索量增加后，向量库性能会明显影响应用响应速度。建议提前规划向量库的存储、内存和索引策略。

5. 升级不要跳太多版本

如果生产环境版本较老，不建议一次性跨越多个大版本升级。可以先在测试环境验证，再分阶段升级。尤其涉及数据库迁移和环境变量变化时，更要谨慎。

十四、推荐的生产部署架构

对于中小团队，推荐如下架构：

用户
  |
HTTPS
  |
Nginx / SLB
  |
Dify Web + API + Worker
  |
  |--- PostgreSQL
  |--- Redis
  |--- Vector DB
  |--- Object Storage
  |
外部大模型服务

进一步演进时，可以拆分为：

• Nginx 或云负载均衡；
• Dify Web 多实例；
• Dify API 多实例；
• Worker 多实例；
• 独立 PostgreSQL；
• 独立 Redis；
• 独立向量数据库；
• 对象存储；
• Prometheus + Grafana 监控；
• ELK / Loki 日志系统。

十五、结语

Dify 是一个非常适合企业快速落地 AI 应用的平台，但生产环境部署不能只停留在“Docker Compose up 起来”。真正稳定的生产环境，需要同时考虑域名、HTTPS、数据持久化、数据库备份、向量库性能、模型服务可用性、日志排查、安全控制和升级策略。

如果你的 Dify 只是个人测试，官方 Docker Compose 足够简单高效；如果已经承载企业内部知识库、客服机器人或业务工作流，就必须把它当作正式系统来运维。建议至少做到以下几点：

1. 使用正式域名和 HTTPS；
2. 修改所有默认密码和 Secret；
3. 明确数据存储位置；
4. 建立自动备份机制；
5. 升级前先备份并在测试环境验证；
6. 不暴露数据库、Redis、向量库端口；
7. 定期检查日志、磁盘、内存和模型调用情况。

按照以上方案部署后，Dify 可以较稳定地运行在生产环境中，并为后续扩展到更高并发、更复杂工作流和更多业务场景打下基础。