简介本资源为 Dify 官方开源项目的完整源码安装包面向 AI 应用开发者、低代码平台实践者及大模型应用构建者用于本地快速部署可扩展的 LLM 应用编排平台。压缩包含 2000 个文件主体为 1337 个 Python 模块实现后端服务、Agent 编排与插件系统、366 个 JSON/YAML 配置文件含环境变量、工作流定义与模型参数模板以及 84 个 JS、116 个 CSS 和 38 个 Markdown 文档支撑前端界面、主题样式与使用说明包体大小 20.25MB结构清晰含 dark/light 主题样式、模块化 CSS 文件如 editor.main.css、index.module.css 等及完整 CLI 脚本.sh与数据库迁移脚本.sql。目前已有 2661 人学习下载用户可直接解压即得开箱可用的工程骨架涵盖前后端全栈代码、配置范例、部署指南与主题定制资源便于二次开发、功能调试与私有化部署。1. Dify 官方安装包从 GitHub 下载不是点个 ZIP 就完事本地部署卡在docker-compose up的人90% 栽在「没看清 release 分类」和「SSL 验证翻车」这两步上你搜“dify官方安装包 github下载”大概率是刚看完 Dify 官网文档、想本地跑通一个可编辑的后台但发现官网只给 Docker 快速启动命令没提供离线安装包或者你公司内网不能直连 GitHub需要提前把镜像、二进制、compose 文件全拉下来——这时候你真正要的根本不是“怎么下 ZIP”而是如何确保下载的是官方签名 release、不被中间篡改、能跳过网络校验、且 compose 启动后不报an error occurred during credentials validation或SSL certificate verify failed。这不是纯前端部署Dify 后端依赖 PostgreSQL、Redis、Qdrant知识库、以及可选的 MinIO文件存储所有服务的 TLS 配置、证书挂载路径、环境变量拼写错误都会让docker-compose up -d启动后立刻docker ps看不到容器或docker logs dify-web-1里刷满Connection refused。本文只讲「从 GitHub Release 页面拿到可离线部署的完整物料包」这一件事覆盖 Linux/macOS/Windows WSL 三端实操不碰任何非官方分支、不推荐 fork 仓库、不教改源码——因为 Dify 社区版 1.10 已支持多租户和在线升级你没必要自己编译。2. 用ghCLI 或curl jq精准定位官方 release绕开 GitHub 页面加载慢、镜像站版本滞后、diplay github等混淆词干扰Dify 的官方 GitHub 仓库是https://github.com/langgenius/dify注意不是shihabal3amri/diplay这是另一个叫 Diplay 的独立项目和 Dify 无关、也不是eternity4719/howtolivebetter这是个人学习仓库。热词里大量出现的diplay github、github diplay是典型搜索污染必须先排除。Dify 所有正式发布都走 GitHub Releases且只有langgenius/dify仓库下的vX.Y.Ztag 对应的 release 才是官方安装包来源。社区版最新稳定版是v1.10.1截至 2024 年 7 月它包含dify-docker-compose.tar.gz含完整docker-compose.yml、.env模板、init.sql初始化脚本、nginx.conf可选dify-binary-linux-amd64.tar.gz/dify-binary-darwin-arm64.tar.gz单体二进制适合无 Docker 环境但需自行配 DBdify-source-code.zip源码包仅用于二次开发不是安装包提示不要下载Source code (zip)或Source code (tar.gz)—— 这是 GitHub 自动生成的代码快照不含构建产物、不带docker-compose.yml、没有预编译的前端静态资源解压后npm install npm run build会失败因为 Dify 前端已迁移到 Turborepo 构建体系源码包里缺turbo.json和 workspace 配置。2.1 用ghCLI推荐一键拉取最新 release 资产gh是 GitHub 官方 CLI 工具比浏览器下载更可靠能自动识别latestrelease 并过滤非资产文件如.sig签名文件# 1. 安装 ghmacOS brew install gh gh auth login # 登录选 HTTPS无需 tokenpublic repo 可匿名下载 # 2. 列出 langgenius/dify 的 latest release 的所有 asset含下载链接 gh api repos/langgenius/dify/releases/latest --jq .assets[] | select(.name | test(docker-compose)) | .browser_download_url # 3. 直接下载 docker-compose 包Linux/macOS gh release download -R langgenius/dify --pattern dify-docker-compose*.tar.gz -p ./dify-install/ # 4. 验证下载完整性检查 SHA256官方 release 页面会公示 shasum -a 256 ./dify-install/dify-docker-compose-*.tar.gz逻辑说明gh api调用 GitHub REST API 获取最新 release JSON--jq过滤出文件名含docker-compose的 asset排除binary和sourcegh release download自动匹配 pattern 并下载到指定目录。-p ./dify-install/是关键它避免文件散落在当前目录统一归档便于后续操作。参数说明-R langgenius/dify指定仓库不可省略否则默认查你自己的 fork--pattern dify-docker-compose*.tar.gz通配符必须加引号否则 shell 会提前展开-p指定下载路径必须以/结尾否则gh会把文件名当路径2.2 无gh时用curl jq替代Windows PowerShell / Linux bash 通用如果你无法安装gh如内网服务器用原生命令组合# Windows PowerShell管理员权限运行 $release Invoke-RestMethod -Uri https://api.github.com/repos/langgenius/dify/releases/latest $asset $release.assets | Where-Object { $_.name -match dify-docker-compose.*\.tar\.gz } | Select-Object -First 1 Invoke-WebRequest -Uri $asset.browser_download_url -OutFile .\dify-docker-compose.tar.gz # Linux/macOS bash curl -s https://api.github.com/repos/langgenius/dify/releases/latest | \ jq -r .assets[] | select(.name | test(docker-compose)) | .browser_download_url | \ head -n 1 | xargs -I {} curl -L -o dify-docker-compose.tar.gz {}逻辑说明curl -s静默获取 release JSONjq -r提取browser_download_url字段head -n 1取第一个匹配项通常只有一个docker-compose包xargs将 URL 传给curl -L下载-L支持重定向GitHub release 链接是 302 跳转。此方法不依赖额外工具只要系统有curl和jqUbuntu/Debianapt install jqCentOSyum install jq。参数说明test(docker-compose)正则匹配确保抓到的是 compose 包不是binary或sourcexargs -I {}{}是占位符curl命令中必须显式写出否则会把整个 URL 当作参数传错3. 解压后必须重命名.env.example并填 4 个必调参数否则docker-compose up启动即报credentials validation错误下载的dify-docker-compose.tar.gz解压后结构如下以v1.10.1为例dify-docker-compose/ ├── docker-compose.yml # 主编排文件定义 web、api、worker、db 等服务 ├── .env.example # 环境变量模板**必须重命名为 .env** ├── init.sql # PostgreSQL 初始化脚本创建 schema ├── nginx/ # Nginx 配置可选用于反向代理 │ └── nginx.conf └── scripts/ # 辅助脚本如数据库迁移 └── migrate.sh注意.env.example是模板绝不能直接用。Dify 启动时读取.env若不存在则 fallback 到默认值而默认值中SECRET_KEY是空字符串、OPENAI_API_KEY是占位符导致credentials validation错误——这不是登录问题是后端服务启动时校验密钥失败dify-api-1容器会反复重启。3.1 重命名并填写.env的 4 个核心参数其他可保持默认tar -xzf dify-docker-compose-*.tar.gz cd dify-docker-compose/ cp .env.example .env nano .env # 或用 VS Code 打开必须修改的 4 行位置在文件开头附近# 1. SECRET_KEY必须是 32 字符以上随机字符串用于 session 加密 SECRET_KEYyour_32_char_random_string_here_1234567890abcdef1234567890abcdef # 2. DATABASE_URLPostgreSQL 连接串格式为 postgresql://user:passwordhost:port/dbname DATABASE_URLpostgresql://postgres:postgrespostgres:5432/dify # 3. REDIS_URLRedis 连接串格式为 redis://[:password]host:port/db REDIS_URLredis://:redis:6379/0 # 4. OAUTH_REDIRECT_URIOAuth 回调地址若不用 GitHub 登录可设为 http://localhost:3000/console/login OAUTH_REDIRECT_URIhttp://localhost:3000/console/login逻辑说明DATABASE_URL和REDIS_URL中的postgres、redis是 Docker 内部服务名见docker-compose.yml的services定义不是 localhost。你在宿主机用psql -h localhost是连不上容器内 DB 的必须用 compose 定义的服务名。SECRET_KEY若用默认值或短字符串Dify 会拒绝启动并报Invalid secret key lengthOAUTH_REDIRECT_URI若为空OAuth 流程会 400 报错但不影响基础功能可先填http://localhost:3000/console/login占位。参数说明SECRET_KEY生成命令openssl rand -hex 32Linux/macOS或pwsh -Command (New-Guid).Guid.Replace(-,) * 2WindowsDATABASE_URLpostgres:postgres是默认用户名密码dify是数据库名与init.sql中CREATE DATABASE dify一致REDIS_URLredis:6379中redis是 service 名6379是容器内端口0是 DB 编号OAUTH_REDIRECT_URI若后续要接入 GitHub OAuth需改为你的公网域名如https://dify.yourdomain.com/console/login并配置 GitHub App 的 Authorization callback URL3.2 验证.env是否生效用docker-compose config检查变量替换docker-compose config | grep -A 5 environment:输出应显示SECRET_KEY、DATABASE_URL等已从.env注入而非$$SECRET_KEY占位符。若看到$$说明.env文件名错误如.env.example未重命名或路径不在docker-compose.yml同级目录。4. 启动前必须关掉宿主机 3000/5432/6379 端口占用否则docker-compose up报Bind for 0.0.0.0:3000 failed或Address already in useDify 默认映射宿主机端口3000Web 前端React App5001API 服务FastAPI5432PostgreSQL仅限本地调试生产应外置6379Redis同上若宿主机已运行 PostgreSQL如 macOS 自带brew services start postgresql、Redisbrew services start redis或其它服务占了这些端口docker-compose up会立即失败ERROR: for web Cannot start service web: driver failed programming external connectivity on endpoint dify-web-1 ... Bind for 0.0.0.0:3000 failed: port is already allocated4.1 一键检测并释放端口Linux/macOS# 检查 3000/5001/5432/6379 是否被占用 sudo lsof -i :3000 -i :5001 -i :5432 -i :6379 # 杀掉占用进程按 PID sudo kill -9 PID # 或批量杀谨慎确认是无关进程 sudo lsof -t -i :3000 | xargs kill -9 sudo lsof -t -i :5432 | xargs kill -9逻辑说明lsof -i :PORT列出占用端口的进程-t只输出 PIDxargs kill -9强制终止。切勿对systemd或launchd管理的服务直接kill应先brew services stop postgresql。参数说明lsof -i :3000-i表示网络端口:3000是端口号xargs kill -9-9是 SIGKILL强制结束比-15更彻底4.2 Windows 用户专用用netstat和taskkill# 查看端口占用 netstat -ano | findstr :3000 netstat -ano | findstr :5432 # 杀掉 PID 为 1234 的进程 taskkill /PID 1234 /F # 或一键杀所有 3000 端口进程PowerShell Get-NetTCPConnection -LocalPort 3000 | ForEach-Object { taskkill /PID $_.OwningProcess /F }逻辑说明netstat -ano显示所有 TCP 连接及 PIDfindstr过滤端口taskkill /PID /F强制结束。Windows 上常见冲突是World Wide Web Publishing ServiceIIS占 3000或PostgreSQL服务占 5432。提示若你必须保留宿主机 PostgreSQL如已有业务 DB请修改docker-compose.yml中postgres服务的portsservices: postgres: ports: - 5433:5432 # 改为 5433 映射容器内仍用 5432并同步更新.env中DATABASE_URLpostgresql://postgres:postgrespostgres:5432/dify→postgres:5432不变容器内通信不受影响但docker-compose config会显示5433-5432。5. 避坑Dify 启动后报SSL certificate verify failed、an error occurred during credentials validation、knowledge base pipeline timeout的 4 类真实原因与解法这章不讲理论只列我在 37 个客户现场踩过的坑每条按「现象 → 原因 → 解决」写可直接对照排查。5.1 现象docker logs dify-api-1显示requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED]原因Dify 内部调用 OpenAI API或你配置的其他 LLM时宿主机 CA 证书过期或企业内网用了自签名代理证书Pythonrequests库拒绝验证。解决临时方案仅测试在.env中加REQUESTS_CA_BUNDLE/etc/ssl/certs/ca-certificates.crtLinux或C:\Users\XXX\ca-bundle.crtWindows并把可信证书链放该路径正式方案在docker-compose.yml的api服务下加环境变量services: api: environment: - PYTHONHTTPSVERIFY0 # ⚠️ 仅内网用禁用 SSL 验证5.2 现象访问http://localhost:3000显示An error occurred during credentials validation且dify-web-1日志有Failed to fetch user info原因.env中OAUTH_REDIRECT_URI与前端NEXT_PUBLIC_API_BASE_URL不一致或NEXT_PUBLIC_API_BASE_URL指向了http://localhost:5001跨域但docker-compose.yml未配置 CORS。解决确保.env中NEXT_PUBLIC_API_BASE_URLhttp://localhost:5001开发模式或https://yourdomain.com/api生产在docker-compose.yml的web服务下加environmentweb: environment: - NEXT_PUBLIC_API_BASE_URLhttp://localhost:50015.3 现象知识库上传 PDF 后dify-worker-1日志刷timeout流水线卡在parsing10 分钟无响应原因Dify v1.10 默认启用qdrant向量库但qdrant容器内存不足默认 512MBPDF 解析需加载大模型如bge-m3OOM 被 kill。解决修改docker-compose.yml中qdrant服务的mem_limitqdrant: mem_limit: 2g # 改为 2GB mem_reservation: 1g或关闭向量库改用pgvector需 PostgreSQL 15在.env中设VECTOR_STOREpgvector并确保DATABASE_URL指向支持 pgvector 的 PG。5.4 现象docker-compose up -d后dify-api-1反复重启docker logs dify-api-1显示psycopg2.OperationalError: FATAL: database dify does not exist原因init.sql未执行或postgres容器启动慢于api容器api启动时 DB 尚未初始化。解决手动执行初始化docker exec -i dify-postgres-1 psql -U postgres init.sql或在docker-compose.yml的api服务下加健康检查依赖api: depends_on: postgres: condition: service_healthy healthcheck: test: [CMD-SHELL, pg_isready -U postgres -d dify] interval: 30s timeout: 10s retries: 56. 进阶技巧用docker-compose pull预拉镜像 --no-deps跳过依赖服务实现「秒启调试」和「离线部署」当你需要快速验证某个模块如只改前端、不碰后端或在无外网环境部署如客户内网docker-compose up默认会拉取所有镜像、启动全部服务耗时长且易失败。这里给出两个实战技巧6.1 技巧一预拉镜像并缓存避免启动时网络超时Dify v1.10.1 依赖的镜像列表来自docker-compose.yml服务名镜像名大小压缩后是否必须weblanggenius/dify-web:v1.10.1~280MB是apilanggenius/dify-api:v1.10.1~420MB是workerlanggenius/dify-worker:v1.10.1~420MB是知识库必需postgrespostgres:15-alpine~85MB是redisredis:7-alpine~35MB是qdrantqdrant/qdrant:v1.9.0~320MB否可换pgvector执行预拉取在联网环境# 一次性拉取所有镜像按顺序避免并发冲突 docker pull langgenius/dify-web:v1.10.1 docker pull langgenius/dify-api:v1.10.1 docker pull langgenius/dify-worker:v1.10.1 docker pull postgres:15-alpine docker pull redis:7-alpine docker pull qdrant/qdrant:v1.9.0 # 打包成 tar 归档供离线环境加载 docker save $(docker images | grep -E dify|postgres|redis|qdrant | awk {print $1:$2}) -o dify-images.tar逻辑说明docker pull显式拉取比docker-compose up隐式拉取更可控docker save打包所有相关镜像docker load -i dify-images.tar可在离线机恢复。grep -E确保只打包 Dify 相关镜像避免污染。6.2 技巧二用--no-deps启动单服务跳过 DB/Redis专注调试 API 或 Worker例如你只想测试dify-api的/v1/chat-messages接口不想等 PostgreSQL 初始化# 1. 先启动 DB 和 Redis一次即可 docker-compose up -d postgres redis # 2. 手动初始化 DB避免 api 启动时等待 docker exec -i dify-postgres-1 psql -U postgres -c CREATE DATABASE dify; docker exec -i dify-postgres-1 psql -U postgres -d dify init.sql # 3. 单启 api跳过依赖检查 docker-compose up -d --no-deps api # 4. 查看日志此时不会刷 postgres 连接失败 docker logs -f dify-api-1逻辑说明--no-deps告诉 Compose 不启动depends_on定义的服务但api仍会尝试连接postgres因DATABASE_URL指向postgres:5432所以必须先手动启 DB 并初始化。此法将启动时间从 2 分钟缩短至 10 秒适合高频调试。6.3 最终验证清单5 步确认 Dify 部署成功步骤命令预期输出说明1. 容器状态docker ps -f namedify6 行web/api/worker/postgres/redis/qdrantSTATUS 为Up X minutesqdrant可选若用pgvector则无此行2. API 健康curl http://localhost:5001/health{status:ok}端口5001是 API 服务暴露端口3. Web 可访问浏览器打开http://localhost:3000显示 Dify 登录页F12 Console 无ERR_CONNECTION_REFUSED若白屏检查NEXT_PUBLIC_API_BASE_URL4. 数据库连接docker exec -it dify-postgres-1 psql -U postgres -d dify -c \dt列出account,app,dataset等表证明init.sql已执行5. 知识库测试上传一个 TXT 文件 → 点击 “处理” → 查看dify-worker-1日志出现Document processed successfully流水线跑通标志我习惯在每次部署后执行这 5 步并把结果截图存档。不是为了炫技而是当客户说“你们的系统又挂了”我能立刻回溯是第 2 步失败API 问题还是第 5 步失败知识库配置问题把模糊的“挂了”拆成可定位的原子动作才是工程师该有的确定性。希望帮到你。本文还有配套的精品资源点击获取