企业官网建设流程全解析

上个月帮一位朋友搭 AI 应用演示环境，他模型接口早就申请好了，结果折腾了整整两天，愣是没让一个聊天机器人跑起来。不是不会调 API，而是卡在“应用怎么落地”这一步——前端要写、后端要接、会话要管、文档要切，全得自己搭。后来我直接把 Dify 搬出来，用 Docker 一键部署，半小时不到，一个能对话、能传文档、能跑知识库的 AI 应用就上线了。这篇就把整个流程拆开揉碎讲清楚，从 Docker 环境准备到 Dify 跑起来，再到发布第一个 AI 应用，五步走完，全程附命令、附截图说明、附我踩过的坑。

1. 为什么是 Dify + Docker：我的选型逻辑

先说结论：如果你要的不是“从零写一个大模型应用框架”，而是“快速把大模型能力变成可用的产品”，Dify 是当前少有的、把开发者和业务方需求同时照顾到的开源平台。我在选型之前也对比过几类方案，这里把当时的思考过程写出来，省得你再走一遍弯路。

1.1 Dify 到底解决了什么问题

Dify 本质上是一个 LLMOps 平台，也就是大模型应用的低代码开发与运营平台。它把大模型应用开发里最重复、最琐碎的部分——模型接入、Prompt 编排、上下文管理、RAG 知识库、会话记忆、应用发布——全都做成了可视化操作。你不需要自己写后端接口来管理对话状态，不需要自己拼向量数据库来做文件问答，更不需要从零开发一个管理后台。

我那位朋友之前卡住的点，正是 Dify 擅长的部分：他把 OpenAI 的 API 接通之后，发现要做成“用户能打开网页直接对话”的产品，还得考虑会话历史、流式输出、系统 Prompt、多轮上下文截断。这些如果自己写，没个一两周打磨不好。Dify 把这些能力全部内置，网页端、API 端、分享链接三种发布方式都是开箱即用的。

还有一个很现实的因素：团队协作。Dify 天然带多租户能力，在 1.x 版本里社区版也支持了多租户模式。也就是说，团队里不同角色可以在同一个实例上各玩各的，开发人员调工作流、运营人员配知识库、产品经理看日志，互不干扰。这一点在后面做企业级应用时非常重要。

1.2 为什么必须用 Docker 部署

Dify 的部署方式不止一种，官方文档里提供了 Docker Compose、本地源码运行、Kubernetes 等方案。但对于绝大多数场景——个人学习、团队内部使用、中小型产品 MVP 验证——Docker Compose 是唯一值得推荐的。原因很简单：Dify 不是单体应用，它由 api、worker、web、db、redis、sandbox、ssrf_proxy 等多个服务组成。如果不用容器编排，光是装依赖、配环境变量、启动顺序就够你喝一壶的。

我实测下来，全新的一台 Ubuntu 22.04 服务器，从安装 Docker 到 Dify 界面出现，大概 15 到 20 分钟。如果用源码方式跑，光装 Python 虚拟环境和 Node 依赖就不止这个时间。而且 Docker 方式最大的优势是“干净”——所有组件都打在容器里，升级时只需要拉新镜像重启即可，不会把宿主机环境搞得一团糟。

所以下面所有步骤，都围绕 Docker Compose 展开。这不是唯一方案，却是让我愿意反复推荐的方案。

2. 动手前的环境检查清单：真正省时间的准备

很多人部署失败，不是后面步骤操作错了，而是第一步环境没准备好。这里列一份我在多次部署中总结的检查清单，照着核对一遍，能避免大部分翻车。

2.1 硬件要求与操作系统建议

先说最低配置。官方的建议是 2 核 4G 内存，但实际上跑起来之后，Dify 全家桶要吃 2GB 左右的内存。如果你还要在同一个实例上做模型推理（比如部署本地嵌入模型 bge-m3），那 8G 内存才稳妥。磁盘方面，系统盘至少留 20G 剩余空间，Docker 镜像和容器日志都会占空间，太紧的话容易出现容器写了半截就退出的问题。

操作系统我踩过两个版本：Ubuntu 22.04 和 Debian 12，都跑得很顺。如果你手头是 CentOS 7，也不是不行，但要确认内核版本不低于 3.10，且 Docker 要装较新版本，否则有些 Compose 特性用不了。Windows 用户建议直接用 Docker Desktop，WSL2 后端；macOS 用户同样用 Docker Desktop。说实话，Windows 上部署 Dify 可行，但如果你有云服务器，我更推荐在 Linux 上跑，后面升级维护都省心。

