Dify本地部署与使用全攻略：从零搭建你自己的AI工作流

说实话，我最开始接触Dify的时候，纯粹是因为受够了各种云端AI平台的限制——数据隐私问题、调用次数计费、模型不能自选……折腾了一圈之后，发现Dify这个开源项目是真的香。下面把我踩过的坑和摸索出来的经验都分享给大家，希望你们少走弯路。

为什么我选了本地部署而不是直接用云服务

Dify，全称"Do It For You"，是一个开源的AI工作流构建平台。说白了就是让你用拖拖拽拽的方式，把大模型的能力串成一个完整的应用。

我选本地部署的原因很简单：

• 数据不想出去：公司内部的知识库、客户数据，你敢传到别人的服务器上？
• 想用啥模型就用啥模型：云端平台一般就给你几个选项，本地部署你可以接OpenAI、接DeepSeek、甚至自己跑Ollama拉个开源模型下来
• 省钱：高频调用场景下，按token计费能把你搞破产，自己部署一劳永逸
• 能改代码：源码都在手上，想怎么定制就怎么定制

我之前给公司搭了一个内部知识库问答系统，用的就是Dify，效果出乎意料的好，老板还以为我花了大价钱请人开发的（其实就是我自己撸的）。

部署实战：我踩过的那些坑

先把环境准备好

硬件要求其实不高：

• CPU至少2核
• 内存至少4GB，但我强烈建议8GB以上，不然跑起来会卡
• 硬盘20GB起步

软件方面需要Docker和Docker Compose：

# Ubuntu上装Docker

sudo apt-get update

sudo apt-get install docker.io docker-compose-plugin

# 确认版本没问题

docker --version

docker compose version

踩坑提醒：我第一次用的是一台2GB内存的机器，结果启动到一半各种容器OOM挂掉，排查了半天才发现是内存不够。Docker Desktop用户记得在设置里把内存分配调到8GB以上。

拉代码、改配置

# 克隆Dify代码

git clone https://github.com/langgenius/dify.git

# 进入Docker部署目录

cd dify/docker

# 复制环境配置文件，这步千万别忘

cp .env.example .env

.env文件里有一大堆配置项，新手直接用默认值就行。但如果你要上生产环境，密码一定要改！我见过太多人直接用默认密码然后被扫的案例了。

启动服务

# 后台启动

docker compose up -d

# 看看容器状态，确保都是Up或者healthy

docker compose ps

# 如果有问题就看日志

docker compose logs -f api

启动之后会拉起13个容器，第一次可能要等几分钟。主要的几个：

• api：后端API服务，处理所有请求
• worker：干活的，处理文档解析、模型推理这种耗时任务
• web：前端页面
• db_postgres：PostgreSQL数据库
• redis：缓存
• weaviate：向量数据库，知识库检索靠它
• nginx：反向代理，统一入口

访问 http://localhost 就能看到Dify的控制台了，第一次会让你设置管理员账号。

又一个坑：我有次在服务器上部署，80端口被nginx占了，Dify的nginx容器起不来。解决办法是改.env里的端口映射，或者把原来的nginx停掉。

模型接入：别只盯着OpenAI

接云端API

进"设置"->"模型供应商"，添加你想用的模型。

我个人推荐的组合：

• 主力模型：GPT-4o，综合能力确实强，但贵
• 日常模型：DeepSeek Chat，性价比极高，日常任务完全够用
• 离线模型：Ollama跑本地开源模型，完全不联网

拿DeepSeek举例，在模型供应商里选DeepSeek，填入API Key，选个模型（比如deepseek-chat），验证一下连接就行了。

本地跑模型（Ollama）

这个是我特别想说的，因为很多场景确实需要完全离线：

# 安装Ollama

curl -fsSL https://ollama.com/install.sh | sh

# 拉个模型下来，qwen2.5:7b不错，7B参数在普通机器上也能跑

ollama pull qwen2.5:7b

# 启动服务

ollama serve

然后在Dify里配置Ollama：

• 模型供应商选"Ollama"
• 基础URL填：http://host.docker.internal:11434（这个地址是Docker内部访问宿主机的特殊地址，别填成localhost）
• 模型名称填：qwen2.5:7b

