企业希望在内部网络搭建一套可私有化、可管控的AI应用开发环境时，Dify.ai是非常合适的开源选择。它提供了工作流编排、知识库、模型接入和API开放能力，通过本地部署可以避免数据外发，并对接公司已有的大模型或推理服务。下面介绍从零开始部署Dify.ai并使其达到企业可用状态的完整流程。
环境准备与基础依赖
在开始部署之前，需要确认服务器满足基本资源要求。Dify.ai的默认编排方式基于Docker Compose，因此服务器必须安装Docker与Docker Compose插件。一般建议准备至少4核CPU、8GB内存和50GB可用磁盘的机器，如果是生产环境，最好使用独立数据库与对象存储，而不是全部跑在单机容器中。
操作系统层面推荐使用Ubuntu 22.04或CentOS 8以上版本，同时需要开放后续服务使用的端口，例如80、443以及内部通信端口。如果企业有安全组或防火墙策略，应提前将对应网段放行。另外，由于Dify依赖向量数据库来存储知识库嵌入，推荐提前决定使用Weaviate还是Qdrant，二者在资源占用和查询性能上略有差异，但Compose默认集成的是Weaviate，部署最简单。
还需要准备一个域名用于访问平台，以及可用的SMTP邮箱用于发送邀请和重置密码邮件。若公司内网没有外网邮箱，可以部署本地邮件服务或暂时关闭邮件依赖，用管理员直接创建账号的方式绕过。环境检查完毕后，就可以拉取源码并调整配置文件。
获取源码与配置环境变量
Dify官方将部署所需文件放在GitHub仓库的docker目录下，其中包含docker-compose.yaml与.env.example。我们需要将仓库克隆到本地，并复制环境变量模板为.env进行编辑。这一步决定了平台能否正确连接数据库、Redis以及外部模型服务。
在.env文件中，有几个关键项必须修改。首先是SECRET_KEY，应使用随机字符串生成，避免被猜测；其次是DB_PASSWORD和REDIS_PASSWORD，不要使用默认值。若企业已有PostgreSQL实例，可以把DB_HOST指向内网地址，并注释掉Compose里自带的数据库服务。模型配置方面，OPENAI_API_KEY可留空，转而通过界面添加自建推理端点，这样更符合私有化要求。
下面是一个最小化的环境变量示例，展示了如何关闭外部模型依赖并指定内网向量库：
# 生成随机密钥 SECRET_KEY=3f9a1c7b2e5846d0a1f2c3b4d5e6f708 # 使用自带数据库 DB_USERNAME=postgres DB_PASSWORD=InnerPwd_2024 DB_HOST=postgres DB_PORT=5432 # 关闭公网OpenAI OPENAI_API_KEY= MODEL_PROVIDER=openai # 向量库 VECTOR_STORE=weaviate WEAVIATE_ENDPOINT=http://weaviate:8080
配置完成后，执行docker compose up -d即可启动全部服务。第一次启动会拉取多个镜像，若公司网络无法访问Docker Hub，需要提前在可联网机器上导出镜像并导入内网。启动后用docker compose ps检查各容器状态，确保api、web、worker均处于healthy。
初始化平台与多租户隔离
服务起来后，通过浏览器访问服务器IP或域名，会进入Dify的初始化页面。第一步是创建管理员账号，该账号拥有租户管理权限。在企业场景中，建议管理员不直接开发应用，而是建立多个团队工作区，将不同部门成员邀请进对应工作区，实现数据与应用的隔离。
Dify本身以租户（tenant）为隔离单位，不同租户的知识库、API密钥和应用互不干扰。在后台，可以通过环境变量EDITION区分社区版与商业版能力，社区版已能满足多数编排需求。如果希望限制某一租户调用的模型种类，可在模型供应商设置中仅对该租户可见特定端点，防止有人误接外部服务造成泄露。
对于权限控制，除了平台自带的角色体系，还可以结合企业LDAP或OAuth服务。在.env中配置LDAP_相关参数后，用户可使用域账号登录。如下代码展示了在配置文件中开启LDAP的思路：
# 在自定义配置片段中启用LDAP
ldap:
enabled: true
server_url: ldap://192.168.0.1:389
bind_dn: cn=admin,dc=corp,dc=local
search_base: ou=people,dc=corp,dc=local
user_filter: (uid={username})
完成上述设置后，企业成员就能在受控环境中搭建AI客服、文档问答等应用。后续可通过Nginx反向代理增加HTTPS证书，并定期备份PostgreSQL与向量库数据，保障业务连续性。
常见故障与排查思路
实际部署里，最容易遇到的是容器启动后页面空白或API报错。这类问题多半源于.env中SECRET_KEY缺失或数据库迁移未执行。Dify在web服务启动前会通过api容器跑数据库迁移，如果日志中出现relation does not exist，可以手动进入api容器执行升级命令。
另一个常见情况是知识库上传文件后嵌入失败，通常因为向量库连接地址错误，或worker容器没有足够内存做文本切片。此时应查看worker日志，确认VECTOR_STORE与环境一致。若使用Qdrant，要在Compose中移除Weaviate并添加Qdrant服务，同时修改环境变量指向新端点。
当多个部门共用一套平台且出现端口冲突时，不要直接改源码，而应通过Docker Compose的ports映射解决。比如将内部80映射到主机8080，再用反向代理统一入口。保持部署文件清晰，有利于后期跟随官方版本升级，减少定制带来的维护成本。