2.2 安装 Docker 与 Docker Compose

如果你的机器还没装 Docker，这一步是必须做的。Ubuntu 22.04 上我通常会这样装：

# 移除可能存在的旧版本 sudo apt-get remove docker docker-engine docker.io containerd runc # 安装依赖 sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg lsb-release # 添加 Docker 官方 GPG 密钥 sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # 添加软件源 echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null # 安装 sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

装完之后，务必确认 Docker Compose 插件版本，Dify 的 compose 文件对版本有要求：

docker --version docker compose version

我当前环境是 Docker 27.x + Compose 2.x，跑 Dify 1.x 没问题。Compose 版本低于 2.0 的，建议先升级，否则后面执行docker compose up时会报语法不支持的错。

2.3 镜像拉取慢的解决方案

这一步几乎是国内服务器部署绕不开的坎。Dify 的镜像包含 postgres、redis、nginx、python、node 等基础镜像，以及 langgenius 自己的镜像，总下载量接近 2GB。如果你直接拉，大概率会卡在等待层数据的阶段，动辄半小时起步。

我的做法是在 Docker 的 daemon 配置里加上镜像加速地址。修改/etc/docker/daemon.json：

{ "registry-mirrors": [ "https://docker.m.daocloud.io", "https://dockerproxy.com", "https://mirror.baidubce.com" ] }

注意：加速地址不要只填一个，国内镜像源偶尔会失效，填两三个做兜底。修改后重启 Docker 服务再继续。

sudo systemctl daemon-reload sudo systemctl restart docker

配置好之后，拉镜像的速度从几 KB/s 到几 MB/s，完全两种体验。这一步如果不做，后面docker compose up会非常痛苦，不是命令错，就是网络慢到怀疑人生。

3. 五步部署实操：从空服务器到 Dify 界面

环境就绪后，真正干活的时间到了。我把整个过程压缩成五个大步骤，每一步都是可以直接复制执行的。全程不需要写一行业务代码，只需要敲命令和点鼠标。

3.1 获取 Dify 源码与 Docker Compose 编排文件

Dify 的部署不是直接写一份 compose 文件，而是官方仓库里已经准备好了完整的编排文件和环境变量模板。你要做的第一件事，就是把仓库拉下来：

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

这里有个小建议：不要直接 clone 主分支的最新代码，而是去 Release 页面看当前正式版的版本号，然后 checkout 到对应 tag。我一般这样做：

cd dify # 查看当前 release 版本，假设是 1.10.0 git checkout 1.10.0

为什么建议用 release tag？因为主分支可能包含一些未完全测试的新特性，部署上去之后如果遇到问题，社区里不一定有对应的解决方案。而 release 版本经过了完整测试，坑基本都被踩平了。我早期图新鲜用过一次主分支，结果某个中间版本里 worker 容器一直重启，查了半天才发现是已知 bug，切回正式版就好了。

进入部署目录：

cd dify/docker cp .env.example .env

.env文件是 Dify 所有环境变量的总开关，里面有端口配置、数据库配置、密钥配置、模型供应商默认开关等。

3.2 环境变量的必要检查

打开.env文件后，有几个关键项我强烈建议现在就检查，而不是等容器启动后再回头改：

• EXPOSE_NGINX_PORT：默认 80。如果你服务器上已经有 Nginx 或其他服务占用 80 端口，这里改成 8080 或任意空闲端口。这个改动只在.env里改就行，compose 文件会自动读取。
• SECRET_KEY：默认是dify-ai，这是用来加密会话数据的密钥。生产环境务必改成随机字符串，比如用openssl rand -base64 42生成一个。
• POSTGRES_PASSWORD、REDIS_PASSWORD：安全起见也建议改成强密码。如果你只是本地学习，不改问题不大；如果是公网部署，不改等于把数据库裸奔在外面。

另外，如果你计划跑本地嵌入模型（比如 bge-m3）来构建知识库，需要在.env里检查一条SANDBOX_API_KEY之类的配置是否存在。Dify 1.x 版本对沙箱有内置的随机密钥逻辑，默认值一般够用，但升级时注意看迁移文档。

