跳转到主要内容
本文档由 AI 自动翻译。如有任何不准确之处，请参考 英文原版。
默认的 Docker Compose 部署自带 PostgreSQL、Weaviate 及 Dify 运行所需的其他服务，无需事先准备数据库或向量数据库。

​
部署前准备

​
硬件

  • CPU：至少 2 核
  • 内存：至少 4 GiB

​
软件

安装 Docker 和 2.35.0 或更高版本的 Docker Compose，并确保 Docker 守护进程正在运行。此外，还需用 Git 下载 Dify，用 OpenSSL 为 Agent 的本地沙箱生成令牌。 开始前检查 Compose 版本：

​
部署并启动

已有部署改按 升级 步骤操作，以保留其配置和数据。
1

获取 Dify 发行版

从 Dify releases 选择一个版本并克隆，将 <version> 替换为该版本的标签：
2

配置启动设置

从模板创建配置文件：
为 Agent 的本地沙箱生成令牌：
在 .env 中，将 DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN 设为上面命令的输出。Agent 后端和它的本地沙箱都要有这个共享令牌才能启动。
首次启动前：
  • 用于生产环境时，先设置 安全加固 中列出的凭据。
  • 如需用其他自带的向量数据库或 MySQL 替代 Weaviate 和 PostgreSQL，在 .env 中设置。首次启动后再切换，已有数据不会随之迁移。各自所需的设置详见 VECTOR_STORE 和 数据库配置。
3

启动并检查服务

在 dify/docker 中运行：
持续运行的服务应显示 Up 或 healthy。init_permissions 任务只运行一次，负责准备存储权限，完成后显示 Exited (0)。

​
访问

在浏览器中打开 http://localhost/install，创建管理员账户，然后在 http://localhost 登录。 远程部署时，将 localhost 替换为服务器的 IP 地址或域名。默认 HTTP 端口为 80。如果 80 端口已被占用，在 docker/.env 中将 EXPOSE_NGINX_PORT 设为其他端口，并在访问地址中带上该端口。
如需在远程服务器上使用实时协作，在 docker/.env 中添加 NEXT_PUBLIC_SOCKET_URL，值为服务器的 WebSocket 地址，然后运行 docker compose up -d。

​
自定义

作用于整个部署的设置写在 docker/.env 中，包括 Compose profile、对外发布的端口、挂载路径、健康检查调度，以及 安全加固 中的共享凭据。 其他设置按服务分开存放。大多数服务会加载 docker/envs/ 下自带的 .defaults 文件。不要改动这些文件，把修改写进注释里指明的本地 .env 文件。API、Worker 和定时任务共用的设置写在 envs/core-services/api-worker.env 中。 例如，要将 Nginx 的请求体大小上限提高到 200M，在 dify/docker 中执行以下步骤：
1

设置覆盖值

如果 envs/infrastructure/nginx.env 不存在，先创建：
在 envs/infrastructure/nginx.env 中设置：
2

应用修改

验证配置，然后重建受影响的容器：
这里要用 up -d，不能用 docker compose restart：restart 会沿用容器原有的环境变量。
3

检查生效值

查看 Nginx 当前生效的配置：
输出应包含 client_max_body_size 200M;。如果显示的是其他值，先检查 docker/.env 中是否设置了覆盖值；值还可能来自其他位置，详见 优先级。
全部变量及完整的优先级规则，详见 环境变量。

​
安全加固

开放给他人访问之前，先配置 HTTPS，并替换 docker/.env 中自带的开发凭据：
  • 数据库和 Redis：DB_PASSWORD 和 REDIS_PASSWORD。
  • 代码执行沙箱：将 SANDBOX_API_KEY 和 CODE_EXECUTION_API_KEY 设为同一个强密钥。详见 沙箱服务。
  • Weaviate：将 WEAVIATE_API_KEY 设为强密钥，并把它加入 WEAVIATE_AUTHENTICATION_APIKEY_ALLOWED_KEYS；再设置 WEAVIATE_AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED=false，强制要求身份认证。详见 向量数据库服务配置。
  • 插件守护进程：为 PLUGIN_DAEMON_KEY 和 PLUGIN_DIFY_INNER_API_KEY 分别设置不同的强密钥。详见 插件守护进程配置。
  • Agent：替换 DIFY_AGENT_API_TOKEN，并按要求的格式生成 DIFY_AGENT_SERVER_SECRET_KEY。保留配置启动设置时生成的 DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN。
如果 Dify 已经在运行，执行 docker compose up -d 让新值生效。数据库密码例外：数据库初始化后，要先在数据库服务器上修改密码，再相应更新 DB_PASSWORD。
SECRET_KEY 保持原样即可：如果没有设置，Dify 会在首次启动时生成一个随机密钥，并与数据一起保存。之后再设置或修改它，用旧密钥签名的令牌和文件链接都会失效。它影响的全部内容详见 SECRET_KEY。
默认部署栈不会将数据库、Redis、代码执行沙箱或 Weaviate 的端口发布到宿主机。在私有网络中，也应限制对这些服务的访问。

​
升级

在 Dify releases 选择目标版本，并先阅读该版本的升级说明。 下面的每条 Compose 命令都要沿用该部署现有的项目名称和 Compose 文件（包括所用的 -p、-f 选项或 COMPOSE_PROJECT_NAME），这样原有的命名卷才会继续挂载。
1

备份部署

  1. 在 dify/docker 中停止部署，避免复制数据库文件时数据库仍在写入：
    如果无法停止部署，改用数据库自带的转储工具备份。
  2. 备份 docker/.env、本地服务 .env 文件、自定义 Compose 文件和持久化数据。持久化数据包括 docker/volumes/，以及所用的外部数据库和存储。
  3. 如果部署包含 local_sandbox，还需备份它挂载到 /home/dify 和 /workspace 的命名卷。卷名带有 Compose 项目前缀，可用以下命令列出：
  4. 保存 docker compose config 的输出，用于更新后对比。输出包含密钥，需妥善保管。
2

更新到新版本

Git 不跟踪本地 .env 文件和 docker/volumes/ 中的数据，因此检出新版本后，它们仍保留在原处。如果修改过 docker-compose.yaml 等 Git 跟踪的文件，先暂存这些修改。在仓库根目录运行：
然后将修改重新应用到新版本的文件中（例如运行 git stash pop），如有冲突，逐一解决。
3

检查配置

对比 docker/.env.example 与现有的 docker/.env，并将每个本地服务文件与对应的 .defaults 或 .env.example 模板对比。在现有文件中更新所需的设置；直接用模板覆盖这些文件，会丢掉你设置的覆盖值。如果某项设置在模板中改了名，改用新名称。Container variable mappings 下的各行保持不变。保留现有数据库，以及知识库仍在使用的每个向量数据库，连同它们的连接设置和 Compose profile。修改 DB_TYPE 或 VECTOR_STORE 不会迁移数据。最后，将新的 docker compose config 输出与之前保存的副本对比，检查凭据、数据卷路径、profile 和你自定义的设置。
4

应用并检查升级结果

在 dify/docker 中运行：
持续运行的服务应显示 Up 或 healthy，init_permissions 应显示 Exited (0)。然后打开 Dify，试用依赖自定义设置的功能。
最后修改于 2026年11月4日