Dify 是一个开源 LLM 应用开发平台，拖拽式编排工作流、挂知识库、管模型 Key，Docker Compose 一条命令起 15 个容器。官方最低要求 2 核 4G，我在 2 核 4G 的 VPS 上实测：全套跑起来空闲占用约 2.6G，上传一份文档做向量化时冲到 3.5G，4G 机器必须配 2G 以上 swap 才稳，最好砍掉不用的向量库容器。 这是 2026 年 10 月的实测数据，机器是 Debian 12、40G 盘。
上一篇让 Workers Cron 定时干活，这篇回到 VPS 自建这条线。想私有化 Dify 的理由很直接：知识库文档不出自己服务器，模型 Key 不交给第三方平台。部署本身不难，难点在 4G 内存的账本和几个没人提前告诉你的坑。
先看账本：15 个容器各吃多少？
结论：api 和 worker 是大头，postgres 和 redis 常驻合计约 600MB，weaviate 向量库空闲也要 400MB+，不用知识库可以先砍掉它。
部署完 docker stats 抓的空闲基线（实测值，四舍五入）：
| 容器 | 空闲内存 | 作用 |
|---|---|---|
| dify-api | ~500MB | 核心接口 |
| dify-worker | ~400MB | 异步任务（向量化在这） |
| dify-web | ~120MB | 前端静态 |
| db_postgres | ~350MB | 业务数据库 |
| redis | ~200MB | 队列与缓存 |
| weaviate | ~450MB | 向量库 |
| sandbox / ssrf_proxy / nginx 等 | ~300MB | 沙箱与代理 |
| plugin_daemon 等 | ~280MB | 插件体系 |
| 合计 | ~2.6G | 4G 机器可用余量约 1.2G |
上传一份 20 页 PDF 做知识库索引时，worker 冲到 1.1G，总占用摸到 3.5G。没有 swap 的话这一下就触发 OOM（排查 OOM 的完整套路我单写了一篇，发布后在相关阅读里）。官方硬件要求写在 Dify Docker Compose 部署文档，它给的「内存 >= 4 GiB」是底线值，我的实测建议：只跑对话应用砍 weaviate，知识库全功能上 8G。
第一步：拉代码、配环境变量
结论：git clone 官方仓库进 docker 目录，cp .env.example .env，SECRET_KEY 必须当场生成并妥善保管，丢了等于知识库清零。
$ git clone https://github.com/langgenius/dify.git
$ cd dify/docker
$ cp .env.example .env
$ openssl rand -base64 42 # 生成 SECRET_KEY
.env 里至少改三处：SECRET_KEY 用上面命令的输出；EXPOSE_NGINX_PORT=80 如果被占用改 8080；VECTOR_STORE=weaviate 保持默认即可。官方文档要求 Docker Compose 2.24.0 以上，先 docker compose version 确认，老版本会报一堆看不懂的错。
第二步：启动与初始化
结论：docker compose up -d 后等三到五分钟，浏览器开 /install 建管理员账号，ps 确认所有容器 Up 或 healthy。
$ docker compose up -d
$ docker compose ps
$ curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1/install
200
init_permissions 容器显示 Exited 是正常的，它只是初始化文件权限。第一印象是容器多：15 个服务加起来镜像下载 3G 多，小盘机器先 df 看一眼再拉。
第三步：接模型，OpenAI 兼容接口最省事
结论：设置 → 模型供应商，选 OpenAI-API-compatible，填 new-api 这类聚合网关的地址和 Key，一个入口管所有模型。
我没有直连任何一家模型商，用的是之前部署的 new-api 聚合网关：Dify 里只配一个供应商，地址填网关，Key 填网关签发的令牌。好处是换模型、控额度都在网关层做，Dify 侧不用动。本地 Ollama 也能接，供应商列表里有现成选项，base_url 指到 Ollama 服务即可。
第四步：SECRET_KEY 丢失恢复现场
结论：SECRET_KEY 加密着所有存储的凭据，.env 丢了或换了，登录后模型 Key 全部解不开，知识库向量与源文件还在但关联配置要重配。
这是我踩的最疼一坑。机器重装过一次 Docker，.env 没备份，起来后平台正常登录、知识库列表都在，点开模型供应商一片空白，测试连接全部报解密失败。恢复路径：如果旧 .env 还在，直接恢复旧 SECRET_KEY 最快；彻底丢了就只能重新录入所有模型 Key、重建工作流里的凭据引用。postgres 里的数据没坏，坏的是加密层。
防住它只要两步：
$ cp .env /opt/backups/dify-env-$(date +%F) # 每次 .env 变更后手动备份
$ echo "/opt/dify/docker/.env" >> /etc/rsync-exclude.txt # 同时纳入异地备份白名单
第五步：4G 机器的性能取舍
结论：砍 weaviate、调小并发、加 swap，三招让 4G 机器稳住全功能；知识库重度使用就该加内存。
- 砍 weaviate：.env 里
VECTOR_STORE换成 qdrant 或干脆不开知识库功能，docker compose up -d时用--scale或注释掉服务。 - 调小 worker 并发：
.env里SERVER_WORKER_AMOUNT=1，CELERY_WORKER_AMOUNT调小，向量化慢一点但不炸内存。 - swap 保底：2G swap +
vm.swappiness=10，实测上传文档冲高时 swap 吃掉 800MB，机器不卡死。
配额参数官方说明在 Dify 环境变量文档。
踩坑汇总
结论：三个坑，SECRET_KEY、镜像拉取、80 端口冲突，前两个会丢数据，最后一个只是烦。
- SECRET_KEY 没备份：前文写透了，.env 当配置文件管，纳入备份体系。
- 镜像拉取失败：GitHub Container Registry 在国内网络不稳，配 Docker 镜像加速器或用代理拉镜像，15 个容器分批 pull 减少单次失败重头来的痛苦。
- 80 端口冲突：机器上已有 Caddy/Nginx 的话，改 EXPOSE_NGINX_PORT 并在反代上配
proxy_read_timeout 300，知识库向量化请求耗时超过默认超时会 504。
部署完怎么验证它真的稳？
结论：三道验证——空闲基线复测两小时、向量化冲高复测一次、容器重启演练一遍，三关都过才算稳，不是 up 完没报错就算完。
我的验证清单，比官方文档多出来的部分都在这：
- 空闲基线：
docker stats --no-stream隔 30 分钟抓两次，波动 <5% 说明没有隐性泄漏。Dify 部署完当天我抓了 4 次，2.6G 上下浮动 80MB，正常。 - 冲高复测：同一份 PDF 删掉重传，模拟最重的向量化路径，盯
free -m的 available 列。第二遍比第一遍慢了约 15%，worker 内存冲高一致在 1.1G 附近，可接受。 - 重启演练：
docker compose down && up -d一遍，确认 postgres volume、redis 队列、知识库索引全部完好——这次演练还真发现了问题：weaviate 容器重启后索引要热加载约 40 秒，期间对话应用报「知识库不可用」，后面在反代加了重试才消掉。
验证别省。三个容器里任何一个重启后的冷启动行为，只有演练过你才知道，线上第一次重启永远是深夜。
常见问题
Q：Dify 和 n8n 怎么选？
A：重 LLM 应用（知识库问答、Agent 工作流）选 Dify，重系统集成（对接几十个 SaaS、定时自动化）选 n8n，两者我也都部署过，定位差异明显，不冲突。
Q：知识库文档规模有上限吗？
A：软件层面没有硬上限，瓶颈在向量库容量和索引耗时。4G 机器实测 20 页 PDF 向量化约 1 分钟，几百份文档建议上独立向量库服务。
Q：能升级吗？升级会丢数据吗？
A：能。git pull 后对照新版 .env.example 补变量，docker compose pull && up -d。postgres 数据在 volume 里不丢，但升级前务必备份 .env（SECRET_KEY）和数据库 volume。
Q：白嫖玩家有别的路吗？
A：Claw 免费容器那篇的思路在 Dify 上不完全适用，15 个容器 3G 内存超出免费容器额度，轻量需求建议直接用 Dify 云版免费档或换更轻的方案。