调整 Dify Docker 部署配置提升工作流执行性能，最推荐的做法是修改 docker 文件夹下的.env 文件而非 docker-compose.yaml，重点优化 SERVER_WORKER_AMOUNT、SERVER_WORKER_CONNECTIONS 和 GUNICORN_TIMEOUT 参数。
先说结论：通过.env 文件覆盖默认配置能避免升级失效，针对 CPU 核数调整进程数并延长超时时间可适配复杂业务场景。
- 先定位：确认服务器 CPU 核数与内存容量，判断是否满足基础运行需求。
- 先做：修改.env 文件中工作进程数量与超时时间参数，避免直接编辑 compose 文件。
- 再验证：重启服务后观察容器状态，测试长耗时工作流是否不再中断。
命令速用版
以下命令用于准备环境变量文件并重启服务，使配置生效：
cd docker
cp .env.example .env
docker compose up -d
为什么会这样
Dify 架构设计为微服务化，不同组件独立部署以隔离负载特征。
系统默认假设服务会拆分到集群中运行，通过 Docker 镜像封装依赖。调整工作进程数量能最大化利用 CPU 多核性能，减少请求排队等待时间；延长 Gunicorn 超时时间则能防止大文件解析或复杂 Workflow 执行中途被判定为超时中断。
分步处理
按照以下步骤调整配置，确保修改持久化且安全：
- 备份配置文件：进入 docker 目录，复制.env.example 为.env，若已存在则先备份原文件。
- 调整进程数量：设置 SERVER_WORKER_AMOUNT，遵循 2n+1 原则（n 为 CPU 核数），例如 8 核 CPU 设置为 17。
- 调整超时时间：设置 GUNICORN_TIMEOUT 为 360 秒，适配企业内部可能出现的长任务场景。
- 调整连接数：设置 SERVER_WORKER_CONNECTIONS 为 100，平衡单个进程的负载压力。
- 重启服务：执行 docker compose up -d 使新配置生效。
怎么验证是否生效
配置修改后需确认服务状态及业务表现：
- 执行 docker compose ps 检查所有容器状态是否为 Up 或 Healthy。
- 在 Dify 控制台创建包含大文件解析或多步骤 AI 分析的工作流。
- 观察任务执行过程，确认不再出现超时失败提示。
常见坑
- 直接修改 docker-compose.yaml 会导致版本升级时配置被覆盖，务必使用.env 文件。
- 运行 7B 参数模型仅加载就需要约 14GB 内存，若同时启用知识库功能需进一步增加内存配置。
- Windows 系统部署建议使用 WSL2 后端模式，以获得更好的文件 I/O 性能。
常见问题
模型供应商密钥应该配置在哪里？
密钥不建议写在 docker/.env 文件中，建议在 Dify 控制台的工作区 Model Providers 中按业务模型调用配置。
Windows 部署 Docker 需要注意什么？
确保 Windows 版本支持 WSL 2 并优先使用此模式，安装 Docker Desktop 时勾选 Use WSL 2 instead of Hyper-V。
参考来源
- Dify 社区版部署性能优化：参数配置详解与二次开发实践
- Dify 本地部署实战：从环境配置到服务优化的完整流程
- Windows 系统 Docker 本地部署 Dify 完整指南：从环境准备到功能验证
- Dify 全 Docker 实战_思维导图工作流与 workflow-debug-ui 对接