1. 部署前的整体思路为什么非要在Mac上跑Dify先说结论Dify这个智能体开发平台本质上是一组微服务组成的容器集群官方推荐部署方式是Docker Compose所以不管你的机器是Mac还是Linux服务器思路都差不多。但Mac有其特殊性——M系列芯片的架构是ARM64而很多镜像默认还是amd64这就会引出架构兼容、镜像拉取、资源分配等问题第一次部署的人很容易卡在这上面。我最初在Mac上部署Dify核心诉求很简单想本地跑一套完整的LLM应用开发环境既能接在线大模型也能接Ollama跑本地模型随手验证工作流、知识库这类功能。为什么要强调Mac因为Mac做开发机很常见16G内存的机器就能带动社区版跑起来而且macOS的Docker Desktop自带图形界面容器状态一目了然方便新手入门。Dify解决了什么问题它把模型管理、Prompt编排、RAG知识库、Agent工作流这些能力打包成一个可视化平台你不需要从零写后端代码就能快速搭出一个AI应用的原型。适合谁想本地研究Dify功能的产品经理、独立开发者以及准备基于Dify做二次开发的技术团队。部署前先想清楚三件事能少踩很多坑。第一你的Mac是Intel芯片还是M系列芯片这会影响到镜像架构的选择虽然Docker Desktop现在内置了Rosetta模拟层但这个兼容层偶尔会出幺蛾子。第二你的内存和磁盘是否够用Dify全家桶差不多要占6到8G内存磁盘至少预留20G空间。第三你打算用什么模型如果只接云端APIDify部署完后填个Key就能用如果想完全本地化还得把Ollama这类本地模型服务也装好。我建议按“先跑通、再优化”的顺序来先把Dify容器集群拉起来看到登录页面后再逐步接模型、做知识库整个链路会顺很多。2. 环境准备Mac上必备的几样东西2.1 包管理工具Homebrew装好后面省一半事Mac上装软件首选就是Homebrew它就像Linux下的apt-get一条命令搞定安装、升级、卸载。Dify部署过程中要用到Git、Docker、还有可能是ollama用Homebrew统一管理这些依赖后续更新也会方便很多。检查是否装了Homebrew在终端执行brew --version如果提示command not found先去官网装一下。官方提供的安装命令是/bin/bash -c $(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)这条命令会下载Homebrew本体并写入对应目录过程中可能需要输入Mac的开机密码。要注意的是这个脚本执行时间比较长和你的网络状况有关中途不要关终端。装完后再执行下面两条把brew加入当前终端的环境变量echo eval $(/opt/homebrew/bin/brew shellenv) ~/.zprofile eval $(/opt/homebrew/bin/brew shellenv)注意路径区别M系列芯片的MacHomebrew默认装在/opt/homebrew下Intel的Mac装在/usr/local下。如果你的机器安装路径不一样把上面命令里的路径替换掉就行。我个人的体会是别嫌装Homebrew麻烦后面用brew install装git、node、ollama都是一条命令的事。如果直接去官网下.dmg安装包版本管理和卸载都麻烦而且命令行工具链经常要配PATH折腾一圈不如Homebrew干净。2.2 容器运行时Docker Desktop与Colima怎么选Dify的部署形态是多个Docker容器所以Mac上必须有一个能跑容器的运行时。主流选择有三个Docker Desktop、Colima、OrbStack。我实际用过前两个简单说下差别。Docker Desktop是官方出品自带图形界面、资源监控面板、镜像管理页对新手最友好。缺点是商业许可对大型企业收费个人和小公司免费而且它默认占用资源比较多需要手动调低内存配额。Colima是命令行工具配合Docker CLI使用本质上是调用macOS的虚拟机框架跑一个Linux虚拟机资源占用比Docker Desktop小但没有图形界面适合喜欢命令行的老手。OrbStack我没深度用过口碑不错但偏向付费方向这里就不展开讨论。如果你没有特殊偏好直接装Docker Desktop即可。安装方式两种一种是用Homebrewbrew install --cask docker另一种是去官网下载dmg安装。装好后打开Docker Desktop先去右上角齿轮图标里找到Settings - Resources调整两个关键参数内存建议至少给到6GBCPU核心数给到4个以上。这一步很多人忽略默认配置只有2GB内存Dify容器集群启动后很容易被OOM杀掉。我最初就是在这一步踩了坑容器一直重启日志里全是memory allocation失败后来把内存提到8GB才稳定。调整完资源配额后回到终端验证Docker是否正常docker version docker compose version能分别看到client和server的版本号以及Docker Compose的版本说明环境就绪。Docker Compose是部署Dify的核心工具新版的Docker Desktop已经自带了compose v2插件不需要单独安装。2.3 拉取项目代码Git与Dify源码Dify社区版托管在GitHub上需要先把代码clone到本地。Mac自带的Git版本可能偏老建议用Homebrew装个新版brew install git然后选定一个你希望存放项目的目录比如在用户目录下建一个workspacemkdir -p ~/workspace cd ~/workspace git clone https://github.com/langgenius/dify.git这里有个小建议不要clone master分支直接裸跑Dify迭代很快master分支偶尔会有正在开发中的功能。稳妥的做法是查看Releases页签里最新的稳定版本标签然后clone指定tag。比如当前社区版已经出到1.10.x可以这样操作git clone -b 1.10.0 https://github.com/langgenius/dify.git标签名称要以仓库Release页为准我这里只是举例。用稳定版本的好处是Docker镜像和源码匹配遇到问题去GitHub搜issue时能搜到更多和你相同版本的讨论不是孤军奋战。clone完成后进入dify目录找到docker子目录里面有一个.env.example文件这是全部配置的起点cd dify/docker cp .env.example .env这个时候先别急着启动下一步我们要检查环境变量和配置文件里几个关键项。3. 核心配置解析.env里那些必须懂的关键参数Dify的部署方式很规矩Docker Compose会按照.env文件里的配置去决定启动哪些服务、暴露哪个端口、使用什么存储路径。大部分参数用默认值就能跑但有几个关键项必须看懂免得后面出了问题找不到方向。打开docker目录下的.env文件从头到尾扫一遍。重点看这几个参数参数默认值作用与建议EXPOSE_NGINX_PORT80Dify入口服务的宿主端口也就是你浏览器访问用的端口。默认80如果被占用改成8080或8000DIFY_PORT5001Dify API服务内部端口容器间通信用一般不用改NGINX_PORT80容器内Nginx端口和EXPOSE_NGINX_PORT是映射关系POSTGRES_PASSWORDdifyai123456Postgres数据库密码本地自用无所谓如果要暴露到非本机网络建议改SECRET_KEY一串随机字符用于加密会话和API密钥部署前务必改成随机串至少32位SECRET_KEY这条我要多说一句。默认的SECRET_KEY是写死在.env.example里的意味着所有clone过这个仓库的人都用同一个Key。本地玩没问题但如果你的Dify暴露在局域网里存在会话伪造的隐患。可以用下面命令生成一个随机Key然后填进.envopenssl rand -base64 42把输出结果完整替换掉SECRET_KEY那行。还有一个容易被忽略的点docker子目录里有独立的docker-compose.yaml文件。这个文件本身就带了一堆服务定义包括nginx、api、worker、web、db、redis、sandbox、ssrf_proxy这几个核心组件。第一次启动时Compose会自动从Docker Hub拉取镜像包括langgenius/dify-api、langgenius/dify-web这些仓库。镜像体积都不小api镜像差不多2GB多web镜像也有几百MB所以要留好网络时间和磁盘空间。如果你平时拉Docker Hub镜像就慢不要在这里卡太久可以确认一下自己的网络环境保证能正常访问Docker Hub再继续。启动之前还可以预检一下.co配置里有没有语法错误docker compose config --quiet一键启动Dify的方式就一句话docker compose up -d这里补充一下为什么很多教程里写的是up -d而不是直接up。加了-d参数Compose会在后台运行所有容器启动完立即把终端控制权交还给你。如果不加所有容器日志会直接刷满你整个终端而且一旦你按CtrlC退出整个Dify服务就被停掉了这不是我们想要的效果。当然第一次调试时临时不用-d直接在前台跑眼神盯日志排查启动问题也是一种策略我习惯先把-d加上后面用docker compose logs单独看日志这样更灵活。启动过程会持续几分钟取决于拉取镜像的耗时。等命令执行完在终端查看容器运行状态docker compose ps正常状态下各服务的STATUS列应该显示Up。如果显示Restarting说明有容器启动失败需要看具体日志。看到所有服务都Up之后浏览器访问http://localhost如果你的EXPOSE_NGINX_PORT改成了8080那就访问http://localhost:8080。首次进入会看到一个初始化页面设置管理员账号和密码这一步完成后Dify就可以登录使用了。部署环节走到这里说实话只是万里长征第一步因为你会立刻遇到下一个问题连模型。没有模型接入的Dify像一台没装软件的电脑空有平台却干不了活。4. 接入模型Ollama本地模型与在线大模型双管齐下Dify本身不内置模型它的定位是模型应用的编排层。所以部署完Dify之后第一件事就是配置模型供应商。两种选择我分别说。如果你追求零成本、完全本地推理推荐用Ollama。前段时间DeepSeek的讨论热度很高一台普通的Mac就能通过Ollama跑参数量较小的模型比如qwen2.5:7b、deepseek-r1:7b这类蒸馏版。安装Ollama很简单brew install ollama brew services start ollama装好后拉一个适合Dify的模型。以qwen2.5:7b为例ollama pull qwen2.5:7b验证模型是否正常加载ollama run qwen2.5:7b 你好能正常返回内容说明本地模型服务就绪。接下来要让Dify能访问到Ollama的服务。这里有一个非常重要的细节Dify的api容器运行在Docker虚拟网络里它访问宿主机的localhost和你在终端里访问localhost不是同一个网络栈。在macOS的Docker Desktop环境中容器内访问宿主机服务要用host.docker.internal这个特殊DNS名称它会被解析到宿主机的IP地址。所以在Dify的模型供应商配置页面里填Ollama的API Base地址时不能写http://localhost:11434要写http://host.docker.internal:11434然后在Ollama这一栏里选择你拉取好的模型名称比如qwen2.5:7b保存即可。如果不是Mac而是Linux服务器部署这里填的应该是服务器对外IP或者内部容器网络IP很多人第一次部署时在这个细节上绕了很久我列出来强调一下。如果你不想折腾本地模型直接接在线大模型更省事。Dify内置了几十家模型厂商的接入模板包括OpenAI、Anthropic、DeepSeek等。以DeepSeek为例你只需要去DeepSeek开放平台注册账号、创建API Key然后把Key填进Dify的模型供应商配置里选择对应的模型名称例如deepseek-chat测试连通性通过就完事。在线模型的优势是推理速度快、能力更强劣势是要联网、按量计费。我个人实际使用中习惯接两套模型日常简单对话、知识库试验用本地qwen2.5:7b成本为零也不怕网络波动正式验证工作流、做复杂Agent任务时用DeepSeek或GPT等在线模型效果更稳定。而且Dify支持在应用设置里配置多个模型并自由切换所以不存在二选一的纠结。5. 上手第一步创建第一个应用与工作流的踩坑实录Dify部署成功并且接好模型之后你已经可以开始创建AI应用了。但这里我建议别急着进工作流编辑器去连一堆节点最好先创建一个最基础的“聊天助手”应用把链路跑通确认模型调用、上下文传递、日志查看这些基础能力正常再上复杂功能。创建应用的路径是在Dify首页点击“创建应用”选择“聊天助手”填好应用名称后进入“编排”页面。在模型选择框里选中你配置好的模型然后在提示词编辑器里写一段简单的System Prompt比如“你是一个乐于助人的助手”保存后点右上角的“预览”打开调试对话框发一句话。如果模型正常回复说明全链路通了这是最基本的冒烟测试。通了之后就可以试试工作流。Dify的工作流本质是一个可视化编排器把LLM调用、代码执行、条件分支、工具调用串联成一个流程图。创建应用时选择“工作流”类型你会进入一个节点画布左侧是各种可拖拽的节点开始节点、大模型节点、知识检索节点、代码执行节点、条件分支节点、HTTP请求节点、结束节点等。一个典型的入门工作流是开始节点接收用户输入传给大模型节点大模型根据指令返回结果结束节点把结果输出。拖完节点把节点之间的连线接好点运行填一个测试输入看看跑通没有。这里常见的坑是节点之间数据变量名的对应关系搞混。比如大模型节点的“系统提示词”里引用用户输入要用{{#start#.input#}}这种变量语法结束节点的输出要引用大模型节点输出得写成{{#llm_1#.text#}}。我第一次创建时就在这块绕了弯总是从变量选择器里去选其实Dify已经替你封装好了选择器点输入框右侧的变量按钮就能选记住这个操作能省很多心。如果你有外部知识文档需要让模型参考就要在Dify里新建“知识库”上传文档Dify会做分段、清洗、向量化处理然后把它挂到应用的“上下文”里。这里的原理很简单把用户问题和知识库里的片段做语义相似度检索找出最相关的文本片段拼进Prompt再喂给大模型回答。所以知识库的实用体验受文档质量、分段策略、检索方式和Embedding模型共同影响不是上传文件就完事的。6. 常见问题排查技巧口袋里那些救命经验部署过程中没有完全顺利的我自己两次部署加上帮朋友远程排查记录了一批高频坑。这里挑几个最常见的放出来希望能让你少走点弯路。6.1 启动后容器反复重启的排查流程遇到docker compose up -d之后容器状态不是Up而是Restarting不要慌先看日志docker compose logs -f 服务名服务名指的是api、worker、web、db这些。最常见的日志内容是数据库连接失败或密码不匹配这时候检查.env里的POSTGRES_PASSWORD是不是被改过而db服务没用上同一个值。另一个常见情况是api容器启动时连接不到Redis看日志会看到redis connection refused的报错。这种情况通常是Redis容器还没完全ReadyApi服务就抢先连了等个十秒再docker compose restart api通常会好。还有一个频率很高的坑磁盘空间不足。Dify的镜像加上运行期间产生的向量库数据、日志很容易把系统盘占满。在Mac上检查磁盘空间df -h ~如果使用率超过了90%建议先清理Docker的悬空镜像docker system prune再重启服务。6.2 端口被占用的处理办法expose-nginx-port默认是80Mac上很多服务比如Apache、Nginx、或别的监听80端口的程序会冲突。启动后容器总是重启docker logs nginx里显示bind: address already in use。解决办法是修改.env里的EXPOSE_NGINX_PORT改成8080或者其他你确认空闲的端口然后重新启动docker compose up -d6.3 登录时提示密码错或错误次数过多Dify在连续多次输错密码后会锁定一段时间并提示“too many incorrect password attempts”。这个机制没有直观的后台界面提示只能等锁定期过。如果你是在测试环境不想等就去Postgres里把失败的登录记录清掉或者干脆重置管理员密码。操作方式比较复杂建议还是老实等锁定期顺便检查一下密码大小写和特殊字符。我遇到过有人把邮箱输错了还怪系统排查半天发现账号绑定的邮箱根本不是自己以为的那个。6.4 Ollama模型响应超时如果本地模型在Dify里测试时经常报超时多半是模型推理太慢而Dify默认的调用超时时间偏短。这时候看两个地方一是Ollama所在机器是不是CPU Performance降频运行ollama的同时还在跑Docker容器造成资源竞争二是在Ollama服务的启动参数里调成后台运行并在Dify里把模型供应商的超时设置调高。Apple Silicon的Mac本身跑7B模型没问题但如果你同时运行Dify全家桶和Ollama推理16G内存会吃紧内存压力一大整个系统都会卡。6.5 升级Dify的正确姿势Dify版本更新很快每次Release都会带新功能和修复。社区版升级的流程我并不推荐动不动就换tag得先把旧容器拉起来看版本再决定要不要升。简单说升级的核心是两步先更新源码到目标版本tag再重启容器因为新的Compose文件可能会带新增服务定义。备份很重要升级前最好把数据库和存储卷的备份做一下。如果你用的是docker compose管理推荐备份方案是把docker目录下的volume目录拷一份虽然有点笨但恢复起来很直接。7. 进阶扩展让Dify在Mac上更好用的几个方向部署完成只是开始我把Mac上后续值得做的事列几个方向。第一把Dify接入更多工具比如让它调用HTTP请求节点去访问你内网的服务、调用自定义代码节点去运算分析逻辑。第二做多租户隔离社区版1.10开始已经支持多租户能力虽然入口埋得比较深但如果你有团队协作需求值得研究。第三把后端嵌入到自己的业务系统里Dify提供了完善的API和Webhook可以把它当做一个模型编排后端来对接。除此之外日常运维上建议养成两个习惯一是定期看容器日志用docker compose logs -f api盯着有没有异常二是注意Dify各容器版本别乱动保持源码、镜像、Compose文件的版本一致否则组合出bug是常事。Dify社区版官方文档更新得也很快遇到问题先查官方文档的部署章节再查GitHub Issues大多数坑都是公开的。我个人实际使用中的体会是在整个部署过程里最耗时间的部分不是命令本身而是理解各容器的职责和数据流向。Dify的容器编排不算复杂但当你搞清楚api负责业务逻辑、worker负责异步任务、sandbox负责代码执行隔离、db与redis负责状态存储之后你就能游刃有余地调整配置而不是背命令。最后再分享一个小技巧如果你觉得自己在Mac上折腾Docker资源消耗较大可以趁空闲时把Dify和Ollama分别跑在两台电脑上Dify负责编排Ollama负责推理只要互为局域网就能接通性能和稳定性都会好上一截。 Mac上部署Dify全指南：Docker Compose配置与本地模型接入
1. 部署前的整体思路为什么非要在Mac上跑Dify先说结论Dify这个智能体开发平台本质上是一组微服务组成的容器集群官方推荐部署方式是Docker Compose所以不管你的机器是Mac还是Linux服务器思路都差不多。但Mac有其特殊性——M系列芯片的架构是ARM64而很多镜像默认还是amd64这就会引出架构兼容、镜像拉取、资源分配等问题第一次部署的人很容易卡在这上面。我最初在Mac上部署Dify核心诉求很简单想本地跑一套完整的LLM应用开发环境既能接在线大模型也能接Ollama跑本地模型随手验证工作流、知识库这类功能。为什么要强调Mac因为Mac做开发机很常见16G内存的机器就能带动社区版跑起来而且macOS的Docker Desktop自带图形界面容器状态一目了然方便新手入门。Dify解决了什么问题它把模型管理、Prompt编排、RAG知识库、Agent工作流这些能力打包成一个可视化平台你不需要从零写后端代码就能快速搭出一个AI应用的原型。适合谁想本地研究Dify功能的产品经理、独立开发者以及准备基于Dify做二次开发的技术团队。部署前先想清楚三件事能少踩很多坑。第一你的Mac是Intel芯片还是M系列芯片这会影响到镜像架构的选择虽然Docker Desktop现在内置了Rosetta模拟层但这个兼容层偶尔会出幺蛾子。第二你的内存和磁盘是否够用Dify全家桶差不多要占6到8G内存磁盘至少预留20G空间。第三你打算用什么模型如果只接云端APIDify部署完后填个Key就能用如果想完全本地化还得把Ollama这类本地模型服务也装好。我建议按“先跑通、再优化”的顺序来先把Dify容器集群拉起来看到登录页面后再逐步接模型、做知识库整个链路会顺很多。2. 环境准备Mac上必备的几样东西2.1 包管理工具Homebrew装好后面省一半事Mac上装软件首选就是Homebrew它就像Linux下的apt-get一条命令搞定安装、升级、卸载。Dify部署过程中要用到Git、Docker、还有可能是ollama用Homebrew统一管理这些依赖后续更新也会方便很多。检查是否装了Homebrew在终端执行brew --version如果提示command not found先去官网装一下。官方提供的安装命令是/bin/bash -c $(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)这条命令会下载Homebrew本体并写入对应目录过程中可能需要输入Mac的开机密码。要注意的是这个脚本执行时间比较长和你的网络状况有关中途不要关终端。装完后再执行下面两条把brew加入当前终端的环境变量echo eval $(/opt/homebrew/bin/brew shellenv) ~/.zprofile eval $(/opt/homebrew/bin/brew shellenv)注意路径区别M系列芯片的MacHomebrew默认装在/opt/homebrew下Intel的Mac装在/usr/local下。如果你的机器安装路径不一样把上面命令里的路径替换掉就行。我个人的体会是别嫌装Homebrew麻烦后面用brew install装git、node、ollama都是一条命令的事。如果直接去官网下.dmg安装包版本管理和卸载都麻烦而且命令行工具链经常要配PATH折腾一圈不如Homebrew干净。2.2 容器运行时Docker Desktop与Colima怎么选Dify的部署形态是多个Docker容器所以Mac上必须有一个能跑容器的运行时。主流选择有三个Docker Desktop、Colima、OrbStack。我实际用过前两个简单说下差别。Docker Desktop是官方出品自带图形界面、资源监控面板、镜像管理页对新手最友好。缺点是商业许可对大型企业收费个人和小公司免费而且它默认占用资源比较多需要手动调低内存配额。Colima是命令行工具配合Docker CLI使用本质上是调用macOS的虚拟机框架跑一个Linux虚拟机资源占用比Docker Desktop小但没有图形界面适合喜欢命令行的老手。OrbStack我没深度用过口碑不错但偏向付费方向这里就不展开讨论。如果你没有特殊偏好直接装Docker Desktop即可。安装方式两种一种是用Homebrewbrew install --cask docker另一种是去官网下载dmg安装。装好后打开Docker Desktop先去右上角齿轮图标里找到Settings - Resources调整两个关键参数内存建议至少给到6GBCPU核心数给到4个以上。这一步很多人忽略默认配置只有2GB内存Dify容器集群启动后很容易被OOM杀掉。我最初就是在这一步踩了坑容器一直重启日志里全是memory allocation失败后来把内存提到8GB才稳定。调整完资源配额后回到终端验证Docker是否正常docker version docker compose version能分别看到client和server的版本号以及Docker Compose的版本说明环境就绪。Docker Compose是部署Dify的核心工具新版的Docker Desktop已经自带了compose v2插件不需要单独安装。2.3 拉取项目代码Git与Dify源码Dify社区版托管在GitHub上需要先把代码clone到本地。Mac自带的Git版本可能偏老建议用Homebrew装个新版brew install git然后选定一个你希望存放项目的目录比如在用户目录下建一个workspacemkdir -p ~/workspace cd ~/workspace git clone https://github.com/langgenius/dify.git这里有个小建议不要clone master分支直接裸跑Dify迭代很快master分支偶尔会有正在开发中的功能。稳妥的做法是查看Releases页签里最新的稳定版本标签然后clone指定tag。比如当前社区版已经出到1.10.x可以这样操作git clone -b 1.10.0 https://github.com/langgenius/dify.git标签名称要以仓库Release页为准我这里只是举例。用稳定版本的好处是Docker镜像和源码匹配遇到问题去GitHub搜issue时能搜到更多和你相同版本的讨论不是孤军奋战。clone完成后进入dify目录找到docker子目录里面有一个.env.example文件这是全部配置的起点cd dify/docker cp .env.example .env这个时候先别急着启动下一步我们要检查环境变量和配置文件里几个关键项。3. 核心配置解析.env里那些必须懂的关键参数Dify的部署方式很规矩Docker Compose会按照.env文件里的配置去决定启动哪些服务、暴露哪个端口、使用什么存储路径。大部分参数用默认值就能跑但有几个关键项必须看懂免得后面出了问题找不到方向。打开docker目录下的.env文件从头到尾扫一遍。重点看这几个参数参数默认值作用与建议EXPOSE_NGINX_PORT80Dify入口服务的宿主端口也就是你浏览器访问用的端口。默认80如果被占用改成8080或8000DIFY_PORT5001Dify API服务内部端口容器间通信用一般不用改NGINX_PORT80容器内Nginx端口和EXPOSE_NGINX_PORT是映射关系POSTGRES_PASSWORDdifyai123456Postgres数据库密码本地自用无所谓如果要暴露到非本机网络建议改SECRET_KEY一串随机字符用于加密会话和API密钥部署前务必改成随机串至少32位SECRET_KEY这条我要多说一句。默认的SECRET_KEY是写死在.env.example里的意味着所有clone过这个仓库的人都用同一个Key。本地玩没问题但如果你的Dify暴露在局域网里存在会话伪造的隐患。可以用下面命令生成一个随机Key然后填进.envopenssl rand -base64 42把输出结果完整替换掉SECRET_KEY那行。还有一个容易被忽略的点docker子目录里有独立的docker-compose.yaml文件。这个文件本身就带了一堆服务定义包括nginx、api、worker、web、db、redis、sandbox、ssrf_proxy这几个核心组件。第一次启动时Compose会自动从Docker Hub拉取镜像包括langgenius/dify-api、langgenius/dify-web这些仓库。镜像体积都不小api镜像差不多2GB多web镜像也有几百MB所以要留好网络时间和磁盘空间。如果你平时拉Docker Hub镜像就慢不要在这里卡太久可以确认一下自己的网络环境保证能正常访问Docker Hub再继续。启动之前还可以预检一下.co配置里有没有语法错误docker compose config --quiet一键启动Dify的方式就一句话docker compose up -d这里补充一下为什么很多教程里写的是up -d而不是直接up。加了-d参数Compose会在后台运行所有容器启动完立即把终端控制权交还给你。如果不加所有容器日志会直接刷满你整个终端而且一旦你按CtrlC退出整个Dify服务就被停掉了这不是我们想要的效果。当然第一次调试时临时不用-d直接在前台跑眼神盯日志排查启动问题也是一种策略我习惯先把-d加上后面用docker compose logs单独看日志这样更灵活。启动过程会持续几分钟取决于拉取镜像的耗时。等命令执行完在终端查看容器运行状态docker compose ps正常状态下各服务的STATUS列应该显示Up。如果显示Restarting说明有容器启动失败需要看具体日志。看到所有服务都Up之后浏览器访问http://localhost如果你的EXPOSE_NGINX_PORT改成了8080那就访问http://localhost:8080。首次进入会看到一个初始化页面设置管理员账号和密码这一步完成后Dify就可以登录使用了。部署环节走到这里说实话只是万里长征第一步因为你会立刻遇到下一个问题连模型。没有模型接入的Dify像一台没装软件的电脑空有平台却干不了活。4. 接入模型Ollama本地模型与在线大模型双管齐下Dify本身不内置模型它的定位是模型应用的编排层。所以部署完Dify之后第一件事就是配置模型供应商。两种选择我分别说。如果你追求零成本、完全本地推理推荐用Ollama。前段时间DeepSeek的讨论热度很高一台普通的Mac就能通过Ollama跑参数量较小的模型比如qwen2.5:7b、deepseek-r1:7b这类蒸馏版。安装Ollama很简单brew install ollama brew services start ollama装好后拉一个适合Dify的模型。以qwen2.5:7b为例ollama pull qwen2.5:7b验证模型是否正常加载ollama run qwen2.5:7b 你好能正常返回内容说明本地模型服务就绪。接下来要让Dify能访问到Ollama的服务。这里有一个非常重要的细节Dify的api容器运行在Docker虚拟网络里它访问宿主机的localhost和你在终端里访问localhost不是同一个网络栈。在macOS的Docker Desktop环境中容器内访问宿主机服务要用host.docker.internal这个特殊DNS名称它会被解析到宿主机的IP地址。所以在Dify的模型供应商配置页面里填Ollama的API Base地址时不能写http://localhost:11434要写http://host.docker.internal:11434然后在Ollama这一栏里选择你拉取好的模型名称比如qwen2.5:7b保存即可。如果不是Mac而是Linux服务器部署这里填的应该是服务器对外IP或者内部容器网络IP很多人第一次部署时在这个细节上绕了很久我列出来强调一下。如果你不想折腾本地模型直接接在线大模型更省事。Dify内置了几十家模型厂商的接入模板包括OpenAI、Anthropic、DeepSeek等。以DeepSeek为例你只需要去DeepSeek开放平台注册账号、创建API Key然后把Key填进Dify的模型供应商配置里选择对应的模型名称例如deepseek-chat测试连通性通过就完事。在线模型的优势是推理速度快、能力更强劣势是要联网、按量计费。我个人实际使用中习惯接两套模型日常简单对话、知识库试验用本地qwen2.5:7b成本为零也不怕网络波动正式验证工作流、做复杂Agent任务时用DeepSeek或GPT等在线模型效果更稳定。而且Dify支持在应用设置里配置多个模型并自由切换所以不存在二选一的纠结。5. 上手第一步创建第一个应用与工作流的踩坑实录Dify部署成功并且接好模型之后你已经可以开始创建AI应用了。但这里我建议别急着进工作流编辑器去连一堆节点最好先创建一个最基础的“聊天助手”应用把链路跑通确认模型调用、上下文传递、日志查看这些基础能力正常再上复杂功能。创建应用的路径是在Dify首页点击“创建应用”选择“聊天助手”填好应用名称后进入“编排”页面。在模型选择框里选中你配置好的模型然后在提示词编辑器里写一段简单的System Prompt比如“你是一个乐于助人的助手”保存后点右上角的“预览”打开调试对话框发一句话。如果模型正常回复说明全链路通了这是最基本的冒烟测试。通了之后就可以试试工作流。Dify的工作流本质是一个可视化编排器把LLM调用、代码执行、条件分支、工具调用串联成一个流程图。创建应用时选择“工作流”类型你会进入一个节点画布左侧是各种可拖拽的节点开始节点、大模型节点、知识检索节点、代码执行节点、条件分支节点、HTTP请求节点、结束节点等。一个典型的入门工作流是开始节点接收用户输入传给大模型节点大模型根据指令返回结果结束节点把结果输出。拖完节点把节点之间的连线接好点运行填一个测试输入看看跑通没有。这里常见的坑是节点之间数据变量名的对应关系搞混。比如大模型节点的“系统提示词”里引用用户输入要用{{#start#.input#}}这种变量语法结束节点的输出要引用大模型节点输出得写成{{#llm_1#.text#}}。我第一次创建时就在这块绕了弯总是从变量选择器里去选其实Dify已经替你封装好了选择器点输入框右侧的变量按钮就能选记住这个操作能省很多心。如果你有外部知识文档需要让模型参考就要在Dify里新建“知识库”上传文档Dify会做分段、清洗、向量化处理然后把它挂到应用的“上下文”里。这里的原理很简单把用户问题和知识库里的片段做语义相似度检索找出最相关的文本片段拼进Prompt再喂给大模型回答。所以知识库的实用体验受文档质量、分段策略、检索方式和Embedding模型共同影响不是上传文件就完事的。6. 常见问题排查技巧口袋里那些救命经验部署过程中没有完全顺利的我自己两次部署加上帮朋友远程排查记录了一批高频坑。这里挑几个最常见的放出来希望能让你少走点弯路。6.1 启动后容器反复重启的排查流程遇到docker compose up -d之后容器状态不是Up而是Restarting不要慌先看日志docker compose logs -f 服务名服务名指的是api、worker、web、db这些。最常见的日志内容是数据库连接失败或密码不匹配这时候检查.env里的POSTGRES_PASSWORD是不是被改过而db服务没用上同一个值。另一个常见情况是api容器启动时连接不到Redis看日志会看到redis connection refused的报错。这种情况通常是Redis容器还没完全ReadyApi服务就抢先连了等个十秒再docker compose restart api通常会好。还有一个频率很高的坑磁盘空间不足。Dify的镜像加上运行期间产生的向量库数据、日志很容易把系统盘占满。在Mac上检查磁盘空间df -h ~如果使用率超过了90%建议先清理Docker的悬空镜像docker system prune再重启服务。6.2 端口被占用的处理办法expose-nginx-port默认是80Mac上很多服务比如Apache、Nginx、或别的监听80端口的程序会冲突。启动后容器总是重启docker logs nginx里显示bind: address already in use。解决办法是修改.env里的EXPOSE_NGINX_PORT改成8080或者其他你确认空闲的端口然后重新启动docker compose up -d6.3 登录时提示密码错或错误次数过多Dify在连续多次输错密码后会锁定一段时间并提示“too many incorrect password attempts”。这个机制没有直观的后台界面提示只能等锁定期过。如果你是在测试环境不想等就去Postgres里把失败的登录记录清掉或者干脆重置管理员密码。操作方式比较复杂建议还是老实等锁定期顺便检查一下密码大小写和特殊字符。我遇到过有人把邮箱输错了还怪系统排查半天发现账号绑定的邮箱根本不是自己以为的那个。6.4 Ollama模型响应超时如果本地模型在Dify里测试时经常报超时多半是模型推理太慢而Dify默认的调用超时时间偏短。这时候看两个地方一是Ollama所在机器是不是CPU Performance降频运行ollama的同时还在跑Docker容器造成资源竞争二是在Ollama服务的启动参数里调成后台运行并在Dify里把模型供应商的超时设置调高。Apple Silicon的Mac本身跑7B模型没问题但如果你同时运行Dify全家桶和Ollama推理16G内存会吃紧内存压力一大整个系统都会卡。6.5 升级Dify的正确姿势Dify版本更新很快每次Release都会带新功能和修复。社区版升级的流程我并不推荐动不动就换tag得先把旧容器拉起来看版本再决定要不要升。简单说升级的核心是两步先更新源码到目标版本tag再重启容器因为新的Compose文件可能会带新增服务定义。备份很重要升级前最好把数据库和存储卷的备份做一下。如果你用的是docker compose管理推荐备份方案是把docker目录下的volume目录拷一份虽然有点笨但恢复起来很直接。7. 进阶扩展让Dify在Mac上更好用的几个方向部署完成只是开始我把Mac上后续值得做的事列几个方向。第一把Dify接入更多工具比如让它调用HTTP请求节点去访问你内网的服务、调用自定义代码节点去运算分析逻辑。第二做多租户隔离社区版1.10开始已经支持多租户能力虽然入口埋得比较深但如果你有团队协作需求值得研究。第三把后端嵌入到自己的业务系统里Dify提供了完善的API和Webhook可以把它当做一个模型编排后端来对接。除此之外日常运维上建议养成两个习惯一是定期看容器日志用docker compose logs -f api盯着有没有异常二是注意Dify各容器版本别乱动保持源码、镜像、Compose文件的版本一致否则组合出bug是常事。Dify社区版官方文档更新得也很快遇到问题先查官方文档的部署章节再查GitHub Issues大多数坑都是公开的。我个人实际使用中的体会是在整个部署过程里最耗时间的部分不是命令本身而是理解各容器的职责和数据流向。Dify的容器编排不算复杂但当你搞清楚api负责业务逻辑、worker负责异步任务、sandbox负责代码执行隔离、db与redis负责状态存储之后你就能游刃有余地调整配置而不是背命令。最后再分享一个小技巧如果你觉得自己在Mac上折腾Docker资源消耗较大可以趁空闲时把Dify和Ollama分别跑在两台电脑上Dify负责编排Ollama负责推理只要互为局域网就能接通性能和稳定性都会好上一截。