当前位置：首页 > news >正文

Windows系统基于Docker一键部署Dify：彻底解决AI应用开发环境难题

news 2026/7/5 11:20:17

🚀 30+款热门AI模型一站整合，DeepSeek/GLM/Qwen 随心用，限时 5 折。 👉 点击领海量免费额度

想在自己的Windows电脑上快速搭建一个AI应用开发平台，却总被复杂的Python环境、版本冲突和依赖问题劝退？看着别人用Dify轻松构建AI工作流，自己却卡在第一步的部署上？

如果你也有这样的困扰，那么这篇文章就是为你准备的。我将带你用最简单、最干净的方式，在Windows系统上基于Docker完成Dify的本地部署。这不是一篇泛泛而谈的“安装指南”，而是结合了实战经验、避坑要点和最佳实践的完整教程。你将了解到，为什么Docker是Windows部署Dify的最佳选择，以及如何避免那些官方文档可能没细说，但新手极易踩中的“坑”。

读完本文，你将能独立完成从零到一的部署，并理解每一步背后的原理，最终获得一个稳定、可复用的本地AI应用开发环境。

1. 这篇文章真正要解决的问题

对于许多开发者，尤其是AI应用开发者而言，最大的痛点往往不是模型算法本身，而是环境。你想快速体验或开发一个基于大语言模型的应用，比如一个智能客服、一个文档问答机器人，但第一步“把环境跑起来”就可能耗费半天甚至更久。Python版本冲突、CUDA驱动问题、各种pip包依赖报错……这些“脏活累活”极大地消耗了开发热情。

Dify作为一个优秀的LLM应用开发平台，其价值在于让开发者聚焦于应用逻辑（工作流、提示词、知识库），而非底层环境。然而，Dify自身的部署，如果采用传统的Python源码方式，在Windows上依然会面临上述所有环境难题。

本文要解决的核心问题就是：如何在Windows系统上，以最高效、最隔离、最可复现的方式，一键部署并运行Dify，彻底摆脱环境依赖的噩梦。我们的解决方案是Docker。这不仅仅是“能用”，而是追求“好用”和“稳定”。我们将深入探讨：

为什么Docker是Windows部署的首选？它如何解决环境隔离和依赖冲突？
Windows上使用Docker有哪些特有的“坑”？比如文件系统性能、网络配置、资源限制。
如何配置Dify的关键组件？如数据库、向量数据库、对象存储，并让它们在Docker中协同工作。
部署成功后，如何进行初步验证和常见问题排查？

无论你是想本地测试Dify功能，还是为团队搭建一个内网开发环境，这篇基于Docker的部署指南都将提供一条清晰的路径。

2. 基础概念与核心原理

在开始动手之前，我们需要统一认知，理解几个关键概念，这能帮助你在遇到问题时更快地定位和解决。

Dify是什么？Dify是一个开源的LLM应用开发平台。你可以把它理解为一个“可视化、低代码的AI应用工厂”。它提供了图形化界面（Workflow）来编排AI处理流程，内置了提示词工程、知识库（RAG）、模型管理、应用发布等核心功能。开发者无需从零开始写代码调用API，就能快速构建出功能丰富的AI应用。

Docker与Docker Compose是什么？

Docker：一种容器化技术。你可以把它想象成一个极其轻量化的虚拟机。它把应用程序及其所有依赖（库、环境变量、配置文件）打包成一个独立的“容器镜像”。这个镜像在任何安装了Docker的机器上都能以完全相同的方式运行，实现了“一次构建，处处运行”。
Docker Compose：一个用于定义和运行多容器Docker应用程序的工具。一个像Dify这样的复杂应用，通常由多个服务组成（如Web前端、后端API、数据库、Redis等）。Docker Compose允许你用一个docker-compose.yml文件来配置所有这些服务，然后用一条命令docker-compose up同时启动它们，并处理好服务间的网络连接。

为什么在Windows上用Docker部署Dify是优选方案？传统部署方式（直接在Windows上安装Python、Node.js、PostgreSQL等）存在诸多问题：

