Dify 离线部署实战：如何在无网环境中搭建本地 AI 应用平台
企业级 AI 应用的落地，往往面临一个现实问题：服务器不能联网。
这在金融、政务、军工等对安全合规要求极高的场景中尤为常见。而像 Dify 这类基于容器的现代化 LLM 开发平台，默认依赖大量在线资源（如docker pull和git clone），直接部署几乎不可能。于是，“离线安装”就成了绕不开的一环。
但离线部署真有那么难吗？其实不然。只要理清流程、掌握关键技巧，哪怕是在完全断网的内网服务器上，也能在半小时内跑起完整的 Dify 服务。
我们不妨从一次典型的失败尝试说起。
某客户在私有云中准备了一台 CentOS 7 虚拟机，按照官方文档执行：
git clone https://github.com/langgenius/dify.git cd dify/docker docker compose up -d结果报错：
ERROR: manifest for langgenius/dify-api:0.6.10 not found原因显而易见：镜像拉取失败。Docker 默认会尝试从公网仓库下载，但在离线环境下这条路走不通。
真正的解决思路是——预加载。
也就是先在一台可以上网的“中转机”上把所有需要的东西打包好，再迁移到目标服务器本地加载。整个过程就像往沙漠运水：你得提前把水装进桶里带进去，而不是指望到了现场还能挖井。
Dify 本身是一个典型的微服务架构系统，前端、API、Worker、数据库、向量库全都独立运行在各自的容器里。它的docker-compose.yml文件定义了七到八个核心服务：
dify-api：处理业务逻辑dify-worker：异步执行任务（比如文档解析）dify-web：前端界面nginx：反向代理postgres：存储应用元数据redis：缓存和任务队列weaviate或qdrant：向量数据库，支撑 RAG 功能
这些镜像加起来超过 2GB，且分布在不同的公共仓库中。如果不能一次性准备好，后续逐个排查缺失镜像将非常耗时。
所以第一步不是写配置，而是构建完整的离线包。
你需要一台能联网的机器作为中转机，可以是本地开发机、跳板机或测试服务器。在这台机器上完成以下动作：
首先克隆源码，并切换到稳定版本分支。别用main，生产环境一定要锁定版本：
git clone https://github.com/langgenius/dify.git cd dify git checkout v0.6.10 # 查看 tag 列表：git tag -l | sort -V进入docker/目录，打开docker-compose.yml，找出所有image:字段对应的镜像名。例如：
services: api: image: langgenius/dify-api:0.6.10 worker: image: langgenius/dify-worker:0.6.10 web: image: langgenius/dify-web:0.6.10 nginx: image: nginx:1.24-alpine redis: image: redis:7.0-alpine db: image: postgres:15-alpine vector-db: image: semitechnologies/weaviate:1.19.0把这些镜像全部拉下来。你可以手动一个个docker pull，但更高效的方式是写个脚本：
#!/bin/bash IMAGES=( "langgenius/dify-api:0.6.10" "langgenius/dify-worker:0.6.10" "langgenius/dify-web:0.6.10" "nginx:1.24-alpine" "redis:7.0-alpine" "postgres:15-alpine" "semitechnologies/weaviate:1.19.0" ) for img in "${IMAGES[@]}"; do echo "正在拉取: $img" docker pull "$img" done等所有镜像都下载完成后，接下来就是“封箱”操作：把它们导出为.tar文件。
Docker 提供了save命令，可以把镜像保存成归档文件：
mkdir -p /tmp/dify-offline/images docker save langgenius/dify-api:0.6.10 > /tmp/dify-offline/images/dify-api.tar docker save langgenius/dify-worker:0.6.10 > /tmp/dify-offline/images/dify-worker.tar docker save langgenius/dify-web:0.6.10 > /tmp/dify-offline/images/dify-web.tar docker save nginx:1.24-alpine > /tmp/dify-offline/images/nginx.tar docker save redis:7.0-alpine > /tmp/dify-offline/images/redis.tar docker save postgres:15-alpine > /tmp/dify-offline/images/postgres.tar docker save semitechnologies/weaviate:1.19.0 > /tmp/dify-offline/images/weaviate.tar然后连同源码一起压缩成一个离线包：
cd /tmp tar -czf dify-offline.tar.gz dify-offline/最终你会得到一个dify-offline.tar.gz文件，里面包含了：
- 所有必需的 Docker 镜像（
.tar格式） - Dify 源码（含
docker-compose.yml和.env.example）
这个包可以通过 U盘、内网FTP、scp 等方式传送到目标服务器。
到了离线服务器后，解压并进入目录：
tar -xzf dify-offline.tar.gz -C ~/ cd ~/dify-offline结构大致如下：
dify-offline/ ├── images/ │ ├── dify-api.tar │ ├── dify-worker.tar │ └── ... └── dify/ └── docker/ ├── docker-compose.yml └── .env.example现在开始加载镜像。同样建议写个脚本自动化处理：
#!/bin/bash cd images/ docker load < dify-api.tar docker load < dify-worker.tar docker load < dify-web.tar docker load < nginx.tar docker load < redis.tar docker load < postgres.tar docker load < weaviate.tar echo "✅ 所有镜像加载完毕"运行前记得加权限：
chmod +x load_images.sh ./load_images.sh验证是否成功：
docker images | grep -E "(dify|weaviate|nginx|redis|postgres)"看到七条记录就说明没问题。
接下来是配置环节。
Dify 使用.env文件管理环境变量，我们需要复制模板并修改关键参数：
cd ../dify/docker cp .env.example .env vim .env重点关注以下几个部分：
COMPOSE_PROJECT_NAME=dify WEB_PORT=80 POSTGRES_PASSWORD=your_secure_password REDIS_DB=0 WEAVIATE_API_KEY=your_weaviate_key API_SERVICE_API_KEY=abc123xyz这里有几个坑新手容易踩：
- 密码太简单会导致 Weaviate 启动失败—— 它对安全性较敏感，建议使用包含大小写字母+数字的组合。
- 端口冲突—— 如果服务器已有服务占用了 80 端口，记得改成 8080 或其他可用端口。
- 变量命名错误—— 比如把
WEAVIATE_ENDPOINT写成VECTOR_DB_URL就会连接不上。
改完之后就可以启动了：
docker compose up -d首次启动时间较长，尤其是 Weaviate 初始化向量引擎时可能卡住几分钟，属于正常现象。
查看状态：
docker compose ps理想输出应该是所有服务都处于running状态。
如果某个服务反复重启，比如dify-api-1，不要慌，先看日志：
docker logs dify-api-1常见问题是数据库连接失败，通常是因为POSTGRES_HOST没填对，或者dify-db-1容器还没完全就绪就被调用。可以稍等片刻再重试。
另一个高频问题是页面显示 502，这时重点查nginx和api的日志：
docker logs dify-nginx-1如果是 “connect to upstream failed”，说明后端没起来，继续追api日志即可。
一切正常后，打开浏览器访问服务器 IP 地址。
首次使用会跳转到注册页，创建第一个管理员账号。
登录后可以选择新建一个“问答助手”应用，试试最基础的功能：
- 添加 Prompt 节点，输入提示词：
你是一个中文 AI 助手，请用简洁语言回答用户问题。 - 点击「调试」面板，发送一条消息：“你好”
- 观察是否有回复返回
如果有，说明核心链路通了。
想进一步验证 RAG 能力？上传一份公司制度 PDF，等待自动切片和向量化完成后，在 Prompt 中开启“知识检索”，然后提问：“年假怎么申请？” 如果能准确返回原文片段，那就说明整套 AI Agent 流程已经打通。
当然，实际部署中总会遇到些小波折。
下面是一些我亲身踩过的坑及应对方法：
- Weaviate 启动失败，报错内存不足
解决方案：确保主机至少有 8GB 内存。若物理内存不够，务必开启 swap 分区。另外关闭 SELinux，避免权限干扰。
- 文档上传后不索引，worker 卡住
查看dify-worker-1日志：bash docker logs dify-worker-1
若发现 Celery 无法连接 Redis，检查.env中的REDIS_HOST是否为redis（对应 compose 中的服务名）。
- 注册后无法登录，提示会话失效
很可能是 Redis 数据异常。尝试重启：bash docker restart dify-redis-1
- 启动时报错“no such image”
说明镜像没加载全。重新运行load_images.sh，并确认每个.tar文件都存在且非空。
整个过程听起来步骤不少，但实际上只要前期准备充分，后期部署非常顺畅。我自己做过多次演练，最快的一次从解压到网页可访问只用了 18 分钟。
更重要的是，这套方法具有很强的复用性。一旦你有了第一个离线包，就可以把它固化为标准交付物，下次部署同类项目时直接复用，效率提升显著。
如果你所在的企业经常需要做私有化交付，我建议把这套流程进一步标准化：
- 将镜像打包、加载、配置初始化写成一键脚本
- 结合 Harbor 搭建内部私有镜像仓库，实现统一分发
- 对接 CI/CD 流水线，自动构建离线包版本
甚至未来还可以升级为 Kubernetes 部署，利用 Helm Chart 实现高可用集群模式。
Dify 正在成为企业构建 AI 应用的事实标准之一。它把复杂的 LLM 工程抽象成可视化的节点编排，让非算法背景的开发者也能快速上手。
而在封闭网络环境下完成部署，不仅是技术能力的体现，更是项目能否落地的关键一步。
掌握了这套离线部署的方法论，你就不再只是“会用工具的人”，而是真正具备了将 AI 能力输送到任何环境的能力。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
