简介这是一份2025年4月28日发布的Dify原版安装包主要面向因GitHub访问不稳定而无法顺利下载安装的用户下载后即可获得GitHub上的完整项目主体dify-main。Dify作为开源AI应用开发平台该zip包内含Python后端代码、前端界面样式与交互脚本、JSON配置、YAML部署配置、Shell脚本及Markdown说明文档等共2000个文件、约20.29MB便于快速搭建本地环境或离线部署。包内文件以1404个.py为核心逻辑368个.json承载数据与配置103个.css和35个.js支撑界面交互41个.md提供说明与二次开发参考另含少量sh、html、yaml及SQL资源整体结构完整清晰。目前已有244人学习下载适合需在受限网络环境下离线部署Dify的开发者同时也便于学习其项目组织与二次开发。 如果你最近在折腾 Dify 的本地部署大概率经历过这种时刻GitHub 仓库页面转半天打不开压缩包下载到一半直接断掉或者 docker compose up -d 之后一堆镜像卡在 pulling进度条一动不动。Dify 这个项目本身不难装难的是第一步就卡在“安装包都拿不到”。写这篇东西的初衷很简单——就是给 GitHub 访问不稳定的同学一条能走通的路从拿原版 Dify 安装包到 Windows 上把一套社区版跑起来再到启动后常见报错的排查尽量都讲清楚。这篇文章适合两类人一类是网络环境下 GitHub 直连经常会失败的纯新手只想把 Dify 装起来先跑通另一类是企业内网或测试环境里不方便直接访问外部仓库的开发者想拿一份干净的离线安装包自己做部署。标题里那个 20250428 的时间点对应的大概是 2025 年 4 月底发布的 Dify 1.10.x 社区版这个版本把多租户和插件机制往生产环境又推了一大步也是目前很多人入坑时接触到的第一个版本。下面我会以这个版本为例讲一套完整的本地部署流程。1. 先搞清楚Dify 部署卡住到底卡在哪一环1.1 GitHub 直连不稳定只是第一道坎很多人以为 Dify 部署的最大阻力就是“下不下来”其实这只是第一道坎。Dify 的代码托管在 GitHub官方压缩包和 release 产物都在那边访问不稳定时最典型的表现就是仓库页面能打开但 assets 下载超级慢、zip 下到 99% 连接重置、git clone 跑了几分钟直接 fatal。这些问题和你的网速没有必然关系是跨国网络链路本身的抖动导致的。如果你只是为了部署而不是做源码级二次开发我强烈建议不要用 git clone 的方式拿代码。一个完整的仓库带着全部历史提交记录体积比压缩包大得多网络不稳时失败概率也高得多。直接从 GitHub 的 Releases 页面下载对应 tag 的 Source code (zip)文件小、结构干净解压就能用。1.2 真正的复杂度在镜像和组件编排拿到安装包只是开始。Dify 不是单个程序而是一组容器服务nginx 做网关web 是前端api 是后端接口worker 跑异步任务底下还挂着 postgres元数据、redis缓存、weaviate向量数据库、plugin_daemon插件守护、sandbox代码执行沙箱等一堆组件。这些镜像全部托管在 Docker Hub 上而 Docker Hub 的访问速度和稳定性在国内环境中同样不可控。很多人在 zip 下载成功后反而更崩溃——docker compose up -d 之后大半个下午都耗在 pulling 上。所以要部署 Dify必须同时解决两个问题GitHub 的安装包获取以及 Docker 镜像的拉取加速。缺一个都会卡死。1.3 原版安装包为什么值得较真标题里强调“原版”是有道理的。Dify 本身是个开源项目任何从官方仓库导出、未经二次打包的源码压缩包都算原版。但网上也流传着一些第三方“一键安装包”“整合包”这里我要提醒一句Dify 会接触数据库、模型 API Key、外部系统凭据如果安装包被人做过手脚你的敏感信息就全暴露了。安全起见认准 langgenius/dify 官方仓库的 Releases或者从可信的镜像下载站拿不要用来路不明的整合包。2. 安装包怎么拿三条绕过 GitHub 拉取的路子2.1 镜像下载站的通用用法既然 GitHub 直连不稳最简单的方式就是借助 GitHub 镜像下载站。这类站点本质上是对 GitHub 资源做一层缓存中转把原本需要跨国下载的文件放到相对快的节点上你只需要把 GitHub 的原始下载链接拼在镜像站后面。以 Dify 1.10.0 为例原始下载地址是https://github.com/langgenius/dify/archive/refs/tags/1.10.0.zip使用镜像站时通常就是在这个完整地址前面加上镜像站域名https://镜像站域名/https://github.com/langgenius/dify/archive/refs/tags/1.10.0.zip具体用哪个镜像站我建议你搜索“github releases 镜像下载”这类关键词找时间比较新、还能正常打开的站点。这类域名经常变化今天能用的可能下周就维护了所以记住这个 URL 拼接规律比记住某一个域名更实用。2.2 只下 Release 产物别去憋 git clone进入 Dify 的 GitHub 仓库首页右侧栏能看到 Releases 入口。点进去找到 1.10.0 这个版本页面底部会有两个自动生成的源码包Source code (zip) 和 Source code (tar.gz)。这两个文件不经过 git下载速度比 clone 快得多而且不会带上 .git 目录。如果镜像站不支持大文件或者你只有某个具体的 release 资产需要下载也可以先把页面里的下载链接复制出来再用带断点续传的下载工具去拉。下载时注意文件名里要有明确的版本号比如 dify-1.10.0.zip避免拿到旧文件或损坏文件。2.3 拿到包之后先校验再解压下载完成后不要急着解压先做三件事确认文件版本号与你预期一致比如文件名是 dify-1.10.0.zip而不是 1.9.x 或其他版本。确认文件大小合理GitHub 页面会显示 zip 的体积相差太大说明可能下载不完整。确认能正常解压。zip 文件如果在下载中断后又被浏览器“救回来”解压时会直接报 CRC 错误这时候果断重新下载别浪费时间修复。解压后目录里应该能看到 api、web、docker 这几个一级目录以及 README.md、docker-compose.yaml 等文件。如果你拿到的“安装包”连这些基本结构都对不上那就得重新评估来源了。3. Windows 环境准备Docker Desktop 和镜像加速一次配好3.1 安装 Docker Desktop 前确认两件事Dify 官方推荐用 Docker Compose 方式部署在 Windows 上最省事的路子就是装 Docker Desktop。安装前确认两件事第一BIOS 里已经开启虚拟化。打开任务管理器 - 性能 - CPU看“虚拟化”这一项是否是“已启用”。没开启的话Docker Desktop 安装完也起不来。第二WSL2 环境就绪。Docker Desktop 新版本默认用 WSL2 后端在管理员 PowerShell 里执行wsl --install可以安装默认发行版装完重启一次。如果你机器上已经有旧版 WSL建议先wsl --update更新到最新内核再装 Docker Desktop。3.2 配置镜像加速地址这一步是很多人容易忽略的。Docker Desktop 装好后默认从 Docker Hub 拉镜像速度很慢。你需要手动配置镜像加速地址。打开 Docker Desktop进入 Settings - Docker Engine在 JSON 配置里加入 registry-mirrors{ registry-mirrors: [ https://docker.m.daocloud.io, https://docker.1ms.run ] }点击 Apply Restart 让配置生效。需要注意的是公共镜像加速地址并不总是稳定可能过一阵子就失效。如果你有阿里云、腾讯云这类容器服务账号去它们控制台里找“容器镜像服务” - “镜像加速器”会给你一个专属加速地址那个是最稳的注册就能用。配置完成后在命令行执行docker info看输出里的 Registry Mirrors 一栏是否列出了你配置的地址。如果还是空的说明配置没生效重启 Docker Desktop 再检查。3.3 内存和文件共享设置Dify 这套容器全家桶吃内存比较凶。官方建议至少 4GB我实际用下来如果本地同时开浏览器、IDE 和 Dify8GB 以上才舒服。Docker Desktop 的 Settings - Resources 里可以调整 WSL2 的内存和 CPU 上限。内存给小了postgres 和 weaviate 很容易 OOM表现就是容器起来没多久又自动退出。另外如果 Docker Desktop 弹出文件共享权限提示记得把 Dify 所在的目录加进去否则容器挂载磁盘时会一直报权限错误。4. compose 拉起 Dify启动顺序和镜像拉不动的处理4.1 初始化配置进入解压后的 Dify 目录找到 docker 文件夹cd 进去。先把环境变量模板复制一份cd dify-1.10.0/docker cp .env.example .env编辑 .env检查几个关键配置。最重要的是端口默认 nginx 监听 80 端口如果你的机器上 80 已经被 IIS、Apache 或其他服务占用compose 起来后 nginx 会直接退出。这时候把 .env 里的端口变量改一下EXPOSE_NGINX_PORT8080旧版本有的叫 NGINX_PORT以你目录下 .env.example 里实际出现的变量名为准。改完后访问地址就是 http://localhost:8080。然后启动docker compose up -d首次启动会拉很多镜像时间不定取决于你的网络和镜像加速配置。中途如果卡住按 Ctrl C 停掉修复镜像源后重新执行。4.2 镜像拉不动时的手动兜底如果你配置了镜像加速docker compose up 仍然卡在某个镜像上最常见的是 langgenius/dify-api、langgenius/dify-web、langgenius/dify-plugin-daemon 这类大镜像。这时候可以手动拉取给镜像地址加上加速前缀。以 dify-api 为例docker pull docker.m.daocloud.io/langgenius/dify-api:1.10.0 docker tag docker.m.daocloud.io/langgenius/dify-api:1.10.0 langgenius/dify-api:1.10.0docker tag 的作用是把带前缀的镜像重命名成 compose 文件里期待的原始镜像名。compose 启动时如果发现本地已经存在这个 tag 的镜像就会跳过拉取直接使用。把启动时报错的那几个镜像都手动 pull 一遍再重新 docker compose up -d基本就能跑通。4.3 离线 tar 包兜底方案如果你的部署机器是完全离线或 Docker Hub 彻底拉不动的场景就得走 docker save / docker load 的离线方案。前提是你能在另一台网络正常的机器上拉取镜像。先在你自己的环境里把 compose 用到的所有镜像列出来docker compose config --images这个命令会输出 compose 文件里全部镜像的完整名字。然后在可以联网的机器上逐个拉取并保存docker pull langgenius/dify-api:1.10.0 docker save -o dify-api-1.10.0.tar langgenius/dify-api:1.10.0把 tar 文件拷贝到目标机器后docker load -i dify-api-1.10.0.tar把所有镜像都 load 一遍再执行 docker compose up -d。离线 tar 包方案虽然繁琐但好处是版本完全可控适合生产环境和内网部署。5. 启动后的体检初始化失败与容器异常排查5.1 初始化页面进不去compose 起来后浏览器访问 http://localhost或你改过的端口正常情况下会进入 Dify 的初始化页面让你设置管理员邮箱和密码。如果你遇到页面打不开先看容器状态docker compose ps重点看 nginx 容器是否是 Up 状态。如果显示 Restarting 或 Exited多半是端口冲突用命令查netstat -ano | findstr :80能找到占用进程就去改 .env 里的端口变量然后重新启动。改完端口后浏览器不好使先清理一下浏览器缓存或换个无痕窗口因为这个页面有本地缓存容易让你误以为服务没起来。5.2 容器一直 Restarting初始页面能打开但一直转圈或者某个容器反复重启这时候去看完整日志docker compose logs api docker compose logs worker日志里最常见的几类问题内存不足导致 postgres 或 weaviate 被系统杀掉日志尾部通常有 OOM 字样。解决方法是给 Docker 更多内存或者减少同时运行的其他大程序。postgres 数据卷权限问题。如果在 WSL2 环境下出现类似 permission denied 的报错可以尝试把整个 docker 目录删掉.env 先备份重新 compose up。注意这会清掉数据库数据仅限初始化阶段使用。.env 里 SECRET_KEY 被改动过。首次启动后 Dify 会生成 SECRET_KEY 和内部密钥之后保持一致就好别在二次启动前随意替换。5.3 模型与插件问题初始化完成后第一件事是进“设置”里配置模型供应商。Dify 本身不自带模型你要填入 OpenAI、DeepSeek、通义千问等模型的 API Key 和对应 endpoint。这里有个很容易踩的点模型 API 的 endpoint 不要写 localhost 或 127.0.0.1因为请求是从容器内部发出的指向的是容器自己必须填宿主机在局域网中的 IP或者使用云端模型服务。1.10 版本的插件市场页面有时会一直转圈原因是插件市场的数据要从远程拉取网络环境不稳定就会失败。这不影响核心的对话、知识库和工作流功能只是暂时不能在线安装插件。后续需要时可以去插件市场下载 .difypkg 文件在“插件”页手动导入效果是一样的。我自己现在维护本机 Dify 的习惯是拿到一个版本后先把 zip 包和 .env 原文件归档保存下次升级前先备份 .env再备份 postgres 数据卷然后才执行 docker compose pull 和 docker compose up -d。另外一个小技巧是每次改动 .env 或 docker-compose 配置后先跑一遍 docker compose config 验证语法再真正重启。养成这两个习惯之后Dify 这套容器的维护成本会低很多。本文还有配套的精品资源点击获取