环境污染：不同项目可能需要不同版本的Python包，容易冲突。
依赖复杂：手动安装和配置数据库、消息队列等中间件，步骤繁琐易错。
系统差异：在Windows开发环境配好了，迁移到Linux服务器可能又出问题。
清理困难：卸载不彻底，残留文件可能影响系统。

使用Docker部署，则完美规避了以上问题：

环境隔离：Dify及其所有依赖都被封装在容器内，与宿主机（你的Windows）完全隔离。
一键部署：通过Docker Compose文件，所有服务一键启动。
一致性：开发、测试、生产环境可以使用完全相同的镜像，保证一致性。
易于清理：停止容器、删除镜像，环境即被彻底清除，不留痕迹。

核心架构理解：一个典型的Dify Docker部署包含以下核心服务，它们通过Docker Compose定义的内部网络进行通信：

api服务：Dify的后端核心，提供RESTful API，使用Python编写。
worker服务：异步任务处理（如知识库文档解析、模型长文本处理），通常与api服务共享代码库。
web服务：Dify的前端界面，基于React/Vue等框架，用户通过浏览器与此服务交互。
postgres服务：关系型数据库，用于存储应用数据、用户信息、工作流定义等。
redis服务：缓存和消息队列，用于提升性能和处理异步任务。
（可选）weaviate/qdrant/milvus服务：向量数据库，用于知识库的向量化存储和相似性搜索。

理解了这些，我们就知道接下来的每一步是在搭建一个怎样的“微服务集群”。

3. 环境准备与前置条件

工欲善其事，必先利其器。在Windows上通过Docker部署Dify，你需要准备好以下环境和工具。请严格按照步骤操作，这是后续所有操作的基础。

3.1 系统要求

操作系统：Windows 10 版本 2004 及更高版本（包含Build 19041及更高版本）或 Windows 11。必须启用WSL 2（Windows Subsystem for Linux 2）或启用Hyper-V。这是Docker Desktop for Windows运行的必要条件。
内存：建议至少8GB，16GB或以上为佳。运行多个容器（特别是向量数据库）会比较吃内存。
磁盘空间：至少预留20GB可用空间，用于存放Docker镜像和容器数据。
CPU：现代多核处理器即可。

3.2 安装 Docker Desktop for Windows

这是最关键的一步。Docker Desktop是Windows和Mac上运行Docker的官方桌面应用。

下载：访问 Docker 官网的 Docker Desktop for Windows 下载安装包。
安装：运行安装程序，安装过程中会提示启用WSL 2或Hyper-V。强烈建议使用WSL 2后端，因为它性能更好，与Linux的兼容性更佳。如果系统不支持WSL 2，则会使用Hyper-V。
启动与登录：安装完成后，启动Docker Desktop。首次启动可能需要几分钟进行初始化。建议注册并登录Docker Hub账号，但非必须。
验证安装：打开Windows PowerShell或命令提示符（CMD），运行以下命令：
```
docker --version docker-compose --version
```
如果正确显示版本号（Docker Compose版本建议在2.24.0+），说明安装成功。同时，系统托盘区的Docker图标应为绿色运行状态。

3.3 获取 Dify 的 Docker Compose 文件

Dify官方在GitHub仓库提供了标准的Docker Compose部署文件。我们不需要克隆整个源码，只需获取这个核心配置文件。

在你的电脑上选择一个合适的目录作为工作目录，例如D:\Projects\Dify。
在该目录下，创建一个新文件，命名为docker-compose.yml。
打开 Dify官方GitHub仓库，找到docker目录下的docker-compose.yml文件。你可以直接通过Raw链接查看内容。为了本文的完整性和可复现性，下面提供一个基于最新稳定版的、适用于Windows的典型配置示例。请注意，版本可能更新，请以官方最新文件为准，此处示例用于说明。

将以下内容复制到你刚创建的docker-compose.yml文件中：

