简介面向需要在离线或国内网络环境快速搭建 Dify 的开发者这份 dify-1.3.1 部署包提供了可一键运行的 Docker Compose 安装方案。包内已预置 .env 环境变量与 dify.yaml 编排文件镜像源切换为国内镜像下载速度快解压进入 docker 目录后执行一条命令即可拉起全部服务默认暴露 17880 端口适合内网隔离、低带宽或首次接触容器化部署的团队快速起步。资源共 2000 个文件、压缩包仅 20.31MB其中 1410 个 Python 脚本承载后端 API 与核心业务逻辑370 个 JSON 文件用于配置、插件元数据及多语言文案百余个 CSS/JS 文件实现前端控制台另有 YAML 编排、SQL 初始化脚本和 shell 辅助工具形成从镜像拉取到数据初始化的完整闭环。目前已有 1856 人学习下载除了开箱即用的容器配置还预置了 Nginx 端口、HTTPS 开关、S3 对象存储等关键参数可低成本修改后投入生产或二次开发显著降低 Dify 私有化部署难度。 作为一个常年折腾部署环境的开发者我太清楚大模型应用平台落地时那种“卡在拉镜像”的滋味了。Dify 1.3.1部署包这个标题背后其实对应着一个特别具体的需求如何把 Dify 社区版在国内网络环境里用纯国内镜像源、一条命令装起来。这个方案专治镜像拉取慢、超时、反复重试的毛病适合要本地搭知识库、做工作流、跑 Agent 的团队和独立开发者十分钟内就能把平台跑起来。Dify 是什么刚接触的朋友可能还不熟。它是开源的大语言模型应用开发平台把 RAG 知识库、工作流编排、Agent 智能体、模型供应商统一接入都做成了可视化界面。1.3.1 属于一个非常稳定的迭代版本功能完整社区资料多拿来作为私有化部署的起点很合适。下面我把这套部署包的思路、脚本逻辑和完整操作过程拆开讲清楚按这个流程走你也能在纯国内网络环境里一键装好。1. 先搞清楚 Dify 部署包的定位与核心价值1.1 这个部署包到底解决了什么问题官方标准的 Dify 部署方式是去代码仓库拉取 docker-compose 文件然后执行容器编排命令。逻辑本身不复杂难点卡在“拉取”这两个字上。国内团队在实操中遇到的问题高度一致Docker Hub 上镜像拉取速度不稳定经常跑到一半就超时依赖的基础镜像又多Dify 依赖 nginx、api、worker、web、postgres、redis、sandbox、ssrf_proxy 等一整套容器任何一个镜像失败整个编排就起不来。部署包要干的事情就是把这些不确定性全部干掉。它把 docker-compose 文件里所有镜像地址替换成国内镜像仓库地址同时在 Docker 层配置好镜像加速再把环境检查、目录初始化、容器启动这一整套流程封装成脚本。用户拿到手之后只需要执行一条命令脚本自动完成检测、拉取、编排、启动最后给你输出访问地址和初始化信息。1.2 1.3.1 版本选择背后的考量为什么选 1.3.1 而不是最新的版本我在做部署包的时候专门想过这个问题。Dify 迭代速度非常快几乎每个月都有新版本发布新功能让人眼馋但生产环境部署我更看重稳定性和依赖的兼容性。1.3.1 这个版本在知识库处理、工作流节点、模型接入几个核心模块上都很成熟社区反馈的问题也明牌网上搜得到各种排错方案。对于初次搭建的人来说用一个“已经被社区验证过”的版本比追最新版踩未知的坑要划算得多。另外1.3.1 对服务器配置的要求也相对亲民2核4G 的机器可以流畅跑起来这对很多拿老机器或者云服务器测试的团队非常友好。1.3 纯国内镜像的完整链路设计“纯国内镜像”不是指只把 compose 文件里的镜像地址换掉就完了它包含三个层面。第一层是 Docker 容器镜像也就是 nginx、api、worker 这些镜像的下载源全部走国内可稳定访问的镜像仓库服务。第二层是系统层面的加速配置也就是 Docker daemon 的 registry-mirrors 配置这能覆盖部分官方镜像的拉取加速。第三层是 Dify 平台内部访问外网模型API的通道这个取决于你实际使用的模型服务地址。部署包把前两层做了强处理第三层留给使用者在平台后台配置模型供应商的时候自行选择。所以这套方案在整个容器基础设施链路里做到了完全国内化不依赖任何境外网络路径。2. 环境准备和镜像方案选型部署前的关键决策2.1 服务器环境需要满足什么条件一键安装不等于无脑安装前置条件还是要满足的。操作系统建议使用 Ubuntu 20.04 及以上版本、Debian 11 及以上版本CentOS 7 也可以跑但 Docker 版本别太老。内核版本建议 4.18 以上避免一些存储驱动的问题。Docker 需要 19.03 以上版本Docker Compose V2 插件也要装好如果你机器上还在用 docker-compose 老方案脚本里我已经做了兼容处理两种都会识别。内存方面2GB 是底线4GB 比较稳妥如果同时跑知识库索引任务和多个对话会话建议 8GB。磁盘至少留 20GB 的可用空间Dify 全套镜像压缩包拉下来大概 3GB 左右运行后还会有日志、索引数据、上传文件这些持续增长的数据。装之前用 df -h 看一眼磁盘别等拉镜像拉到一半才发现 /var/lib/docker 所在分区满了。2.2 Docker 镜像加速配置的几种落地方式Docker 镜像加速的配置逻辑很简单修改 /etc/docker/daemon.json把 registry-mirrors 加上去然后重启 Docker 服务。部署包里写的是这样一段{ registry-mirrors: [ https://docker.m.daocloud.io, https://dockerproxy.net, https://docker.mirrors.ustc.edu.cn ], log-driver: json-file, log-opts: { max-size: 20m, max-file: 3 } }注意我除了配置镜像加速还把日志驱动的大小做了限制。这个坑是我踩过的Dify 的 API 容器在某些情况下会产生大量日志如果不限制一个礼拜就能吃掉几个G的磁盘。max-size 20m、max-file 3 的意思是单个日志文件 20MB最多保留 3 个够用又控制空间。不过要提醒一点镜像加速服务在不同地区和时段稳定性会有差异如果拉取速度不理想可以换其他可用的国内镜像加速地址或者直接让运维同事帮忙找一个内网镜像仓库。2.3 docker-compose 文件里的镜像地址替换策略Docker 加速解决了平台基础镜像的拉取问题但 Dify 自己的业务镜像包括 langgenius/dify-api、langgenius/dify-web 这些地址还是在 Docker Hub 上。部署包里的做法是在 compose 文件中把这些镜像地址全部替换成国内镜像仓库的镜像路径。具体替换逻辑分两类一类是直接把 langgenius 这个组织名下的镜像从 docker.io/langgenius 换成可用的国内镜像仓库地址另一类是开放平台这些基础镜像保持仓库路径不变依赖 Docker daemon 层面的加速配置。这里有个细节容易踩坑不同国内镜像仓库对 Docker Hub 上不同镜像的支持程度不一样有的同步快有的同步慢甚至有的镜像仓库已经停止同步某些镜像。所以交付给使用者的 compose 文件最好把每个镜像服务地址都验证过一遍确认能拉下来再发出去。我在打包的时候会写一段批量拉取验证脚本把 compose 文件里所有镜像逐个拉一遍失败的一目了然再据此调整镜像仓库地址。3. 一键安装脚本的实现逻辑拆解3.1 压缩包里到底包含哪些东西部署包解压之后目录结构是这样的dify-1.3.1-offline/ ├── docker-compose.yaml ├── .env ├── install.sh ├── uninstall.sh ├── upgrade.sh ├── configs/ │ └── daemon.json └── README.mdinstall.sh 是主角它负责从环境检查到服务启动的全流程。docker-compose.yaml 是经过镜像地址替换之后的编排文件。.env 里面保存了基础环境变量包括 SECRET_KEY、POSTGRES_PASSWORD、DB 配置这些。upgrade.sh 是升级脚本为什么单独放后面讲数据备份的时候会具体说。3.2 脚本执行流程五步完成部署安装脚本的核心逻辑分五步每一步都有明确目的。第一步检查 Docker 和 Docker Compose 是否安装检查端口占用情况Dify 默认要占用 80 端口如果机器上有 Nginx 或者其他 Web 服务先处理好冲突。第二步初始化环境和数据目录。脚本会创建 ./volumes 目录这个目录用于存放 PostgreSQL 数据、Redis 持久化数据、Milvus 或 Weaviate 向量数据库数据、上传文件等。这里有个关键设计理念所有容器都不在容器内部保留数据全部挂载到宿主机目录以后升级、迁移、备份都有操作空间。第三步写入 Docker 加速配置。脚本会把 configs/daemon.json 复制到 /etc/docker/daemon.json然后重启 Docker。已经跑着别的重要容器的同学要注意这一步重启 Docker 会让所有容器短暂停止脚本在执行前会有一次交互确认询问。第四步执行 docker compose pull 把镜像预先拉取到本地。预拉取的好处是能直观看到进度和失败项比直接 up 启动之后再发现镜像缺失要清晰得多。第五步docker compose up -d 启动服务然后执行健康检查脚本等待所有容器变成 healthy 状态最后把管理员初始化地址和控制台地址提示给用户。3.3 .env 环境变量的配置细节.env 文件里的配置直接决定 Dify 运行时的数据库连接、密钥管理、日志级别等行为。部署包内置的默认值里SECRET_KEY 是随机生成的POSTGRES_PASSWORD 也是随机生成的第一次启动前会写一份备份在 configs/ 目录。这样做的好处是多个开发者协作部署时不会因为“所有人用了同一个默认密码”而产生安全隐患。EXPOSE_NGINX_PORT 默认是 80如果你机器上 80 端口被占用了可以改成 8080 之类的高位端口。有了这个变量Dify 对外访问地址就变成了 http://服务器IP:端口。3.4 为什么要做预拉取镜像这一步很多人在手工部署的时候喜欢直接 docker compose up -d让 Compose 自己拉镜像。这个操作在官方源环境下确实省事但在国内网络环境下就可能变成了“灾难现场”——拉取过程中途失败Compose 会不断重试每次重试都是漫长的等待期间整个编排处于一个不可用状态。部署包里单独拆出 pull 步骤本质上是把不可控的过程变成可控过程先确保所有镜像都在本地启动的时候即使某个容器起不来问题也只会在容器配置层面不会再出现镜像层面的反复重试。这个思路在交付部署包时非常重要因为你没法预料使用者的网络环境能把不可控因素前置消化就尽量前置。4. 完整实操部署流程照做就能跑通4.1 Linux 服务器上的完整安装步骤拿到部署包后先把包传到服务器上比如放到 /opt 目录解压tar -zxvf dify-1.3.1-offline.tar.gz cd dify-1.3.1-offline然后给脚本赋予执行权限直接运行一键安装命令chmod x install.sh ./install.sh脚本开始执行后你会看到几行彩色提示脚本里我用普通文本做的区分中间有一次交互确认询问是否确认执行 Docker 重启操作输入 yes 继续。之后就是镜像预拉取过程这个过程长短取决于网络状态快的话一两分钟慢的话五到十分钟。全部镜像 Pull 成功后脚本自动执行 docker compose up -d接着进入健康检查环节等待容器进入 healthy 状态。整个脚本跑完终端会输出类似下面这样的信息访问地址: http://服务器IP/ 初始化管理员地址: http://服务器IP/install 默认端口: 80 PostgreSQL/Redis/向量库数据已挂载到 ./volumes 目录 请尽快访问 /install 完成管理员初始化看到这几行字说明部署成功。第一次访问会进入初始化页面需要设置管理员邮箱和密码这是整个部署过程的第一个交互动作。4.2 Windows 环境用 Docker Desktop 怎么处理很多开发者的本地机器是 WindowsDify 在 Docker Desktop 上跑也没有问题。部署包里针对 Windows 写了一个 install.bat逻辑和 install.sh 一致不过有几个适配改动。Docker Desktop 在 Windows 上的路径处理方式不一样脚本里用 %~dp0 来获取脚本所在目录所有相对路径都以这个为基准。另外 Docker Desktop 的 daemon.json 配置不建议手动改脚本会检测到当前是 Docker Desktop 环境跳过 daemon 配置这一步镜像加速逻辑通过 Docker Desktop 的图形界面设置改完设置之后需要点击 Apply Restart。Windows 环境下跑 Dify我建议至少给 Docker Desktop 分配 4GB 内存不然同时跑 postgres、redis、sandbox、api 这些容器内存很容易吃紧。在 Docker Desktop 的 Settings - Resources 里调整改完重启 Docker 才能生效。Dify 启动之后Windows 本机访问 http://localhost/install 就能进入初始化界面。有一点要提醒从 Docker 容器里访问宿主机服务要用特殊地址这个在配置模型供应商时如果用到本地模型服务会碰到后面会讲。4.3 初始化后台和管理员账号配置浏览器打开初始化地址之后第一步是设置管理员账号。Dify 管理员的邮箱和密码一定要记好这是平台唯一的超级管理员入口以后配置模型供应商、管理成员、调整系统设置都需要这个账号。管理员创建完成后进入平台第一件事建议先到右上角头像进入“设置”里边的“模型供应商”页面添加模型。Dify 支持 OpenAI 格式兼容的接口、Ollama 本地模型、Azure OpenAI、国内大模型服务等多种方案。如果本地部署了 Ollama模型的 Base URL 在 Linux 服务器上填 http://localhost:11434但在 Docker Desktop 环境里要填 http://host.docker.internal:11434这个区别很多人会踩我专门列出来。配置好模型之后就可以新建应用了。Dify 有聊天助手、文本生成、Agent、工作流多种应用类型第一次用建议从“聊天助手”开始选好模型然后在“编排”页面拖几个节点试试配合右上角的调试对话很快就能理解整个平台的交互逻辑。5. 常见问题与排查技巧实录避坑从这里看5.1 镜像拉取失败的几个典型场景镜像拉取失败是部署过程中最常遇到的问题。第一种情况是提示 manifest unknown这说明当前镜像仓库里没有这个镜像版本解决办法是换一个同步更及时的国内镜像服务地址。第二种情况是连接超时通常是当前镜像仓库服务暂时不可用可以在配置里多写几个备选加速地址Docker 会按顺序尝试。第三种情况比较隐蔽镜像确实拉下来了但是 digest 校验不一致这是老版本 Docker 偶尔会出现的缓存问题执行 docker system prune -a 清掉缓存再试。部分镜像仓库存在配额限制频繁拉取同一个大镜像会触发限流报错信息里通常会出现 rate limit 字样此时换一个镜像服务地址或者等几分钟再试就行。5.2 容器启动失败怎么定位镜像全部就绪之后容器还是有可能会启动失败。最常见的是 postgres 容器反复重启打开日志看基本都是数据库目录权限问题或者密码不一致导致初始化失败。遇到这种问题处理方案是先 docker compose down 彻底停掉所有容器然后删除挂载目录里 postgres 对应的数据目录再把 .env 里的 POSTGRES_PASSWORD 改成一个新值重新 docker compose up -d。注意这里删除数据目录意味着数据库会清空重来如果你里面有重要数据先把 volumes 目录整个备份一份再操作。api 容器启动失败的另一个常见原因是环境变量里 SECRET_KEY 为空或者格式不对。SECRET_KEY 是 Dify 用来做会话加密和数据签名的关键密钥部署包生成之后不建议频繁改动改了会导致已登录用户会话失效。查看容器状态的命令部署包里也封装好了docker compose ps 可以看所有容器的运行状态docker compose logs -f api 可以实时看某个容器的日志。排查问题时优先看 db、redis、api、web 这四个核心容器的状态和日志。5.3 数据备份与升级的操作要点Dify 跑起来之后最重要的就是数据。数据库在 postgres 容器里向量数据在向量数据库容器里上传文件在 volumes/upload_files 目录里。部署包里的 upgrade.sh 脚本执行的动作就是先 docker compose down然后把 volumes 目录整个打包成带时间戳的 tar.gz放在同级目录的 backups 文件夹下再拉取新版本镜像docker compose up -d。备份容器数据不能只备份镜像镜像只是程序的代码包数据全在 volumes 挂载目录里。我见过不少同事以为 docker commit 一下容器就能备份这个思路对 Dify 不适用commit 出来的镜像既不完整也不可靠正确做法永远是备份 volumes 目录。恢复的时候把备份文件解压回 volumes 目录启动旧版本镜像即可。5.4 资源占用和性能优化建议如果你跑了一段时间发现 Dify 响应变慢先查内存和磁盘。docker stats 命令可以实时看每个容器的 CPU 和内存占用正常情况下 api 容器内存占用是最高的随着会话数增加会持续增长。如果内存持续居高不下可以重启 api、worker 这两个容器释放内存。日志增长也是个容易被忽视的问题部署包里 daemon.json 已经配置了日志轮转但如果你是用手工方式部署没配置这段建议尽快补上。另外 Dify 平台内部的日志级别也可以在 .env 里把 LOG_LEVEL 从 INFO 改成 WARNING能明显减少日志文件增速。磁盘空间不足时先用 docker system df 看 Docker 占用的空间构成然后 docker image prune 清理悬空镜像docker builder prune 清理构建缓存。这几个命令建议加到日常维护的脚本里定时执行能防止磁盘被慢慢吃满。6. 结尾说说我在实际使用中的体会部署包这个东西做得越多越明白一个道理真正帮到人的不是那一堆命令而是把“为什么这么做”想清楚。比如为什么要预拉取镜像为什么要单独做备份目录为什么要限制日志大小每一条都是有人在真实环境里踩过坑之后沉淀下来的。我建议你第一次部署时不要只盯着“跑起来”而是把脚本里每一段逻辑都读一遍遇到不懂的配置就去查文档这样以后做二次开发、排查问题、升级版本都会从容很多。最后再分享一个小技巧。部署包里的 .env 文件建议你在首次部署完成后复制一份改名为 .env.backup 保存起来。这个文件里有 Dify 的 SECRET_KEY 和数据库密码以后万一误删环境变量或者容器配置错乱拿这份备份就能快速恢复。很多人不重视这一步等到数据库连不上、所有会话失效的时候才后悔那就晚了。多花一分钟省下后面半天排错时间这笔账怎么算都划算。本文还有配套的精品资源点击获取