检查完毕后，保存文件，接下来就是见证奇迹的时刻。

3.3 启动所有服务：docker compose up 的完整姿势

启动命令非常简单，但这简单背后有一个顺序问题。Dify 的依赖关系是：数据库和 Redis 先起来 → api 和 worker 起来 → web 前端起来 → nginx 做入口反向代理。不过 Docker Compose 会根据depends_on自动处理启动顺序，你不需要手动分步启动。

在dify/docker目录下执行：

docker compose up -d

-d表示后台运行。第一次执行时，会开始拉取所有镜像，这个阶段我想再强调一句：如果前面配置了镜像加速，这里会顺很多。

拉取完成后，观察容器启动状态：

docker compose ps

正常情况下，你会看到大约 9 到 10 个容器，分别是：

如果你的版本里有 weaviate 或 qdrant 容器，这是正常的，知识库功能会用到向量数据库。看到所有容器都是 healthy 之后，部署就完成了 90%。

3.4 初始化管理员账号：进入系统的第一道门

容器健康不代表你立刻能登录。首次访问 Dify 时，系统会要求你配置管理员账号。在浏览器里访问：

http://你的服务器IP:端口/install

如果你改过EXPOSE_NGINX_PORT，不要忘了带上端口号。页面上会要求设置管理员邮箱和密码。我一般会设置一个专门的邮箱来接收系统通知，密码用足够强度的组合。这一步没有任何难度，但有一点要注意：这个页面只在首次安装时出现，如果你跳过了，系统不会自动弹出来，那就得去数据库里手动初始化，非常麻烦。所以遇到/install页面，一次填完，别关。

设置完管理员账号，Dify 会跳到登录页。用刚创建的账号密码登录，你就正式进入了 Dify 的工作台。

3.5 登录后的三个必要设置

登录之后，先别急着创建应用，我强烈建议你按下面三步把基础设置做完，否则后续用起来会别扭：

• 检查模型供应商页签：在右上角头像进入“设置”，找到“模型供应商”。这里能看到支持的各类模型列表。你要用的模型（比如 OpenAI 的 gpt-4o、Anthropic 的 claude、国内的智谱 GLM、阿里通义等）都需要在这里填 API Key。填完之后，Dify 会自动验证 Key 是否可用。
• 添加模型即可：有些模型供应商需要单独在“模型类型”里选择对话、文本生成、Embedding 等类别。Embedding 模型格外重要，做知识库时要用，建议提前把 bge-m3 或 text-embedding-3-small 之类的模型配上。
• 设置工作空间信息：工作空间名称会展示在应用管理的界面上，改成你自己项目的名字，后面多项目时就不会搞混。

到这里，Dify 平台本身已经跑通。剩下的问题只有一个：怎么让一个 AI 应用上线？我下面用最小化的路径演示一遍。

4. 五步上线的核心：创建并发布一个可对话的 AI 应用

部署好 Dify 只是平台就绪，真正让业务方看见价值的是“应用”本身。这里我不讲复杂的工作流编排，而是用最简单的“聊天助手”类型，走完从创建到发布的完整流程，让你先有一个跑得通的闭环，再谈进阶。

4.1 选择合适的应用类型

在 Dify 工作台首页，点击“创建应用”，你会看到几种类型：聊天助手、Agent、文本生成、工作流等。第一个应用我建议创建“聊天助手”，因为它的交互方式最直观，而且能直接看到模型对话效果。

创建对话框里会让你填应用名称和描述，这些会展示在最终用户面前。名称我用过“内部知识助手”这种业务向的名字，也用过“测试机器人”这种开发向的名字，看你自己场景。创建完成后，进入的是应用编排页面。

4.2 编排页面的关键配置：模型、Prompt、对话开场白

编排页面是 Dify 的核心工作区，左侧是应用的基本信息，中间是系统 Prompt 编辑区和模型选择，右侧是调试预览区。

模型选择放在右上角。点击选择模型，会列出你在设置里配好的模型列表。第一个应用我建议直接选一个能力强的模型，比如 gpt-4o 或 claude-3.5-sonnet，因为你要先验证链路是否通，而不是优化成本。

系统 Prompt 是给模型的总纲。我在这里踩过一个小坑：最开始什么都不填，直接调试，模型也能回复，但语气和风格完全是随机的。建议至少写清楚角色、目标、限制三件事，比如：