version: '3.8' services: postgres: image: postgres:16-alpine environment: POSTGRES_DB: dify POSTGRES_USER: postgres POSTGRES_PASSWORD: dify2024 volumes: - postgres_data:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"] interval: 10s timeout: 5s retries: 5 restart: unless-stopped redis: image: redis:7-alpine command: redis-server --requirepass dify2024 volumes: - redis_data:/data healthcheck: test: ["CMD", "redis-cli", "--raw", "incr", "ping"] interval: 10s timeout: 5s retries: 5 restart: unless-stopped weaviate: # 使用Weaviate作为向量数据库示例 image: semitechnologies/weaviate:1.24.6 command: - --host - 0.0.0.0 - --port - '8080' - --scheme - http environment: QUERY_DEFAULTS_LIMIT: 25 AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED: 'true' PERSISTENCE_DATA_PATH: '/var/lib/weaviate' DEFAULT_VECTORIZER_MODULE: 'none' ENABLE_MODULES: '' CLUSTER_HOSTNAME: 'node1' volumes: - weaviate_data:/var/lib/weaviate ports: - "8081:8080" restart: unless-stopped api: image: langgenius/dify-api:latest environment: # 数据库配置 DB_HOST: postgres DB_PORT: 5432 DB_USER: postgres DB_PASSWORD: dify2024 DB_DATABASE: dify # Redis配置 REDIS_HOST: redis REDIS_PORT: 6379 REDIS_PASSWORD: dify2024 # 向量数据库配置 (以Weaviate为例) VECTOR_STORE: weaviate WEAVIATE_ENDPOINT: http://weaviate:8080 WEAVIATE_API_KEY: "" # 其他关键配置 CONSOLE_API_URL: http://localhost:5001 CONSOLE_WEB_URL: http://localhost:3000 SECRET_KEY: your-secret-key-please-change-it # 务必修改！ # 文件存储配置 (本地存储示例) STORAGE_TYPE: local STORAGE_LOCAL_PATH: /app/storage volumes: - storage_data:/app/storage - ./logs/api:/app/logs depends_on: postgres: condition: service_healthy redis: condition: service_healthy weaviate: condition: service_started ports: - "5001:5001" restart: unless-stopped worker: image: langgenius/dify-api:latest command: /bin/bash ./entrypoint/start_worker.sh environment: # 环境变量与api服务基本一致 DB_HOST: postgres DB_PORT: 5432 DB_USER: postgres DB_PASSWORD: dify2024 DB_DATABASE: dify REDIS_HOST: redis REDIS_PORT: 6379 REDIS_PASSWORD: dify2024 VECTOR_STORE: weaviate WEAVIATE_ENDPOINT: http://weaviate:8080 WEAVIATE_API_KEY: "" CONSOLE_API_URL: http://api:5001 SECRET_KEY: your-secret-key-please-change-it # 务必与api服务一致！ STORAGE_TYPE: local STORAGE_LOCAL_PATH: /app/storage volumes: - storage_data:/app/storage - ./logs/worker:/app/logs depends_on: postgres: condition: service_healthy redis: condition: service_healthy weaviate: condition: service_started api: condition: service_started restart: unless-stopped web: image: langgenius/dify-web:latest environment: # 指向后端API地址 CONSOLE_API_URL: http://localhost:5001 APP_API_URL: http://localhost:5001 # 启用公开注册（仅用于测试，生产环境应关闭） ENABLE_WEB_SIGNUP: 'true' depends_on: - api ports: - "3000:3000" restart: unless-stopped volumes: postgres_data: redis_data: weaviate_data: storage_data:

重要说明：

这个配置文件定义了我们之前提到的所有核心服务。
我们使用了weaviate作为向量数据库示例。你也可以根据需要替换为qdrant或milvus，但需要修改相应的服务和配置。
SECRET_KEY：这是一个至关重要的安全配置，用于加密会话等。你必须将其your-secret-key-please-change-it替换为一个自己生成的、足够复杂的随机字符串。在生产环境中，建议通过环境变量文件（.env）管理此类敏感信息。
端口映射：api服务映射到主机的5001端口，web服务映射到3000端口，weaviate映射到8081端口。请确保这些端口在主机上未被占用。
数据持久化：我们使用了Docker的volumes（postgres_data,redis_data等）来持久化数据库和存储的数据。即使容器被删除，数据也不会丢失，它们存储在Docker管理的卷中。

