简介这份PDF教程面向希望快速上手开源LLM应用开发平台的开发者与AI应用爱好者围绕Dify的本地化部署展开帮助读者在自有环境中搭建一套可演示、可验证的生成式AI解决方案原型无需依赖复杂云服务。资源包共1个PDF文件大小约711KB内容以图文结合的命令行操作指导为主涵盖从环境准备到容器启动的完整流程。教程先说明Docker与Git的前置安装要求再依次讲解新建目录、克隆源码、复制环境变量配置、通过docker compose一键拉起服务并以九个容器全部健康运行为部署完成的标志最后引导访问本地地址完成管理员账号初始化。对于网络受限或克隆失败的情况文中也提供了直接获取打包版本的折衷思路并提醒妥善保存超级管理员凭证。目前已有1350人学习适合初学者按步骤实践也便于有经验的技术人员在此基础上深入定制与拓展平台功能。1. 从一份 PDF 教程说起Dify 应用开发平台到底该怎么部署很多人拿到「Dify应用开发平台部署教程.pdf」这类资料时第一反应是照着截图一步步点结果卡在拉镜像、连数据库、配模型这几步上翻车现场比比皆是。Dify 是一个开源的 LLM 应用开发平台核心价值在于把「编排工作流、挂知识库、接大模型、发 API」这几件事收敛到一个可视化界面里让你不用从零写后端就能搭出智能体和 RAG 应用。它解决的是「模型能跑但应用难落地」的问题适合想快速验证 AI 应用的中小团队、独立开发者以及需要内网私有化部署的运维同学。这份教程类资料真正要讲清楚的不是界面怎么点而是部署形态怎么选、依赖怎么配、模型怎么接、出问题怎么查。下面按本地 Docker 部署这条最通用的路径展开把每一步的参数和坑都摊开讲。2. 部署形态选型Docker Compose、K8s 还是源码二次开发2.1 三种部署形态的适用边界Dify 官方主推的是 Docker Compose 部署这也是绝大多数人第一次接触 Dify 时会走的路。它把 api、worker、web、db、redis、weaviate或其它向量库、nginx 这些组件用一份 compose 文件串起来一条命令拉起。适合单机、内网、快速验证资源占用可控出问题也容易定位。K8s 部署适合已经有集群、要做多租户隔离或高可用的团队。Dify 社区版本身对多租户的支持有限K8s 更多是解决「多个团队共用一套平台」的调度问题而不是 Dify 自带的能力。如果你只是自己用或者小团队用上 K8s 属于过度设计运维成本反而更高。源码二次开发适合要改前端界面、加自定义节点、对接内部系统的场景。这时候你不是在「部署」而是在「基于 Dify 做产品」需要同时跑 Python 后端和 Node 前端依赖管理复杂度上一个台阶。选型判断很简单先问自己要不要改代码。不改代码Docker Compose要集群调度K8s要改功能源码。下面重点讲 Docker Compose因为它是复现成本最低、检索量最大的一条路。2.2 Docker Compose 部署的最小依赖清单在动手之前先把环境盘清楚。Dify 对宿主机的要求不算高但有几个硬性依赖不能少。组件最低要求说明Docker20.10需要支持 compose v2Docker Composev2.x用docker compose而非docker-composeCPU2 核低于 2 核 worker 会明显卡内存4 GB跑向量库和模型调用时建议 8 GB磁盘20 GB镜像加数据卷知识库大就往上加操作系统Linux / macOS / Win10Windows 建议走 WSL2这里有个血泪经验Windows 上用 Hyper-V 加 Docker Desktop 部署 Dify最容易翻车的不是 Dify 本身而是 WSL2 的内存分配。默认 WSL2 只给一半内存Dify 的 worker 和向量库一起跑很容易 OOM。解决办法是在用户目录下建.wslconfig手动限制内存上限。# 在 Windows 用户目录创建 .wslconfig # 路径通常是 C:\Users\你的用户名\.wslconfig [wsl2] memory8GB processors4 swap2GB这段配置的作用是给 WSL2 虚拟机分配固定内存和 CPU避免它动态抢占导致 Docker 容器被杀。memory按你物理内存的一半到三分之二给processors不超过物理核心数swap给 2GB 兜底。改完执行wsl --shutdown重启 WSL 生效。很多人部署到一半容器反复重启查日志发现是 OOMKilled根子就在这里。2.3 拉取代码与目录结构确认Dify 的部署文件在官方仓库的docker目录下。常见做法是克隆仓库后进入该目录复制环境变量模板。# 克隆 Dify 仓库只取部署需要的部分即可 git clone https://github.com/langgenius/dify.git cd dify/docker # 复制环境变量模板 cp .env.example .env # 查看目录结构确认关键文件都在 ls -la执行后你应该能看到docker-compose.yaml、.env.example、nginx目录、volumes目录等。.env是全局配置入口数据库密码、端口、向量库类型、密钥都在这里改。volumes目录是数据持久化的落点删容器不删这个目录数据就还在。这一步的坑在于不要直接改.env.example一定要复制成.env再改否则后续升级覆盖模板时你的配置会丢。3. 环境变量与核心参数把 .env 里真正要改的几项挑出来3.1 端口、密钥与数据库连接.env文件里参数上百个但真正必须改的没几个。默认配置能跑起来但生产或内网使用必须调整下面这几类。# 对外访问端口默认 80被占用就改 EXPOSE_NGINX_PORT8080 # 密钥用于加密存储务必改成随机长字符串 SECRET_KEYyour-random-secret-key-here # 数据库配置默认用内置 postgres DB_USERNAMEpostgres DB_PASSWORDdifyai123456 DB_HOSTdb DB_PORT5432 DB_DATABASEdify # Redis 配置 REDIS_HOSTredis REDIS_PORT6379 REDIS_PASSWORDdifyai123456 # 向量库类型默认 weaviate VECTOR_STOREweaviateEXPOSE_NGINX_PORT决定你从浏览器访问的端口如果宿主机 80 被 nginx 或其它服务占了改成 8080 之类。SECRET_KEY是加密密钥默认值必须换否则任何知道默认值的人都能解密你的敏感配置。数据库和 Redis 的密码同理内网也别用默认值。VECTOR_STORE决定知识库用哪个向量库weaviate 是默认且最省心的要换 pgvector 或 milvus 就改这里但换之前确认对应服务在 compose 文件里启用了。参数改完不要急着up先做一次配置校验。Dify 的 compose 文件里服务之间有依赖顺序db 和 redis 没起来 api 会反复重试。可以用docker compose config检查语法确认没有变量拼写错误。3.2 向量库与存储卷的取舍向量库的选择直接影响知识库的检索效果和部署复杂度。默认 weaviate 是嵌入式友好、开箱即用的选项单机部署首选。pgvector 适合你已经有 postgres 且想少跑一个容器的情况但需要额外装扩展。milvus 适合知识库规模上百万条向量单机跑起来资源占用明显更高。存储卷这块Dify 把数据分几处postgres 数据、redis 数据、weaviate 数据、上传的文件。这些在 compose 文件里都映射到了宿主机目录。升级或迁移时只要把这几个目录打包带走新机器上还原就能恢复。常见误区是只备份数据库忘了上传的文件目录结果知识库文档全丢。迁移前用docker compose down停服务再打包volumes目录比热备份可靠。提示改完.env后如果之前已经启动过需要docker compose down再up直接restart不会重新读取环境变量。3.3 启动服务与首次访问配置确认无误后拉起全部服务。第一次会拉取大量镜像耐心等。# 后台启动所有服务 docker compose up -d # 查看容器状态确认都处于 running docker compose ps # 跟踪 api 日志看有没有报错 docker compose logs -f apiup -d是后台启动ps看状态时重点确认 api、worker、db、redis、weaviate、nginx 都是 running 或 healthy。如果 api 一直重启logs -f api会告诉你原因常见的是数据库连不上或迁移失败。首次启动 api 会自动跑数据库迁移这一步需要几十秒别看到日志停在迁移就以为卡死。全部就绪后浏览器访问http://宿主机IP:端口进入初始化页面设置管理员账号。到这里部署主体就完成了接下来是接模型。4. 接入大模型与知识库让平台真正跑起来4.1 模型供应商配置的两种方式Dify 本身不带模型它是个调度层模型要你自己接。接入方式分两种在界面里配 API Key或者通过环境变量配本地模型。前者适合用云端模型服务后者适合内网私有化。界面配置路径是「设置 → 模型供应商」选对应厂商填 API Key 和 Base URL。这里最常见的报错是an error occurred during credentials validation原因通常是 Base URL 写错、Key 无效、或者网络不通。排查顺序先用 curl 直接打模型的接口确认通不通再回来看 Dify 配置。# 用 curl 验证模型接口是否可达以 OpenAI 兼容接口为例 curl -X POST http://你的模型地址/v1/chat/completions \ -H Authorization: Bearer 你的APIKey \ -H Content-Type: application/json \ -d { model: 模型名称, messages: [{role: user, content: test}] }这段命令的作用是绕过 Dify 直接测模型服务。如果 curl 通而 Dify 不通问题在 Dify 的网络或配置如果 curl 也不通问题在模型服务本身。model字段要填模型服务实际暴露的名称不是随便写。内网部署时Dify 容器访问宿主机上的模型服务地址不能写localhost要写宿主机的内网 IP 或 Docker 网桥地址这是新手最容易踩的坑。4.2 本地模型接入与国内镜像加速内网或想省成本的话本地跑模型是常见选择。用 vLLM 或 Ollama 起一个 OpenAI 兼容接口再在 Dify 里按「OpenAI-API-compatible」类型接入。Qwen2.5-7B 这类模型单卡就能跑适合做行业知识库问答的底座。# 用 vLLM 起一个 OpenAI 兼容服务示例 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b \ --host 0.0.0.0 \ --port 8000--served-model-name是 Dify 里要填的模型名称两边必须一致。--host 0.0.0.0让服务监听所有网卡否则容器访问不到。启动后在 Dify 里填http://宿主机IP:8000/v1作为 Base URL模型名填qwen2.5-7b。拉镜像慢是另一个高频问题。国内环境给 Docker 配镜像加速能省大量时间在/etc/docker/daemon.json里加 registry-mirrors重启 Docker 生效。这一步不涉及任何网络工具纯粹是镜像仓库地址替换。4.3 知识库流水线与文档导入知识库是 Dify 的核心能力之一。上传文档后平台会做分段、向量化、存进向量库检索时按相似度召回。分段策略直接影响检索质量分段太大召回内容冗余分段太小语义被切碎。一般中文文档按 500 到 800 字符分段重叠 50 到 100 字符能兼顾完整性和精度。导入结构化数据时常见做法是先用脚本把数据整理成 CSV 或 JSON再通过 API 批量灌入而不是在界面里一条条传。Dify 提供了数据集 API可以程序化创建文档。import requests # 向 Dify 知识库批量导入文档 API_KEY dataset-你的密钥 DATASET_ID 你的数据集ID url fhttp://你的Dify地址/v1/datasets/{DATASET_ID}/document/create-by-text headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } payload { name: 示例文档, text: 这里是要导入的正文内容, indexing_technique: high_quality, process_rule: { mode: automatic } } resp requests.post(url, headersheaders, jsonpayload) print(resp.status_code, resp.text)indexing_technique选high_quality会用嵌入模型做向量化检索效果好但消耗 token选economy用关键词索引省成本但精度低。process_rule的mode设automatic用默认分段要自定义就换成custom并给分段规则。这段脚本适合把外部数据库里的结构化数据批量搬进知识库比手工上传高效得多。注意 API Key 是数据集级别的在知识库设置里生成不是账号级的。5. 部署避坑与常见问题排查5.1 容器反复重启日志显示数据库连接失败现象docker compose ps看到 api 容器状态在 restarting 和 running 之间跳logs api报连接 postgres 被拒。原因db 容器还没完成初始化api 就急着连或者.env里DB_HOST写成了localhost而不是服务名db。解决确认DB_HOSTdb这是 compose 内部的服务名。首次启动给 db 留足初始化时间可以先把 db 单独up -d等它 healthy 再up -d其余服务。如果之前用错误配置启动过down后删掉 postgres 数据卷重来否则残留的初始化状态会干扰。5.2 界面能打开但模型调用报 403 或超时现象Dify 界面正常配好模型后测试报 403或者一直转圈超时。原因403 通常是 API Key 权限不足或 Base URL 路径不对超时多半是容器访问不到宿主机上的模型服务。解决先用第 4 章的 curl 命令在宿主机上验证模型接口。容器内访问宿主机服务地址用宿主机内网 IP不要用127.0.0.1。如果是云端模型检查 Key 是否绑定了 IP 白名单Dify 服务器的出口 IP 要在白名单里。403 还要确认 Base URL 有没有多写或少写/v1。5.3 内网部署插件市场打不开或安装失败现象内网环境点插件市场一直加载或者安装插件报网络错误。原因插件市场默认走公网内网没有出口自然打不开。解决内网部署要么配一个能出网的代理给 Dify 容器要么离线安装插件。离线方式是把插件包下载好通过本地插件安装入口上传。注意这里说的代理是内网出网代理配置在 Docker 的 daemon 或容器环境变量里和任何网络工具无关。5.4 升级后数据丢失或配置被覆盖现象执行升级拉新镜像重启后管理员账号没了或者配置回到默认。原因升级时误删了数据卷或者直接覆盖了.env。解决升级前先docker compose down备份volumes目录和.env文件。升级只拉新镜像不动数据卷。.env永远基于自己的副本改不要用仓库里的模板覆盖。迁移到新机器时把这两个东西一起带过去还原后up -d即可。5.5 SSL 错误与反向代理配置现象配了域名和 HTTPS 后界面报 SSL 错误或者回调地址不对。原因Dify 的 nginx 容器默认只处理 HTTPHTTPS 通常由外层反向代理终止但CONSOLE_API_URL等地址没跟着改。解决在外层代理如宿主机的 nginx做证书终止转发到 Dify 的 HTTP 端口。同时把.env里的CONSOLE_API_URL、APP_API_URL、CONSOLE_WEB_URL改成实际的 HTTPS 域名否则前端请求会打到错误地址。改完down再up让配置生效。6. 进阶把 Dify 工作流接进现有系统的几个实用技巧部署只是起点真正体现价值的是把 Dify 的工作流接进你现有的业务系统。这里分享几个我实际用下来比较稳的做法。第一用工作流 API 而不是应用 API 做系统集成。工作流 API 的输入输出结构更清晰适合被后端程序调用。调用时注意response_mode选blocking还是streaming后端批处理用blocking拿完整结果前端交互用streaming做打字机效果。鉴权用应用级 API Key放在请求头Authorization: Bearer里。第二变量赋值节点是工作流里最容易被低估的能力。很多人把工作流写成一条直线其实用变量赋值可以在节点间传递和转换数据比如把上一步的 JSON 输出拆成多个字段供后续节点用。赋值时注意类型字符串和数字混用会导致后续节点报类型错误。第三知识库检索的召回参数要按场景调。top_k控制召回条数score_threshold控制相似度门槛。做精确问答时把score_threshold调高宁可召回少也不要有噪声做宽泛检索时调低保证覆盖率。这两个参数没有万能值要拿真实问题集测。参数精确问答场景宽泛检索场景top_k3 到 58 到 10score_threshold0.7 以上0.4 到 0.5分段大小300 到 500 字符800 到 1000 字符第四验证部署是否真的可用别只看界面能打开。写一个最小工作流开始节点接一个文本输入接一个 LLM 节点再接结束节点输出。用 API 打一次确认返回结构正确。这一步能一次性验证模型接入、工作流编排、API 鉴权三条链路比逐个点界面高效。我自己的习惯是每次部署完先跑这个最小工作流再跑一个带知识库检索的工作流两个都通了才算部署完成。踩过的坑告诉我界面正常不代表链路正常只有端到端跑通一次心里才有底。希望帮到你。本文还有配套的精品资源点击获取