你是一个智能客服助手，负责回答用户关于产品使用的问题。 回答要简洁直接，如果不知道答案，就如实说不知道，不要编造。

填完 Prompt 后，右侧会出现调试对话框，可以直接发消息测试。这一步能立刻看到模型是否正常响应，也能调整 Prompt 的效果。别忘了左下角有个“对话开场白”设置，这是用户点开聊天气泡时看到的第一句话，类似于“你好，我是XX助手，有什么可以帮你？”。做完这个设置，客服体验会专业很多。

4.3 发布应用：三种方式任选

调试满意后，点击右上角的“发布”按钮。Dify 会弹出一个发布方式选择，通常有“发布为 Web App”和“访问 API”两种。这两个都是生产方式，不是测试方式。

对于第一个应用，我建议选择“发布为 Web App”。发布完成后，你会得到一个链接，把链接发给任何人，对方不需要登录 Dify，就能直接打开网页和你的 AI 应用对话。这一点在演示场景中非常加分——我那位朋友最后就是用这个链接给领导演示的，整个过程只花了一个晚上。

4.4 从 Web App 到 API 集成

如果你的应用最终要嵌入到现有产品里，Dify 的 API 能力才是重点。在“访问 API”页面，你可以创建 API 密钥，然后通过标准的 REST API 调用应用。官网给了 Python、curl 等示例，核心逻辑是：

curl -X POST 'http://你的服务器IP/端口/v1/chat-messages' \ -H 'Authorization: Bearer app-你的API密钥' \ -H 'Content-Type: application/json' \ -d '{ "inputs": {}, "query": "你好", "user": "test-user", "response_mode": "blocking" }'

返回的 JSON 里，answer字段就是模型生成的回复。这种方式适合把 AI 能力嵌入到已有的业务系统里，公司内部工具、客服工作台、后台管理界面都可以这样接通。

我这里多提醒一句：API 密钥是敏感信息，只放到后端代码里，前端页面不要暴露。我在一些开源项目里见过把app-开头的密钥直接写在前端 JS 里的，别人拿到密钥就能无限调用你的 AI 应用，账单会非常难看。

5. 实测中踩过的坑与高频问题排查

跑通是一回事，跑得稳是另一回事。下面这些问题是过去几个月里反复出现在社区和我个人部署经历里的高频问题，我把排查链路写出来，遇到问题时照着走会快很多。

5.1 多个容器状态异常：定位根因的通用套路

第一次启动后，不是所有人都会一次全绿。常见情况是docker compose ps看到某个容器状态为 restating 或 unhealthy。这时候不要慌，也不要挨个容器重启，正确做法是先看日志：

docker compose logs api # 看后端 API 日志 docker compose logs worker # 看任务队列日志

日志会明确告诉你失败原因。我遇到最多的几个原因：

• 数据库还没准备好，api 容器就尝试连接导致启动失败。处理方式是等几秒再docker compose restart api，或者直接把启动命令里的健康检查依赖调严格一点。
• .env里的SECRET_KEY格式不对，导致加解密报错。检查是否包含特殊字符导致解析异常。
• 镜像版本不一致，比如 compose 文件里的版本号被改成不存在的 tag。这种情况把镜像 tag 恢复到官方默认即可。

日志排查法适用于绝大多数容器异常，实在没头绪就去 Dify 官方 GitHub Issues 里搜报错关键词，基本都能找到答案。

5.2 80 端口被占用导致 Web 无法访问

如果你服务器上已经装了 Nginx 或宝塔面板，80 端口冲突是大概率事件。症状是容器都 healthy，但浏览器访问 IP 就是打不开页面。这时候不要先怀疑 Dify，先看本机端口监听：

sudo netstat -tlnp | grep :80

如果是其他服务占用，最简单的方案是把EXPOSE_NGINX_PORT改成 8080，然后重新执行：

docker compose up -d

修改.env后，光重启容器不够，因为 nginx 容器启动时读取的是当时的环境变量。你需要先停掉再启动：

docker compose down docker compose up -d

5.3 升级后知识库报 Internal Server Error

这个坑在 Dify 社区里出现频率很高，尤其是在线升级版本之后。我自己的经历是：1.6 升到 1.10 时，知识库里旧的文档索引和新的向量数据库逻辑对不上，导致打开知识库页面或修改文档时直接 500。