4. 核心流程拆解：启动与配置Dify

有了配置文件，启动Dify容器集群就变得非常简单。但在此之前，我们需要对一些关键配置和Windows特有的注意事项进行拆解。

4.1 配置文件关键点解析与调整

打开你创建的docker-compose.yml文件，我们逐一分析需要关注或可能调整的地方：

镜像版本：image: langgenius/dify-api:latest。使用latest标签会拉取最新的镜像，这可能包含不稳定的变更。对于生产环境，强烈建议指定一个稳定的版本标签，例如langgenius/dify-api:0.9.0。你可以在Dify的 Docker Hub页面查看可用版本。
数据库密码：POSTGRES_PASSWORD和DB_PASSWORD。示例中使用了简单的dify2024，在生产环境中必须修改为强密码。
文件存储路径：STORAGE_LOCAL_PATH: /app/storage和volumes映射。示例中将容器内的/app/storage路径挂载到了一个名为storage_data的Docker卷。这意味着上传的文件（如知识库文档、应用头像等）会保存在Docker管理的卷中，而不是Windows主机的一个具体文件夹。如果你希望文件存储在主机特定目录（例如D:\DifyStorage），可以将配置改为：
```
volumes: - D:\DifyStorage:/app/storage
```
注意：Windows路径直接映射到Linux容器可能存在权限问题。使用Docker Desktop的WSL 2后端时，更推荐将文件存储在WSL 2子系统内的路径（如/mnt/d/DifyStorage），或者直接使用Docker卷（如示例所示），这是最省事且性能较好的方式。
日志路径：./logs/api:/app/logs。这会将容器内的日志文件映射到主机当前目录下的logs文件夹中，方便查看和调试。

4.2 启动Dify服务

所有配置检查无误后，就可以启动服务了。

打开Windows Terminal、PowerShell或CMD，导航到你存放docker-compose.yml文件的目录（例如D:\Projects\Dify）。
```
cd D:\Projects\Dify
```
执行以下命令启动所有服务：
```
docker-compose up -d
```
- up：创建并启动容器。
- -d：在后台运行（“detached”模式）。

此时，Docker会开始从Docker Hub拉取所需的镜像（PostgreSQL, Redis, Weaviate, Dify API, Dify Web），这个过程取决于你的网速，可能需要几分钟到十几分钟。拉取完成后，会自动创建并启动所有容器。

4.3 查看服务状态与日志

启动命令完成后，并不意味着所有服务都已就绪。数据库初始化、应用启动都需要时间。

查看容器运行状态：
```
docker-compose ps
```
这个命令会列出所有由当前docker-compose.yml管理的容器，并显示它们的状态（Up、Exit）、端口映射等信息。等待所有服务的状态都变为Up。
查看实时日志（用于调试）：
```
# 查看所有服务的日志 docker-compose logs -f # 查看特定服务（如api）的日志 docker-compose logs -f api
```
-f参数表示“follow”，即持续输出日志。当你遇到启动问题时，这是最重要的排查手段。重点关注api和worker服务的日志，查看是否有连接数据库失败、配置错误等异常信息。
验证服务健康：你可以通过访问以下URL来初步验证服务是否正常：
- Dify Web前端：打开浏览器，访问http://localhost:3000。如果看到Dify的登录/注册界面，说明前端服务已启动。
- Dify API后端：访问http://localhost:5001或http://localhost:5001/health。如果返回JSON格式的健康状态信息，说明后端API服务正常。
- Weaviate向量数据库：访问http://localhost:8081/v1/.well-known/ready。如果返回{"status": "ready"}，说明向量数据库已就绪。

关键点：首次启动时，api服务会等待数据库（PostgreSQL）健康检查通过后，才执行数据库迁移（创建表结构等）。这个过程会在日志中体现。请耐心等待1-2分钟，直到日志中出现数据库迁移完成、服务启动成功的消息，再访问Web界面。