大坑警告：很多人填http://localhost:11434发现连不上，那是因为Dify跑在Docker容器里，localhost指的是容器自己，不是宿主机。必须用host.docker.internal或者宿主机的实际IP。我在这卡了快一个小时才反应过来。

动手做几个应用

聊天机器人：5分钟搞定

最简单的入门方式：

1. "创建应用" -> 选"聊天助手"
2. 起个名字，选个模型
3. 写个系统提示词，比如：

你是一个专业的客服助手，请礼貌地回答用户问题。

如果不知道答案，请坦诚说明并建议转人工。

回答控制在200字以内。

4. 右边调试区试试效果，觉得OK就发布

工作流编排：这才是Dify的杀手锏

我搭过一个"小红书读书卡片生成器"，流程是这样的：

1. 开始节点：接收书名和简评
2. LLM节点1：生成吸引人的标题和核心观点
3. LLM节点2：写适合社交媒体的文案
4. 代码节点：格式化输出
5. 结束节点：返回最终结果

LLM节点的提示词大概长这样：

你是社交媒体文案专家，擅长把阅读感悟变成有吸引力的短内容。

书名：{{book_name}}

用户简评：{{user_review}}

请生成：

1. 吸引人的标题（10字以内）

2. 3个核心观点（每点15字以内）

3. 适合小红书的文案（带emoji，150字以内）

把节点之间连线串起来，调试几轮，一个完整的小应用就出来了。整个过程不需要写一行代码（除了代码节点里那点格式化逻辑）。

知识库：企业内部问答的神器

这个功能我用得最多，步骤也不复杂：

1. 创建知识库，上传文档（PDF、Word、TXT、Markdown都支持）
2. 选择分段策略，我一般用自动分段
3. 索引方式选"高质量模式"（基于向量检索）
4. 在聊天助手的编排里加上"知识检索"节点，关联这个知识库

实战经验：

• 文档质量很重要，乱七八糟的格式会影响检索效果，上传前先清理一下
• 分段太长太短都不好，500-1000字一段比较合适
• 知识库要定期更新，业务变了文档也要跟着变
• 用"知识库调试"功能多测几轮，看看检索出来的东西是不是你想要的

智能体：让AI自己调工具

Dify的Agent模式可以集成外部工具，比如我搭过一个数据库查询助手：

1. 创建Agent类型的应用
2. 添加数据库工具，填上连接信息
3. 给Agent写个指令，告诉它怎么用SQL查数据

你是数据分析助手，可以通过SQL查询数据库回答业务问题。

查询前请确认权限范围，不要执行任何修改操作。

4. 开启"思考过程"，这样用户能看到AI的推理步骤，增加可信度

生产环境：别光能跑就行

性能优化

数据库和Redis的调优很关键：

# PostgreSQL调优，在docker-compose.yaml里改

db_postgres:

  command: postgres -c shared_buffers=256MB -c work_mem=16MB

  shm_size: '256mb'

Redis内存限制在.env里改：

REDIS_MAXMEMORY=512mb

REDIS_MAXMEMORY_POLICY=allkeys-lru

安全问题

这个真的不能马虎：

1. 所有默认密码必须改掉
2. 配HTTPS，用nginx挂SSL证书
3. 只暴露80/443端口，其他服务都放内网
4. 定期备份数据库：

# 备份PostgreSQL

docker compose exec db_postgres pg_dump -U postgres dify > dify_backup.sql

升级维护

# 拉最新代码

git pull origin main

# 停掉旧服务，拉新镜像，重启

docker compose down

docker compose pull

docker compose up -d

# 确认状态

docker compose ps

升级前一定要先备份，别问我怎么知道的。

最后说几句

Dify这个项目真的改变了我对AI应用开发的看法。以前觉得搭一个AI应用得从头写代码，现在用Dify拖拖拽拽就能搞定大部分场景。

几个建议：

• 从简单的聊天助手开始，别一上来就搞复杂工作流
• 多试试不同的模型，不同场景下最优选择不一样
• 关注Dify的MCP协议支持和插件系统，这是未来的方向
• 遇到问题先看官方文档和GitHub Issues，大部分坑前人都踩过了

技术这东西，光看不练永远学不会。建议你现在就拉个Dify下来跑起来，遇到问题再回来翻这篇文章，效果绝对比光看不动手好十倍。