Dify 部署前先确认目标版本、服务器资源、Docker 环境、模型接口和备份方案。本篇给出安装前检查顺序及只读命令，依据官方资料整理，不作为部署成功或容量实测记录。
1. 先选定版本与使用方式
从 官方仓库 确认准备部署的发布版本，再阅读该版本文档和配置示例。不要直接把不断变化的主分支命令当作长期不变的操作指南。将目标版本和现有系统、数据库、代理配置记入部署记录。
2. 核对基础资源与 Compose
核对时官方 README 列出的最低资源为 2 核 CPU、4 GiB 内存，并要求 Docker Compose 至少 v2.24.0。这是文档最低要求，不是多人使用的容量承诺，也不含额外本地模型推理资源。实际部署时重新核对所选版本。
在已有 Linux 测试环境中，可以先运行下面的只读检查。命令不存在时，应按系统与 Docker 官方说明安装对应组件；不要在已有生产环境盲目升级。
uname -m
free -h
df -h
docker version
docker compose version检查 CPU 架构是否被所需镜像支持、可用内存与磁盘是否充足、Docker 客户端能否连接服务端，以及 Compose 的实际版本。命令没有报错不代表应用已经部署或通过验收。
3. 明确模型接口和资料路径
记录模型服务的接口地址、认证方式、预算与网络可达性。API 密钥只保存到受控配置或密钥管理系统，不放入文章、截图或 Git。需要使用本地模型时，另外评估 模型运行服务 的资源与访问控制。
区分对话模型、嵌入模型和可能使用的重排模型；还要确认文件解析、向量存储等组件的需求。先用不含敏感信息的样本，避免将业务资料直接拿来排查网络问题。
4. 设计对外访问与恢复
明确哪些端口仅内部访问，哪些入口需要对外提供，并提前规划 HTTPS、管理访问限制、日志与更新责任。不要把数据库、缓存或没有访问控制的模型接口直接开放到互联网。
部署前备份将要修改的系统与代理配置，记录数据目录、配置文件、数据库和文件存储位置。将备份放到独立位置，并准备如何恢复的步骤；创建快照不是恢复测试的替代品。
5. 写好安装后的验收任务
- 能否登录、创建应用并保存配置？
- 模型调用能否完成，失败时是否有可定位的日志？
- 样本资料能否导入、检索，并正确显示来源？
- 不同账号是否只能访问授权内容？
- 备份后是否能在隔离环境恢复必要数据？
准备清单完成后，才进入具体版本的安装步骤。本站后续的部署实测应独立记录版本、机器、实际命令与结果，不能仅凭本篇清单宣称完成。先阅读 服务器选型 和 项目与许可介绍。