5. 完整示例：初始化访问与基础配置

假设你的服务已经全部成功启动，并且通过http://localhost:3000看到了Dify的界面。接下来，我们完成首次使用的初始化配置。

5.1 注册第一个管理员账户

在浏览器中打开http://localhost:3000。
你应该会看到一个欢迎页面，点击“注册”或“Sign Up”。
输入你的邮箱、用户名和密码，完成注册。第一个注册的用户会自动成为系统管理员。
使用刚注册的账号登录。

5.2 配置模型供应商（以OpenAI为例）

Dify本身不提供大模型，它需要连接外部的模型API。登录后，首要任务就是配置模型供应商。

进入后台管理界面。通常可以在左下角用户头像处找到“系统设置”或“管理员”入口。
找到“模型供应商”或“Model Providers”配置页面。
点击“添加模型供应商”或“Add Provider”，选择“OpenAI”。
填写配置信息：
- 供应商名称：自定义，如“My-OpenAI”。
- API Key：填入你的OpenAI API Key。你需要在 OpenAI平台创建并获取。
- API Base URL：如果你使用官方接口，保持默认https://api.openai.com/v1即可。如果你使用第三方代理或Azure OpenAI，则需要修改。
点击“保存”。保存成功后，可以点击“校验”测试连接是否正常。

5.3 配置模型

添加了供应商后，还需要配置具体的模型。

在“模型配置”或“Model Configuration”页面，点击“添加模型”。
选择刚才添加的供应商（如“My-OpenAI”）。
在模型列表中，选择你需要的模型，例如gpt-4o、gpt-4-turbo-preview、gpt-3.5-turbo等。
填写模型名称（通常与API模型标识一致），并设置配额限制（可选）。
保存配置。

至此，你的Dify平台已经具备了调用大模型的能力。你可以开始创建你的第一个AI应用了。

5.4 创建第一个应用（提示词编排）

让我们快速创建一个简单的提示词应用，验证整个流程。

在Dify主界面，点击“创建新应用”。
选择“提示词编排”模式。
为应用起个名字，例如“智能翻译助手”。

进入应用开发界面后，在“提示词”区域输入：

你是一个专业的翻译助手。请将用户输入的任何语言翻译成中文。 用户输入：{{input}}

在右侧的“预览与调试”区域，输入一句英文，例如 “Hello, how are you today?”，点击“运行”。
如果配置正确，你应该会看到模型返回的中文翻译结果。

这个简单的流程验证了从Dify前端 -> Dify后端API -> 外部模型API -> 返回结果的完整链路是通的。

6. 运行结果与效果验证

部署并初步配置后，我们需要系统地验证部署是否完全成功，各组件是否协同工作正常。以下是一份验证清单：

6.1 基础服务连通性验证

通过Docker命令和浏览器访问，确认所有容器服务均正常运行。

# 1. 确认所有容器状态为 Up docker-compose ps # 预期输出应显示所有服务（postgres, redis, weaviate, api, worker, web）的状态均为 “Up” # 2. 检查各服务内部健康端点（需在容器内执行，或通过映射端口访问） # 我们通过curl命令模拟（确保已安装curl，或者使用浏览器访问） # 验证API健康 curl http://localhost:5001/health # 预期输出包含 {"status": "healthy"} 或类似信息 # 验证Weaviate健康 curl http://localhost:8081/v1/.well-known/ready # 预期输出 {"status": "ready"}

6.2 核心功能验证

在Dify Web界面中，进行以下操作测试：

知识库功能：
- 进入“知识库”模块，点击“创建知识库”。
- 上传一个文本文件（如.txt或.md文件）或PDF文件。
- 观察“索引状态”。成功的话，会经历“解析中”、“索引中”最终变为“可用”。这验证了worker服务、向量数据库（Weaviate）和文件存储的协同工作能力。
- 在知识库中进行一次“搜索测试”，看是否能返回相关片段。
工作流功能：
- 创建一个新的“工作流”应用。
- 从左侧拖拽一个“LLM”节点到画布。
- 配置该节点，选择你之前配置好的模型（如gpt-3.5-turbo）。
- 添加一个“开始”节点和一个“回答”节点，并将其连接起来。
- 点击“运行”。如果工作流能成功执行并返回LLM的结果，则证明api、worker、模型供应商的整个异步任务流程是通的。
用户与团队管理（管理员）：
- 在系统设置中，尝试邀请一个新用户（需要提供邮箱）。
- 如果邮件功能未配置，邀请会失败，但这可以验证用户管理模块的基础功能是否正常。

