Dify服务部署指南

Dify 是一款开源的大语言模型应用开发平台，能够帮助开发者快速构建智能体和工作流等AI应用。

目录
[1. 系统要求](#1. 系统要求)

[2. 安装依赖](#2. 安装依赖)

[2.1 安装docker](#2.1 安装docker)

[2.2 安装docker compose](#2.2 安装docker compose)

[3. 克隆 Dify 仓库](#3. 克隆 Dify 仓库)

[4. 环境配置](#4. 环境配置)

[4.1 服务端口配置修改（可选）](#4.1 服务端口配置修改（可选）)

[4.2 插件相关配置修改](#4.2 插件相关配置修改)

[4.3 数据相关配置修改](#4.3 数据相关配置修改)

[5. Dify部署](#5. Dify部署)

[5.1 启动dify服务](#5.1 启动dify服务)

[5.2 关闭dify服务](#5.2 关闭dify服务)

[5.3 进入dify可视化页面](#5.3 进入dify可视化页面)

[6. dify容器说明](#6. dify容器说明)

[6.1 核心业务服务](#6.1 核心业务服务)

[6.2 基础支撑组件](#6.2 基础支撑组件)

[6.3 其他辅助服务](#6.3 其他辅助服务)

[6.4 日志查看说明](#6.4 日志查看说明)

[7. dify源码说明](#7. dify源码说明)

---

1. 系统要求

在开始部署之前，请确保你的服务器满足以下要求：

• 操作系统：Linux（推荐使用 Ubuntu 20.04 或更高版本）
• 内存：至少 4GB RAM
• 存储：至少 20GB 可用空间
• 网络：稳定的互联网连接

2. 安装依赖

Dify 推荐使用 Docker 来简化部署过程，确保已安装docker和docker compose。

2.1 安装docker

# 安装
sudo apt-get update && sudo apt-get upgrade -y
sudo apt-get install docker.io

# 启动docker
sudo systemctl start docker

# 查看docker状态
systemctl status docker

2.2 安装docker compose

sudo apt-get install docker-compose

3. 克隆 Dify 仓库

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

4. 环境配置

进入到dify目录下的docker文件夹下，复制一份示例配置到 .env

cp .env.example .env

4.1 服务端口配置修改（可选）

考虑到端口占用的问题，如果需要修改dify可视化界面端口，需要调整相关配置项。将变量EXPOSE_NGINX_PORT修改为新的可视化界面端口。

修改.env文件下，Nginx的默认端口号。80改成8099，443改成4433等非默认端口，防止冲突。

4.2 插件相关配置修改

导入本地插件，需要调整相关配置项，避免对本地插件进行验证。

将变量FORCE_VERIFYING_SIGNATURE设置为false。

4.3 数据相关配置修改

在工作流中，为了工作流的正常运行，需要对部分数据长度配置项进行修改。

避免由于业务数据中，列表长度过大，导致代码执行报错的情况。

变量CODE_MAX_STRING_ARRAY_LENGTH、CODE_MAX_OBJECT_ARRAY_LENGTH修改为300。

5. Dify部署

5.1 启动dify服务

进入dify源码项目，执行下面的操作，启动dify容器

cd dify/docker
docker compose up -d          # 启动

会拉取镜像并启动相关容器。

5.2 关闭dify服务

docker compose down

5.3 进入dify可视化页面

首次进入，需要注册用户登陆信息。注册完成后，将出现登陆界面。

6. dify容器说明

默认的基础dify框架，其框架如下图所示。

dify框架中使用的容器和镜像列表如下：

|-------------------|-------------------------------------------|
| 服务名 | 镜像名 |
| api | langgenius/dify-api:1.7.1 |
| worker | langgenius/dify-api:1.7.1 |
| worker_beat | langgenius/dify-api:1.7.1 |
| web | langgenius/dify-web:1.7.1 |
| db | postgres:15-alpine |
| redis | redis:6-alpine |
| sandbox | langgenius/dify-sandbox:0.2.12 |
| plugin_daemon | langgenius/dify-plugin-daemon:0.2.0-local |
| ssrf_proxy | ubuntu/squid:latest |
| nginx | nginx:latest |
| weaviate | semitechnologies/weaviate:1.19.0 |

备注：

其中的redis可以替换为本地已经部署的redis服务

基于上面的框架图和dify容器列表，对dify框架中的各个容器进行说明。

1. nginx：

• • 作用：作为反向代理服务器，处理来自用户的所有请求。它根据请求的路径将请求分发到不同的服务，例如/explore、/api/v1/files和/e/。
  • 镜像：nginx:latest

2. web：

• • 作用：提供Web前端服务，处理用户通过浏览器发起的请求，如资源请求。
  • 镜像：langgenius/dify-web:1.7.1

3. SSRF Proxy：

• • 备注：squid是代理服务器软件，可以充当代理服务器，将用户的请求转发给上游代理，从而为应用程序提供额外的控制。
  • 作用：在使用dify的过程中，会遇到通过代理服务器来访问外部网络的情况。dify使用 ssrf proxy（squid）来提升sandbox的安全性。通过配置squid代理可以实现所有http请求都通过上游代理进行转发的要求。
  • 镜像：ubuntu/squid:latest

4. api：

• • 作用：核心API服务，处理来自nginx的API请求。它与数据库、缓存、插件守护进程和沙箱服务交互。
  • 镜像：langgenius/dify-api:1.7.1

5. worker：

• • 作用：工作队列服务，处理异步任务，如保存数据到数据库或向插件守护进程发送请求。
  • 镜像：langgenius/dify-api:1.7.1

6. worker_beat：

• • 作用：用于定时任务或心跳检测，确保系统组件正常运行。
  • 镜像：langgenius/dify-api:1.7.1

7. db (postgres)：

• • 作用：数据库服务，存储系统数据，如用户信息、文件元数据等。
  • 镜像：postgres:15-alpine

8. redis：

• • 作用：缓存服务，用于存储临时数据，提高数据访问速度。
  • 镜像：redis:6-alpine

9. sandbox：

• • 作用：沙箱服务，提供一个安全的环境来执行代码，防止恶意代码影响系统。
  • 镜像：langgenius/dify-sandbox:0.2.12

10. plugin_daemon：

• • 作用：插件守护进程，管理插件的加载和执行，允许系统扩展功能。
  • 镜像：langgenius/dify-plugin-daemon:0.2.0-local

11. vector database (weaviate)：

• • 作用：向量数据库，用于存储和检索向量化的数据，可能用于机器学习模型的输入。
  • 镜像：semitechnologies/weaviate:1.19.0

这些容器共同构成了Dify系统，每个容器都有其特定的功能和作用，确保系统的运行。

6.1 核心业务服务

这部分是Dify平台功能的直接提供者。

容器/服务名	核心功能	常用端口
api	提供平台所有核心功能的API接口。	5001
worker	执行异步任务，如知识库文档处理、工作流执行等。	-
web	提供平台的Web前端用户界面。	3000

6.2 基础支撑组件

这些是平台运行所依赖的后端服务。

容器/服务名	核心功能	常用端口
db (PostgreSQL)	存储应用数据、用户信息、知识库元数据等核心业务数据。	5432
redis	用作任务队列、缓存和会话存储。	6379
nginx	作为反向代理，将前端请求转发到后端服务。	80, 443
weaviate (可选)	向量数据库，用于存储和处理文档向量，实现RAG检索功能。不使用RAG时可不启动。	-

6.3 其他辅助服务

根据部署版本或配置，可能还会看到以下部分或全部服务：

• sandbox：代码执行沙箱，用于安全地运行工作流中的自定义代码。

• worker_beat：定时任务调度器，用于触发周期性任务。

• ssrf_proxy：SSRF代理，用于安全地访问外部网络资源。

• plugin_daemon：插件守护进程，用于管理和运行插件。

6.4 日志查看说明

当工作流被调用后出现异常，你需要重点关注 api 容器和 worker 容器的日志。这两个容器是处理工作流执行与异步任务的核心。

下面这个表格整理了关键容器及其日志的查看方法，你可以快速了解：

容器/服务名	日志查看方法（在docker-compose.yml所在目录执行）	日志内容与排查重点
api	docker-compose logs api 或 docker logs dify-api	核心排查目标 ：记录所有工作流API调用的请求、响应和执行过程中的错误。当工作流节点调用失败时，这里会留下关键记录。
worker	docker-compose logs worker 或 docker logs dify-worker	核心排查目标：处理异步任务（如知识库索引、部分耗时操作）。如果工作流涉及这类后台任务，其错误日志会在这里。
web	docker-compose logs web	主要记录前端界面相关的访问日志，通常与工作流业务逻辑错误无关。
nginx	docker-compose logs nginx	记录HTTP访问日志和错误码（如502、504），可用于判断请求是否成功到达后端api服务。
db/redis	docker-compose logs db	通常只有在怀疑数据库连接或查询出现根本性问题时才需要查看。

掌握以下几个命令，可以帮助更快定位问题：

• 查看实时日志 ：docker-compose logs -f api 或 docker-compose logs -f worker。-f 参数可以实时跟踪日志输出。

• 限定时间范围 ：docker-compose logs api --since 1h 可以只查看最近1小时的日志。

• 过滤错误信息 ：结合 grep 命令快速筛选，例如 docker-compose logs api | grep -i error 来查找错误行。

• 结构化日志解析 ：Dify日志通常是JSON格式，使用 jq 工具可以更清晰地解析，例如：docker-compose logs api | jq 'select(.level == "error")'

7. dify源码说明

Dify 采用"前后端分离 + 多进程组件"的形态 （ 模块化的"Beehive 架构" ）

①Web（/web）：Next.js 前端，负责控制台、工作流画布、应用配置 UI。

②API（/api）：Python 后端（Flask 家族生态，见源码/文档中的 Flask 线索与迁移命令），提供控制台/应用/工作流/RAG/模型管理等核心 REST 接口，出队/入队任务等。

③Worker：通常与 API 同代码库部署，以 Celery/RQ 等队列执行耗时任务（索引、文件解析、长推理等），具体以版本为准。

④向量检索/外部服务：Weaviate 等向量库（近几个版本提示需升级到 ≥1.24 并开放 gRPC 50051 端口），以及模型供应商/推理网关。

⑤Plugin Daemon（独立仓库/镜像）：插件生命周期管理器，负责本地/调试/Serverless 三种运行时，承载"数据源/Endpoint"等插件执行。

---