排查方式是先看 api 容器日志，基本会看到和数据库 migration 相关的错误。处理方案通常是把数据库迁移补跑一遍：

docker compose exec api flask db upgrade

注意：不同版本的迁移命令可能不同，升级前务必看官方 Release Notes 里的升级指南。如果已经报错，先备份dify/docker目录下的.env和volumes文件夹，再尝试迁移命令。实在不行，回滚到旧版本镜像也是一种保命手段。

5.4 镜像加速失效后的应急方案

即使配置了镜像加速，也可能遇到某些特定镜像拉取特别慢的问题。我遇到过langgenius/dify-api这个镜像因为体积大偶尔拉取超时的情况。应急方案有两个：一是重新执行docker compose pull，多试几次一般能续上；二是找到该镜像的具体名称和 tag，单独执行docker pull，成功后 compose 会自动使用本地缓存镜像。不要反复docker compose up -d，中间中断会留下很多悬空层，反而拖慢后续操作。

5.5 离线环境的插件与模型部署

如果你的部署环境是内网隔离的，无法访问外网拉取模型和插件，那就要提前做好离线准备。Dify 1.x 支持离线安装插件，你需要先在一台联网机器上把插件打包下载，再拷贝到内网机器上通过命令导入。这个过程比较繁琐，但可行。我建议这类用户优先在测试环境把整个镜像目录docker save导出来，再在目标机器docker load导入，比逐层解决网络问题省事得多。

6. 从“跑通”到“好用”：部署完成后的扩展方向

应用上线不是终点，甚至只是开始。Dify 真正厉害的地方在于，跑通基础链路之后，你可以像搭积木一样给它加能力。最后这部分讲讲我最常推荐的三个扩展方向。

6.1 接入知识库，做 RAG 问答

第一个应用只是一个裸模型，只能靠训练数据回答问题。如果你的业务需要基于内部文档问答，那就得给应用接上“外挂知识库”。在 Dify 里，这个过程不需要写向量数据库代码，只需要在“知识库”模块上传文档（PDF、Markdown、TXT 等），Dify 会自动完成切片、向量化、索引。然后回到应用编排页面，在“上下文”里关联这个知识库，模型就会优先从文档中找答案。

如果做知识库，本地部署嵌入模型（比如 bge-m3）会很有必要，这样可以避免把文档内容发到外部模型 API，数据安全上更可控。部署 bge-m3 到本地后，在模型供应商里配置为 Embedding 模型，创建知识库时选择它即可。

6.2 用工作流编排复杂业务逻辑

如果单纯对话无法满足你的场景，Dify 的工作流是你下一个要玩的东西。工作流可以把大模型能力、逻辑判断、HTTP 请求、代码执行等节点串联起来，实现类似“用户输入订单号 → 查询数据库 → 调用大模型总结 → 返回结果”这样的复杂流程。这个能力对团队内部工具非常有用，相当于把 AI 应用从“聊天”升级到了“自动化处理”。

我第一次用工作流做的是一个组内日报自动生成器：从项目管理工具拉数据，丢给大模型总结，最后通过 Webhook 发到群机器人。整个流程在 Dify 界面里拖拽完成，没写一行代码。

6.3 多租户与团队协作

Dify 1.10 开始，社区版的多租户能力进一步完善。在团队场景下，管理员可以创建多个成员账号，不同成员可以在同一个实例上各自管理自己的应用和知识库，互相看不到对方的数据，但共享同一个模型配置。这对希望控制成本、集中管理模型 API Key 的团队来说非常友好。

我现在的用法是：个人一套 Dify 实例做实验，公司一套独立实例做正式业务。正式业务里给开发、产品、运营分别建账号，开发调工作流，产品配知识库，运营看数据，各司其职。版本升级前先在个人实例验证，没问题再动正式环境，这个习惯帮我避开了好几次升级导致的故障。

6.4 最后分享一个小技巧

关于日常维护，我强烈建议你养成定期备份的习惯。Dify 的数据在 PostgreSQL 里，你不需要备份整个服务器，只需要备份数据库和.env文件：

docker compose exec db pg_dump -U postgres -d dify > dify_backup_$(date +%Y%m%d).sql

备份的 SQL 文件拉回本地存好，真出问题时，在新机器上部署好 Dify 后用同样的命令恢复，几分钟就能满血复活。这个习惯救过我不止一次，重要的事情值得再次强调。