6.3 数据持久化验证

这是确保数据安全的关键测试。

停止所有服务：
```
docker-compose down
```
再次启动服务：
```
docker-compose up -d
```
验证数据：重新登录http://localhost:3000。
- 检查之前创建的应用是否还在。
- 检查知识库是否还在，状态是否正常。
- 用之前的账号是否能登录。

如果所有数据都在，说明Docker卷（postgres_data,redis_data,storage_data等）的持久化配置是正确的，数据在容器重启后得以保留。

7. 常见问题与排查思路

在Windows上使用Docker部署Dify，你可能会遇到一些典型问题。下表汇总了常见现象、原因及解决方案：

问题现象	可能原因	排查方式	解决方案
执行`docker-compose up`时报错，提示端口被占用。	主机（Windows）的3000、5001、8081等端口已被其他程序（如本地开发服务器）占用。	在PowerShell中运行`netstat -ano \| findstr :<端口号>`查找占用进程。	1. 停止占用端口的进程。 2. 修改`docker-compose.yml`中的端口映射，如将`"3000:3000"`改为`"3001:3000"`。
访问`localhost:3000`无法连接，但容器状态显示`Up`。	1. 容器启动慢，服务尚未完全初始化。 2. Windows防火墙阻止了连接。 3. Docker Desktop网络配置问题。	1. 查看容器日志`docker-compose logs web`。 2. 检查防火墙设置。 3. 尝试在容器内执行命令`docker-compose exec web curl localhost:3000`。	1. 等待1-2分钟再试。 2. 暂时关闭防火墙或添加入站规则。 3. 重启Docker Desktop。
`api`或`worker`服务日志报错，提示连接不上`postgres`或`redis`。	1. 数据库服务未完全启动。 2. 网络配置错误，容器间无法通过服务名通信。 3. 密码错误。	1. 运行`docker-compose logs postgres`查看数据库启动日志。 2. 在`api`容器内执行`ping postgres`。 3. 检查`docker-compose.yml`中的环境变量密码是否一致。	1. 确保`depends_on`中设置了`condition: service_healthy`。 2. Docker Compose默认创建的网络是互通的，通常无需额外配置。 3. 核对并统一所有服务的密码环境变量。
知识库文档上传后，一直处于“索引中”或失败。	1.`worker`服务未正常运行。 2. 向量数据库（如Weaviate）连接失败或配置错误。 3. 文件存储路径权限问题。	1. 检查`worker`容器日志`docker-compose logs worker -f`。 2. 检查`weaviate`容器日志和健康状态。 3. 检查`api`/`worker`容器内`/app/storage`目录的写入权限。	1. 重启`worker`服务`docker-compose restart worker`。 2. 确认`WEAVIATE_ENDPOINT`配置正确（使用服务名`weaviate`）。 3. 确保使用的Docker卷或挂载目录有写入权限。
应用调用模型时超时或报“模型不可用”。	1. 模型供应商配置的API Key错误或余额不足。 2. 网络问题，无法访问外部模型API（如OpenAI）。 3. Dify后端到模型API的代理配置问题。	1. 在Dify控制台“模型供应商”页面点击“校验”。 2. 在`api`容器内执行`curl https://api.openai.com`测试网络。 3. 查看`api`服务日志中关于模型调用的详细错误。	1. 检查并更正API Key，确认账户有额度。 2. 如果身处特殊网络环境，可能需要为Docker容器配置网络代理。 3. 检查`docker-compose.yml`中是否配置了`http_proxy`等环境变量。
Docker Desktop 启动失败，提示WSL 2或Hyper-V相关问题。	1. BIOS中未开启虚拟化（VT-x/AMD-V）。 2. Windows功能“Hyper-V”或“Windows Subsystem for Linux”未启用。 3. WSL 2内核未更新。	1. 进入BIOS设置，开启虚拟化技术。 2. 在“启用或关闭Windows功能”中勾选相关功能并重启。 3. 根据错误提示，更新WSL 2内核。	1. 开启BIOS虚拟化。 2. 启用所需Windows功能并重启电脑。 3. 从微软官网下载并安装最新版WSL 2内核。
容器运行一段时间后，磁盘空间占用巨大。	Docker的镜像、容器和卷缓存不断累积。	运行`docker system df`查看Docker磁盘使用详情。	定期清理： `docker system prune -a`(谨慎，会删除所有未使用的镜像、容器、网络和卷) `docker volume prune`(仅删除未使用的卷)

