Dify 部署指南：Dify Docker 部署与云端/K8s 方案对比
详细对比 Dify Cloud, Dify Docker 部署 (Compose) 和 Kubernetes 部署模式的差异及企业级配置建议。
Dify 部署模式精讲
Dify 有三种核心使用模式：
- Dify Cloud 云端 SaaS 模式：支持快速上手，免维护。
- 基于 Docker Compose 的私有化部署模式：适合中小规模或 POC 阶段。
- 基于 Kubernetes (Helm) 的大规模企业版集群部署模式：适合高可用、大规模生产环境。
三种模式对比
| 评估维度 | Dify Cloud (SaaS) | Docker Compose (Private) | Kubernetes (Enterprise) |
|---|---|---|---|
| 适用场景 | 快速 POC、非敏感业务、无运维团队 | 内部工具、数据隐私敏感、中小规模生产 | 大规模对外服务、高可用要求、多租户运营 |
| 数据主权 | 数据存储于 Dify 托管云端 | 数据完全本地化 | 数据完全本地化 |
| 基础设施成本 | 按量付费/订阅制 | 需自备服务器资源 | 需自备集群资源及云服务 |
| 运维复杂度 | 零运维 | 中等（单机管理） | 高（需要 K8s 专业知识） |
| 水平扩展性 | 依赖平台配额 | 受限于单机物理上限 | 原生支持弹性伸缩（HPA） |
| 合规性支持 | SOC2 (依赖平台) | 可完全掌控，易于通过等保/GDPR | 可完全掌控，支持复杂网络隔离 |
具体的区别和价格可以参考：Dify Pricing
一、Dify Cloud 云端 SaaS 模式使用
在决定进行私有化部署前，使用云端版本是一个很好的选择。Dify Cloud 版本（dify.ai）提供了与开源版本一致的功能体验，同时免除了基础设施的维护负担。
使用非常简单：
-
访问 dify.ai，点击 Get Started。
-
您可以使用邮箱、Google 或 GitHub 登录。
-
登录后即可进入工作台，开启您的 Dify 之旅。
二、基于 Docker Compose 的私有化部署
对于拥有一定技术能力的开发者、希望数据私有化的项目，基于 Docker Compose 的部署是标准且高效的选择。
2.1 基础设施准备与环境调优
Dify 包含多个内存密集型组件，资源不足会导致 OOM。
2.1.1 硬件资源基线
- CPU：最低 2 vCPU，建议生产环境 4 vCPU。
- 内存：最低 4GB RAM，建议 8GB RAM（尤其是启用本地向量库时）。
- 磁盘：建议使用 SSD，根分区预留至少 50GB。
2.1.2 软件依赖检查
- Docker Engine：版本 >= 19.03。
- Docker Compose：务必使用 V2（命令为
docker compose）。 - 系统参数：调整
vm.max_map_count以适配向量数据库等组件。sysctl -w vm.max_map_count=262144 echo "vm.max_map_count=262144" >> /etc/sysctl.conf
2.2 部署全流程
步骤 1：获取源代码与版本锁定 建议检出最新的 Tag 版本以确保稳定性。
git clone https://github.com/langgenius/dify.git
cd dify/docker
latest_tag=$(curl -s https://api.github.com/repos/langgenius/dify/releases/latest | jq -r .tag_name)
git checkout $latest_tag步骤 2：环境变量配置
cp .env.example .env以下是部署中必须注意的关键变量清单：
| 变量模块 | 变量名 | 推荐配置 |
|---|---|---|
| 基础安全 | SECRET_KEY | 高危。用于 Session 加密和数据库敏感字段加密。务必执行 openssl rand -base64 42 生成随机字符串。一旦泄露，系统安全性将荡然无存。 |
| Web 访问 | APP_WEB_URL | 前端访问的完整 URL（如 https://ai.corp.com）。用于 OAuth 回调校验和生成分享链接。配置错误会导致 SSO 登录失败或图片无法加载。 |
| Web 访问 | COOKIE_DOMAIN | 若前后端部署在不同子域名下，需设置为顶级域名（如 .corp.com）以共享 Cookie。 |
| 数据库 | DB_HOST | 默认为 db（容器名）。若连接外部 RDS，填写 RDS 的 IP 或域名。 |
| Redis | REDIS_PASSWORD | 默认为空。生产环境务必设置强密码，防止未授权访问。 |
| 向量库 | VECTOR_STORE | 默认为 weaviate。若企业已有 Milvus 集群，可修改为 milvus 并配置相应连接参数。更改此项需同步修改 docker-compose.yaml 以禁用不需要的容器。 |
| 性能调优 | GUNICORN_WORKERS | API 服务的工作进程数。默认为 1。建议设置为 CPU核数 * 2 + 1，以提升并发处理能力。 |
| 性能调优 | CELERY_WORKER_AMOUNT | 异步任务并发数。增加此值可加快知识库导入速度，但会显著增加内存消耗。 |
| 文件存储 | STORAGE_TYPE | 默认为 local。生产环境强烈建议改为 s3。 |
根据需求修改 .env 中的数据库、Redis 和对象存储等配置。
步骤 3：启动与健康检查
docker compose up -d
docker compose ps重点关注 api、worker 和 db 容器。如有异常，查看日志：docker compose logs -f api。
2.3 企业级高阶配置：去容器化中间件
在生产环境中，建议将有状态服务（Stateful Services）外部化。
2.3.1 对接外部 PostgreSQL 与 Redis
修改 .env 文件，指向企业内部的高可用集群。Dify 启动时会自动运行 flask db upgrade。
2.3.2 配置 S3 对象存储（持久化关键）
将 STORAGE_TYPE 设置为 s3，并配置相应的 Endpoint、Bucket 和 Key。这样容器本身将不再持有状态数据，方便迁移和扩容。
三、基于 Kubernetes 的企业级集群部署
当业务规模扩展到数千用户或需要 99.9% SLA 时，建议使用 Kubernetes。
3.1 架构规划
- 无状态服务 (Deployments)：
dify-api、dify-worker、dify-web。建议配置 HPA 自动伸缩。 - 有状态服务 (External)：严禁在生产环境 K8s 内部署核心数据库。建议连接云厂商托管的 RDS、ElastiCache 和云原生向量检索服务。
3.2 Helm Chart 部署流程
helm repo add dify https://borispolonsky.github.io/dify-helm
helm repo update定制 values.yaml：
在 production-values.yaml 中禁用内置数据库并配置外部连接，同时设置资源限制（Resources）和自动伸缩（Autoscaling）。
部署与初始化：
helm upgrade --install dify dify/dify -f production-values.yaml --namespace dify-prod --create-namespace部署完成后，手动执行数据库迁移：
API_POD=$(kubectl get pods -n dify-prod -l app.kubernetes.io/component=api -o jsonpath='{.items.metadata.name}')
kubectl exec -it $API_POD -n dify-prod -- flask db upgrade附录：Dify 微服务架构解构
Dify 的核心由一组微服务构成：
- API Service (Flask)：逻辑大脑，处理 HTTP 请求、权限及 LLM 交互。
- Worker Service (Celery)：执行异步任务，如文档解析、向量嵌入及 Agent 推理。
- Web Service (Next.js)：提供可视化用户界面。
- Redis：充当消息代理 (Broker) 及缓存。
- PostgreSQL：存储元数据（配置、日志、用户数据）。
- Vector Database：存储高维度向量数据（Weaviate, Qdrant 等）。
- Object Storage (S3)：存储非结构化数据（图片、文档原件）。
- Sandbox：安全地执行用户代码。