正在加载，请稍候
从 docker-compose 起步到企业高可用：Dify 私有化部署的 4 个生产环境必改默认配置、多租户拓扑、模型网关密钥管理与升级踩坑记录。
2026 年上半年我们交付了 7 套私有化 Dify，其中 4 套是从 docker-compose 裸跑升级上来的。这篇文章记录生产环境必须改的默认配置，以及我们踩过的坑。
官方推荐的起步方式是 docker compose 一键起服务。按 2026 年 8 月更新的官方部署文档，最低硬件要求是 CPU ≥ 2 核、内存 ≥ 4 GiB；macOS 上 Docker Desktop 虚拟机建议 2 vCPU + 8 GiB。软件侧要求 Docker 19.03+、Compose 2.24.0+。
docker compose up -d 会拉起 7 个核心服务（api、api_websocket、worker、worker_beat、web、plugin_daemon、agent_backend）、8 个依赖组件（weaviate、db_postgres、redis、nginx、ssrf_proxy、agent_ssrf_proxy、sandbox、local_sandbox）和一次性任务 init_permissions。
这个"最低要求"是能跑的门槛，不是生产可用的基线。我们实测一台 2C4G 机器跑默认栈，导入 2000 份文档后向量库与数据库就把内存吃到 80%，检索开始抖动。生产环境建议 4C8G 起步，并按数据量留 3 倍余量。更完整的 RAG 落地工程细节可参考企业知识库 AI 搭建实战。
docker/.env 里的默认值是"能跑"配置，不是"生产"配置。下面 4 项在每一个企业项目里我们都会改。
默认 compose 把数据库和缓存与 Dify 装在同一台机器、同一套生命周期里。企业内网通常已有 PG 或 Redis 实例，应把 DATABASE_HOST、REDIS_HOST 指到独立实例，复用已有的备份与监控体系。
独立之后要开连接池上限、调 max_connections、给 Dify 单独建库建账号。我们遇到过客户把 PG 默认连接数撑爆、其他业务跟着抖动的案例，根因就是没做这层隔离。
默认文件落在本地卷，文档上传、工作流产物、图片预览会无限增长。生产环境应切到 S3 兼容对象存储（MinIO、阿里云 OSS、腾讯 COS 均可），在 .env 里配 STORAGE_TYPE 与相关变量。
切换要趁早——索引和元数据稳定后再迁移，成本高一个量级。另外官方环境变量里文件签名 URL 默认有效期 300 秒（FILES_ACCESS_TIMEOUT），长任务场景要调大，否则批量导出会频繁报过期。
默认 compose 只暴露 nginx 80 端口，没有限流、没有 WAF。企业知识库开放给全员后，应用密钥泄露或恶意调用会直接烧掉模型配额。
我们一般在这套前面再挂一层网关（OpenResty 或云上 SLB + WAF），按应用维度做 QPS 限流，并把 /v1 路径的调用审计打开。官方文档还提示多 API 副本需要 sticky sessions，网关层要提前规划，否则协作模式与流式请求会断连。
按官方环境变量参考，日志默认输出 text 格式、写到容器内 /app/logs/server.log，单文件 20MB 轮转保留 5 份，时区默认 UTC。这套默认值对生产基本等于没有审计。
生产环境要把 LOG_OUTPUT_FORMAT 改成 json 汇入 ELK 或向量日志平台，LOG_TZ 改成 Asia/Shanghai。谁在什么时间调了哪个知识库、输出了什么，合规审计里必须查得到。
| 配置项 | 默认值 | 生产建议 | 不改的后果 |
|---|---|---|---|
| 数据库/缓存 | 随 compose 同机 | 独立实例 + 连接池上限 | 资源挤占、重启丢失 |
| 文件存储 | 本地卷 | S3/MinIO/OSS | 磁盘膨胀、迁移难 |
| 入口网关 | 裸 nginx 80 | 网关 + WAF + QPS 限流 | 密钥泄露烧配额 |
| 日志 | text / 20MB 轮转 | json + 集中平台 | 审计链路缺失 |
一个常见问题：一套 Dify 给多个部门共用，还是各跑一套？我们的判断标准只有两条：数据隔离等级和升级节奏。
如果只是部门间知识库隔离，一套 Dify + 多工作区 + 权限控制就够，成本最低。如果项目之间要求网络隔离、密钥隔离，或其中一个项目的插件升级可能影响另一个，就拆成多套独立部署。
拆多套时公共组件（模型网关、对象存储、日志）可以复用，Dify 本体各自一套。我们有个客户拆了三套，运维成本约为一套的 1.8 倍，换来的是升级互不阻塞——这个取舍对长期维护很重要。
企业内网通常要同时接 DeepSeek、通义、Qwen 与海外模型。密钥散落在各供应商配置里，一旦某一家限流，整条链路就断。
我们的做法是前面加一层模型网关（One API / LiteLLM 或自研），统一 /v1 入口，网关里做密钥轮换、成本分摊和 fallback：主模型超时 10 秒自动切备用模型。Dify 侧只配网关这一个供应商，密钥不出内网。网关层采购逻辑的变化可以参考Stripe 收购 OpenRouter 的分析。
这套系统我们升级过很多次，挑 3 次有代表性的踩坑：
现在每次升级的标准动作：先 git diff .env.example，备份三份，升级后跑一遍核心链路用例（建应用、传文档、检索、出结果）再放量。
某客户直接用 docker-compose 裸跑 3 个月，所有服务挤在一台 8C16G 机器上。索引库膨胀到 21GB，检索延迟从 300ms 涨到 2.1s，管理员重启一次要 6 分钟。
我们介入后做了三件事：把数据库迁到独立实例、给向量库做分区与定时清理、存储切到 MinIO。恢复后 P95 检索延迟回到 380ms。这个案例的教训就一句话：默认配置不是生产配置，资源基线要按数据量留余量。检索不到内容的排查清单可以参考RAG 落地最常见的 6 个坑，需要长期记忆能力的企业可以看Agent Memory 落地实录。
如果你也在评估私有化知识库或 Agent 平台，可以把现状发给我们，一周内给出架构建议与成本拆解，联系蓝曜炬辉。相关交付经验可参考我们的案例页。
官方基线 2C4G 能跑，生产建议 4C8G 起步，并按文档量留 3 倍余量。
能。多工作区 + 权限控制即可；要求网络或密钥隔离、升级节奏不同再拆多套。
前面加一层模型网关统一入口，密钥管理与 fallback 都放网关层，Dify 只配一个供应商。
对比 .env.example 新增变量，备份数据库、对象存储、向量库三份，升级后跑核心链路用例。