8. 最佳实践与工程建议

将Dify成功部署到本地只是第一步。为了让它成为一个稳定、高效、安全的开发或测试环境，你需要遵循一些最佳实践。

8.1 配置管理：使用`.env`文件分离敏感信息

永远不要将密码、API密钥等敏感信息硬编码在docker-compose.yml中。应该使用环境变量文件。

在docker-compose.yml同目录下，创建一个名为.env的文件。

在其中定义你的变量：

# .env 文件 POSTGRES_PASSWORD=YourStrongPassword123! REDIS_PASSWORD=AnotherStrongPassword456! SECRET_KEY=YourVeryLongAndRandomSecretKeyHere OPENAI_API_KEY=sk-your-actual-openai-api-key

修改docker-compose.yml，引用这些变量：

# 在postgres服务中 environment: POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} # 在api服务中 environment: SECRET_KEY: ${SECRET_KEY} OPENAI_API_KEY: ${OPENAI_API_KEY} # 需要先在api服务环境变量中添加此配置

重要：将.env文件添加到.gitignore中，避免将其提交到版本控制系统。

8.2 数据备份与恢复

你的应用数据、知识库文档都存储在PostgreSQL和文件卷中。定期备份至关重要。

备份PostgreSQL数据库：

# 执行备份，将数据库导出为sql文件 docker-compose exec postgres pg_dump -U postgres dify > dify_backup_$(date +%Y%m%d).sql

备份Docker卷：Docker卷通常位于\\wsl$\docker-desktop-data\version-pack-data\community\docker\volumes\（WSL 2后端）或Windows的Docker数据目录下。更稳妥的方式是使用docker run命令挂载卷进行备份。
```
# 备份名为‘dify_storage_data’的卷 docker run --rm -v dify_storage_data:/source -v $(pwd):/backup alpine tar czf /backup/storage_backup.tar.gz -C /source .
```
恢复：恢复则是反向操作，将sql文件导入数据库，或将tar.gz解压到卷中。

8.3 性能优化

资源限制：默认情况下，容器可以使用宿主机的所有资源。对于长期运行的服务，建议在docker-compose.yml中为内存密集型服务（如weaviate,api）设置资源限制，防止单个容器耗尽系统资源。
```
services: weaviate: # ... 其他配置 deploy: resources: limits: memory: 4G cpus: '2.0'
```
使用更高效的向量数据库：Weaviate功能全面但相对较重。对于资源有限的本地环境，可以尝试更轻量的qdrant。只需在docker-compose.yml中替换weaviate服务，并修改api/worker中的VECTOR_STORE和连接配置即可。

8.4 安全加固

修改默认密码：务必修改所有服务的默认密码（PostgreSQL, Redis）。
使用非latest标签：在生产环境中，为所有镜像指定具体的版本标签，避免自动升级导致的不兼容问题。
限制网络暴露：本例中我们将API（5001）和Web（3000）端口映射到了主机。如果仅在本地使用，可以考虑不映射端口，或者仅映射到127.0.0.1（ports: - "127.0.0.1:3000:3000"），避免外部访问。
定期更新：关注Dify官方GitHub的Release和Security公告，定期更新镜像版本以获取功能更新和安全补丁。