尧图网页设计 
Dify 自托管进阶部署环境变量定制、Grafana 监控与 Kubernetes / 云原生落地【免费下载链接】difyBuild Agentic workflows, RAG pipelines, with rich AI model and tool support on one collaborative workspace. Deploy on cloud, VPC, or self-hosted, so teams move from prototype to production without rebuilding the stack.项目地址: https://gitcode.com/GitHub_Trending/di/dify本文基于 Dify 仓库的 docs/ADVANCED_SETUP.md 展开覆盖自托管部署中的三类进阶主题如何定制 Docker Compose 的环境变量配置.env与docker/envs/两级配置的加载优先级、如何用 Grafana 以 PostgreSQL 为数据源构建应用级监控看板以及如何通过 Helm Chart、Terraform、AWS CDK 等工具把 Dify 部署到 Kubernetes 与各云平台。读完本文你将掌握从改配置重启到生产级多副本、上云的完整进阶路径并能对照仓库源码理解每一项配置的实际作用。一、定制配置修改docker/.env后重启进阶部署的第一站是配置定制。按照 docs/ADVANCED_SETUP.md 的说明如果需要定制配置请编辑docker/.env。启动所需的基础默认值位于docker/.env.example可选的进阶变量按主题拆分在docker/envs/目录下。修改任何内容后从docker目录重新执行docker compose up -d。这条流程在仓库中的实际结构是这样的cd docker cp .env.example .env # 首次部署复制基础模板 # 按需复制进阶配置去掉 .example 后缀 # cp envs/core-services/shared.env.example envs/core-services/shared.env docker compose up -d # 使配置生效.env.example的文件头注释明确了两级配置的分工见 docker/.env.example# Essential defaults for Docker Compose deployments. # Only include variables required for services to start. # Do not add optional variables to this file. # # For a default deployment, copy this file to .env and run: # docker compose up -d # # Optional and provider-specific variables live under docker/envs/. # Copy an optional *.env.example file beside itself without the # .example suffix when you need those advanced settings. # Values in docker/.env take precedence over docker/envs/*.env files.也就是说仓库坚持一个原则根级.env只放启动必需的变量可选的、供应商特定的、服务特定的变量一律下沉到docker/envs/按主题归档。这一设计在 docker/README.md 的 Overview of.env,.env.example, andenvs/ 一节中被再次强调不要把可选或供应商相关变量塞进根级.env.example而应放进对应的envs/*.env.example。1.1docker/envs/的主题化目录结构当前仓库中docker/envs/实际包含四个主题分组目录内容典型文件core-services/API、Worker、Web、Plugin Daemon、Sandbox 等核心服务配置shared.env.example、api.env.example、worker.env.example、web.env.example、plugin-daemon.env.exampledatabases/数据库与缓存db-postgres.env.example、db-mysql.env.example、redis.env.examplevectorstores/18 种向量数据库各自一份配置milvus.env.example、qdrant.env.example、pgvector.env.example 等infrastructure/Nginx、SSRF 代理、etcd、MinIO、Certbot 等基础设施nginx.env.example、ssrf-proxy.env.example此外还有两份不属于子目录的主题文件envs/security.env.example 与 envs/middleware.env.example后者用于开发场景的中间件组合。1.2 源码层面的加载顺序与优先级从源码结构看配置优先级并非口头约定而是直接写死在 Compose 文件中。docker/docker-compose.yaml 顶部用 YAML anchorx-shared-api-worker-config统一定义了env_file列表其中每个envs/文件都标注required: false文件不存在时跳过而根级.env是列表中的最后一项# docker/docker-compose.yaml节选 x-shared-api-worker-config: shared-api-worker-config env_file: - path: ./envs/core-services/shared.env required: false - path: ./envs/core-services/api.env required: false - path: ./envs/security.env required: false - path: ./envs/databases/db-postgres.env required: false # ... 各向量库、基础设施配置共 20 余项均 required: false - ./.envDocker Compose 的env_file语义是列表中后出现的文件覆盖先出现的因此.env的取值优先级最高——这与 docker/README.md Docker Compose readsenvs/*.envfiles when present, then reads.envlast so values in.envtake precedence 的说明完全一致。需要注意docker-compose.yaml文件头有明确警告# WARNING: This file is auto-generated by generate_docker_compose # Do not modify this file directly. Instead, update the .env.example # or docker-compose-template.yaml and regenerate this file.也就是说不要手工修改docker-compose.yaml配置入口应当始终是.env与envs/下的文件Compose 文件由仓库根目录下的docker/generate_docker_compose工具基于 docker-compose-template.yaml 生成。1.3 进阶场景常用的关键变量以下是从 docker/.env.example 中整理、对生产定制最有价值的一组变量含默认值与用途修改后执行docker compose up -d即可生效服务地址与入口变量默认值说明CONSOLE_API_URL/CONSOLE_WEB_URL空控制台 API / Web 的对外 URLSERVICE_API_URL/APP_API_URL/APP_WEB_URL空服务 API 与应用侧 API/Web URLSERVER_CONSOLE_API_URLhttp://api:5001Web 服务端请求使用的内部 API 地址标准 Compose 部署保持默认FILES_URL/INTERNAL_FILES_URL空文件下载/预览的公网与内网基址TRIGGER_URLhttp://localhost触发器回调地址运行时与并发变量默认值说明SECRET_KEY空自动生成会话/JWT/文件 URL 签名密钥留空时 Dify 会在存储目录生成持久密钥LOG_LEVEL/DEBUG/FLASK_DEBUGINFO/false/false日志级别与调试开关SERVER_WORKER_AMOUNT/SERVER_WORKER_CLASS1/geventGunicorn 工作进程数与类型CELERY_WORKER_AMOUNT4Celery 并发 worker 数CELERY_AUTO_SCALEtrue时可配合CELERY_MAX_WORKERS/CELERY_MIN_WORKERS弹性伸缩GUNICORN_TIMEOUT360Gunicorn 请求超时秒数据库与缓存变量默认值说明DB_TYPEpostgresqlpostgresql或mysql同时决定 Compose profile见下文 1.4DB_USERNAME/DB_PASSWORD/DB_HOST/DB_PORT/DB_DATABASEpostgres/difyai123456/db_postgres/5432/difyPostgreSQL 连接信息SQLALCHEMY_POOL_SIZE/SQLALCHEMY_MAX_OVERFLOW30/10SQLAlchemy 连接池大小REDIS_HOST/REDIS_PASSWORD/REDIS_DBredis/difyai123456/0Redis 连接信息REDIS_KEY_PREFIX可为 Redis 键、topic、流统一加命名空间前缀CELERY_BROKER_URLredis://:difyai123456redis:6379/1Celery 消息代理存储与向量库变量默认值说明STORAGE_TYPE/OPENDAL_SCHEME/OPENDAL_FS_ROOTopendal/fs/storage默认本地文件存储切换到 S3、Azure Blob 等后端时使用envs/中对应文件VECTOR_STOREweaviate向量库类型可切换为milvus、qdrant、pgvector、opensearch等WEAVIATE_ENDPOINT/WEAVIATE_API_KEYhttp://weaviate:8080/ 内置开发密钥默认 Weaviate 连接配置安全相关生产必改变量默认值说明WEB_API_CORS_ALLOW_ORIGINS/CONSOLE_CORS_ALLOW_ORIGINS*跨域白名单生产建议收紧SSRF_PROXY_ALLOW_PRIVATE_IPS空拒绝私网需要让 HTTP 请求节点/工具访问内网地址时填入允许的 CIDR 段如172.21.0.0/16,10.0.0.0/8DIFY_AGENT_API_TOKEN/DIFY_AGENT_SERVER_SECRET_KEY开发默认值文件内注释明确提示生产环境请替换可用python -c import secrets; print(secrets.token_urlsafe(32))生成PLUGIN_DAEMON_KEY/PLUGIN_DIFY_INNER_API_KEY内置开发密钥插件守护进程与 API 内部通信密钥完整的可选变量还有登录方式ENABLE_EMAIL_CODE_LOGIN、ENABLE_SOCIAL_OAUTH_LOGIN、文件上传限制UPLOAD_FILE_SIZE_LIMIT等、工作流限额WORKFLOW_MAX_EXECUTION_TIME、WORKFLOW_MAX_EXECUTION_STEPS、插件市场开关MARKETPLACE_ENABLED等均按主题分散在 envs/core-services/shared.env.example 等文件中。1.4 用VECTOR_STORE与DB_TYPE切换服务组合.env.example的最后一行揭示了服务组合的自动切换机制COMPOSE_PROFILES${VECTOR_STORE:-weaviate},${DB_TYPE:-postgresql},collaboration从源码结构看docker-compose.yaml中每个可选服务各向量库、db_mysql、api_websocket、certbot等都声明了自己的profiles只有出现在COMPOSE_PROFILES中的服务才会随docker compose up -d启动。例如默认部署实际拉起的向量库与数据库服务就是 weaviate 与 db_postgres改成VECTOR_STOREmilvus、DB_TYPEmysql后启动的就是 qdrant 之外的另一组服务。collaborationprofile 控制专用的 websocket 服务api_websocket如需停用可从COMPOSE_PROFILES中移除该值。1.5 版本升级时的环境变量同步工具当你长期维护一份从.env.example复制的完整.env升级 Dify 后可以用仓库提供的单向同步脚本 docker/dify-env-sync.sh对应实现为 docker/dify-env-sync.py把新增变量安全合并进.env。根据 docker/README.md 的说明同步是单向的只从.env.example到.env.env中已有值绝不会被自动覆盖执行前会自动把当前.env备份到env-backup/目录带时间戳文件名会展示差异以及从.env.example中被移除的变量供人工审查。chmod x dify-env-sync.sh # 首次使用 ./dify-env-sync.sh适用时机升级到引入新变量的版本后、或.env已经积累大量自定义值时。二、用 Grafana 监控指标docs/ADVANCED_SETUP.md 给出的监控方案是向 Grafana 导入 Dify 官方社区看板以 Dify 的 PostgreSQL 数据库为数据源从而以应用apps、租户tenants、消息messages等粒度监控运行指标Import the dashboard to Grafana, using Difys PostgreSQL database as data source, to monitor metrics in granularity of apps, tenants, messages, and more.官方看板为社区贡献项目 dify-grafana-dashboard作者 bowenliang123仓库文档原文附有该项目链接可在其项目主页获取看板 JSON 后导入 Grafana。由于数据源是业务数据库本身这套方案对自托管部署非常友好不需要在 API 侧额外暴露 Prometheus 端点只需让 Grafana 的数据源指向 docker/.env.example 中DB_HOST/DB_PORT/DB_DATABASE对应的 PostgreSQL默认db_postgres:5432/dify即可直接查询apps、tenants、messages等表统计活跃度与用量。使用前提与限制是该路径依赖关系型数据库中的业务数据反映的是用量/活跃度类指标进程级的 trace、metric如请求延迟、队列深度请走 OpenTelemetry 路线——即 envs/core-services/shared.env.example 中的ENABLE_OTELtrue加OTLP_BASE_ENDPOINT默认http://localhost:4318配合OTEL_SAMPLING_RATE、OTEL_BATCH_EXPORT_SCHEDULE_DELAY等调参项接入你自己的 CollectorQUEUE_MONITOR_THRESHOLD默认 200与QUEUE_MONITOR_ALERT_EMAILS提供了队列积压邮件告警可视为监控的补充手段。三、部署到 Kubernetes若需要高可用部署docs/ADVANCED_SETUP.md 指出社区贡献了多个 Helm Chart 与 YAML 方案可将 Dify 部署到 Kubernetes。原文列出的社区资源链接见原文档Helm ChartLeoQuotedouban/charts的 Dify ChartBorisPolonsky 的 dify-helmmagicsong 的 ai-chartsK8s YAMLWinson-030 的 dify-kuberneteswyy-holding 的 dify-k8sZhoneym 的 DifyAI-Kubernetes支持 Dify v1.6.0 的较新方案选型建议从仓库结构推断Docker Compose 中通过COMPOSE_PROFILES切换向量库/数据库的做法在 K8s 上等价于部署时选择一组 StatefulSet/Deployment因此社区 Chart 通常也会把VECTOR_STORE、DB_TYPE抽象成 values 选项选用时应确认 Chart 支持的 Dify 版本与当前仓库版本匹配如 Zhoneym 方案明确标注支持 v1.6.0并复用本文第一节整理的变量语义来填写 values。3.1 Terraform 一键上云同一文档还收录了 Terraform 部署方案Azurenikawang 的 dify-azure-terraformAzure 全局区域Google CloudsotazumDeNA的 dify-google-cloud-terraform两者均以一条命令拉起整套依赖含向量库、对象存储、数据库为目标适合把 Dify 作为 IaC 的一部分纳入团队云资源管理。3.2 AWSCDK 部署KevinZhao 的 AWS CDK 方案基于EKStmokmss 的 AWS CDK 方案基于ECS两者同为 AWS CDK 实现差异在于运行时是 KubernetesEKS还是托管容器ECS可按团队既有运维栈选择。3.3 阿里云与 Azure 托管方案阿里云计算巢Computing Nest通过计算巢服务目录一键部署 Dify 社区版阿里云数据管理DMS通过阿里云 DMS 一键部署 DifyAKS Azure DevOps PipelineLeoZhang 提供基于 Helm Chart 的 Azure DevOps 流水线一键部署 Dify 到 AKS。四、小结与仓库入口索引进阶部署的主线可以概括为三层配置层——一切定制从docker/.env出发按主题把可选变量下沉到docker/envs/用VECTOR_STORE、DB_TYPE控制COMPOSE_PROFILES切换服务组合改完docker compose up -d生效升级时用 docker/dify-env-sync.sh 做单向变量同步。可观测层——业务指标用 Grafana PostgreSQL 看板进程级指标用ENABLE_OTEL走 OTLP 通道队列积压用QUEUE_MONITOR_*变量兜底。平台层——K8s 用户选社区 Helm Chart / YAML云用户选 Terraform / CDK / 计算巢 / 计算巢 DMS / AKS Pipeline均为社区与云厂商贡献方案注意核对版本兼容性。继续深入的仓库入口docker/README.mdCompose 部署、中间件开发模式docker-compose.middleware.yaml与迁移说明docker/.env.example启动必需变量全集docker/envs/按主题拆分的进阶配置core-services / databases / vectorstores / infrastructuredocker/docker-compose.yaml由模板自动生成的最终 Compose 文件只读参考勿手改docs/ADVANCED_SETUP.md本文的原始文档【免费下载链接】difyBuild Agentic workflows, RAG pipelines, with rich AI model and tool support on one collaborative workspace. Deploy on cloud, VPC, or self-hosted, so teams move from prototype to production without rebuilding the stack.项目地址: https://gitcode.com/GitHub_Trending/di/dify创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Dify 自托管进阶部署：环境变量定制、Grafana 监控与 Kubernetes / 云原生落地
Dify 自托管进阶部署环境变量定制、Grafana 监控与 Kubernetes / 云原生落地【免费下载链接】difyBuild Agentic workflows, RAG pipelines, with rich AI model and tool support on one collaborative workspace. Deploy on cloud, VPC, or self-hosted, so teams move from prototype to production without rebuilding the stack.项目地址: https://gitcode.com/GitHub_Trending/di/dify本文基于 Dify 仓库的 docs/ADVANCED_SETUP.md 展开覆盖自托管部署中的三类进阶主题如何定制 Docker Compose 的环境变量配置.env与docker/envs/两级配置的加载优先级、如何用 Grafana 以 PostgreSQL 为数据源构建应用级监控看板以及如何通过 Helm Chart、Terraform、AWS CDK 等工具把 Dify 部署到 Kubernetes 与各云平台。读完本文你将掌握从改配置重启到生产级多副本、上云的完整进阶路径并能对照仓库源码理解每一项配置的实际作用。一、定制配置修改docker/.env后重启进阶部署的第一站是配置定制。按照 docs/ADVANCED_SETUP.md 的说明如果需要定制配置请编辑docker/.env。启动所需的基础默认值位于docker/.env.example可选的进阶变量按主题拆分在docker/envs/目录下。修改任何内容后从docker目录重新执行docker compose up -d。这条流程在仓库中的实际结构是这样的cd docker cp .env.example .env # 首次部署复制基础模板 # 按需复制进阶配置去掉 .example 后缀 # cp envs/core-services/shared.env.example envs/core-services/shared.env docker compose up -d # 使配置生效.env.example的文件头注释明确了两级配置的分工见 docker/.env.example# Essential defaults for Docker Compose deployments. # Only include variables required for services to start. # Do not add optional variables to this file. # # For a default deployment, copy this file to .env and run: # docker compose up -d # # Optional and provider-specific variables live under docker/envs/. # Copy an optional *.env.example file beside itself without the # .example suffix when you need those advanced settings. # Values in docker/.env take precedence over docker/envs/*.env files.也就是说仓库坚持一个原则根级.env只放启动必需的变量可选的、供应商特定的、服务特定的变量一律下沉到docker/envs/按主题归档。这一设计在 docker/README.md 的 Overview of.env,.env.example, andenvs/ 一节中被再次强调不要把可选或供应商相关变量塞进根级.env.example而应放进对应的envs/*.env.example。1.1docker/envs/的主题化目录结构当前仓库中docker/envs/实际包含四个主题分组目录内容典型文件core-services/API、Worker、Web、Plugin Daemon、Sandbox 等核心服务配置shared.env.example、api.env.example、worker.env.example、web.env.example、plugin-daemon.env.exampledatabases/数据库与缓存db-postgres.env.example、db-mysql.env.example、redis.env.examplevectorstores/18 种向量数据库各自一份配置milvus.env.example、qdrant.env.example、pgvector.env.example 等infrastructure/Nginx、SSRF 代理、etcd、MinIO、Certbot 等基础设施nginx.env.example、ssrf-proxy.env.example此外还有两份不属于子目录的主题文件envs/security.env.example 与 envs/middleware.env.example后者用于开发场景的中间件组合。1.2 源码层面的加载顺序与优先级从源码结构看配置优先级并非口头约定而是直接写死在 Compose 文件中。docker/docker-compose.yaml 顶部用 YAML anchorx-shared-api-worker-config统一定义了env_file列表其中每个envs/文件都标注required: false文件不存在时跳过而根级.env是列表中的最后一项# docker/docker-compose.yaml节选 x-shared-api-worker-config: shared-api-worker-config env_file: - path: ./envs/core-services/shared.env required: false - path: ./envs/core-services/api.env required: false - path: ./envs/security.env required: false - path: ./envs/databases/db-postgres.env required: false # ... 各向量库、基础设施配置共 20 余项均 required: false - ./.envDocker Compose 的env_file语义是列表中后出现的文件覆盖先出现的因此.env的取值优先级最高——这与 docker/README.md Docker Compose readsenvs/*.envfiles when present, then reads.envlast so values in.envtake precedence 的说明完全一致。需要注意docker-compose.yaml文件头有明确警告# WARNING: This file is auto-generated by generate_docker_compose # Do not modify this file directly. Instead, update the .env.example # or docker-compose-template.yaml and regenerate this file.也就是说不要手工修改docker-compose.yaml配置入口应当始终是.env与envs/下的文件Compose 文件由仓库根目录下的docker/generate_docker_compose工具基于 docker-compose-template.yaml 生成。1.3 进阶场景常用的关键变量以下是从 docker/.env.example 中整理、对生产定制最有价值的一组变量含默认值与用途修改后执行docker compose up -d即可生效服务地址与入口变量默认值说明CONSOLE_API_URL/CONSOLE_WEB_URL空控制台 API / Web 的对外 URLSERVICE_API_URL/APP_API_URL/APP_WEB_URL空服务 API 与应用侧 API/Web URLSERVER_CONSOLE_API_URLhttp://api:5001Web 服务端请求使用的内部 API 地址标准 Compose 部署保持默认FILES_URL/INTERNAL_FILES_URL空文件下载/预览的公网与内网基址TRIGGER_URLhttp://localhost触发器回调地址运行时与并发变量默认值说明SECRET_KEY空自动生成会话/JWT/文件 URL 签名密钥留空时 Dify 会在存储目录生成持久密钥LOG_LEVEL/DEBUG/FLASK_DEBUGINFO/false/false日志级别与调试开关SERVER_WORKER_AMOUNT/SERVER_WORKER_CLASS1/geventGunicorn 工作进程数与类型CELERY_WORKER_AMOUNT4Celery 并发 worker 数CELERY_AUTO_SCALEtrue时可配合CELERY_MAX_WORKERS/CELERY_MIN_WORKERS弹性伸缩GUNICORN_TIMEOUT360Gunicorn 请求超时秒数据库与缓存变量默认值说明DB_TYPEpostgresqlpostgresql或mysql同时决定 Compose profile见下文 1.4DB_USERNAME/DB_PASSWORD/DB_HOST/DB_PORT/DB_DATABASEpostgres/difyai123456/db_postgres/5432/difyPostgreSQL 连接信息SQLALCHEMY_POOL_SIZE/SQLALCHEMY_MAX_OVERFLOW30/10SQLAlchemy 连接池大小REDIS_HOST/REDIS_PASSWORD/REDIS_DBredis/difyai123456/0Redis 连接信息REDIS_KEY_PREFIX可为 Redis 键、topic、流统一加命名空间前缀CELERY_BROKER_URLredis://:difyai123456redis:6379/1Celery 消息代理存储与向量库变量默认值说明STORAGE_TYPE/OPENDAL_SCHEME/OPENDAL_FS_ROOTopendal/fs/storage默认本地文件存储切换到 S3、Azure Blob 等后端时使用envs/中对应文件VECTOR_STOREweaviate向量库类型可切换为milvus、qdrant、pgvector、opensearch等WEAVIATE_ENDPOINT/WEAVIATE_API_KEYhttp://weaviate:8080/ 内置开发密钥默认 Weaviate 连接配置安全相关生产必改变量默认值说明WEB_API_CORS_ALLOW_ORIGINS/CONSOLE_CORS_ALLOW_ORIGINS*跨域白名单生产建议收紧SSRF_PROXY_ALLOW_PRIVATE_IPS空拒绝私网需要让 HTTP 请求节点/工具访问内网地址时填入允许的 CIDR 段如172.21.0.0/16,10.0.0.0/8DIFY_AGENT_API_TOKEN/DIFY_AGENT_SERVER_SECRET_KEY开发默认值文件内注释明确提示生产环境请替换可用python -c import secrets; print(secrets.token_urlsafe(32))生成PLUGIN_DAEMON_KEY/PLUGIN_DIFY_INNER_API_KEY内置开发密钥插件守护进程与 API 内部通信密钥完整的可选变量还有登录方式ENABLE_EMAIL_CODE_LOGIN、ENABLE_SOCIAL_OAUTH_LOGIN、文件上传限制UPLOAD_FILE_SIZE_LIMIT等、工作流限额WORKFLOW_MAX_EXECUTION_TIME、WORKFLOW_MAX_EXECUTION_STEPS、插件市场开关MARKETPLACE_ENABLED等均按主题分散在 envs/core-services/shared.env.example 等文件中。1.4 用VECTOR_STORE与DB_TYPE切换服务组合.env.example的最后一行揭示了服务组合的自动切换机制COMPOSE_PROFILES${VECTOR_STORE:-weaviate},${DB_TYPE:-postgresql},collaboration从源码结构看docker-compose.yaml中每个可选服务各向量库、db_mysql、api_websocket、certbot等都声明了自己的profiles只有出现在COMPOSE_PROFILES中的服务才会随docker compose up -d启动。例如默认部署实际拉起的向量库与数据库服务就是 weaviate 与 db_postgres改成VECTOR_STOREmilvus、DB_TYPEmysql后启动的就是 qdrant 之外的另一组服务。collaborationprofile 控制专用的 websocket 服务api_websocket如需停用可从COMPOSE_PROFILES中移除该值。1.5 版本升级时的环境变量同步工具当你长期维护一份从.env.example复制的完整.env升级 Dify 后可以用仓库提供的单向同步脚本 docker/dify-env-sync.sh对应实现为 docker/dify-env-sync.py把新增变量安全合并进.env。根据 docker/README.md 的说明同步是单向的只从.env.example到.env.env中已有值绝不会被自动覆盖执行前会自动把当前.env备份到env-backup/目录带时间戳文件名会展示差异以及从.env.example中被移除的变量供人工审查。chmod x dify-env-sync.sh # 首次使用 ./dify-env-sync.sh适用时机升级到引入新变量的版本后、或.env已经积累大量自定义值时。二、用 Grafana 监控指标docs/ADVANCED_SETUP.md 给出的监控方案是向 Grafana 导入 Dify 官方社区看板以 Dify 的 PostgreSQL 数据库为数据源从而以应用apps、租户tenants、消息messages等粒度监控运行指标Import the dashboard to Grafana, using Difys PostgreSQL database as data source, to monitor metrics in granularity of apps, tenants, messages, and more.官方看板为社区贡献项目 dify-grafana-dashboard作者 bowenliang123仓库文档原文附有该项目链接可在其项目主页获取看板 JSON 后导入 Grafana。由于数据源是业务数据库本身这套方案对自托管部署非常友好不需要在 API 侧额外暴露 Prometheus 端点只需让 Grafana 的数据源指向 docker/.env.example 中DB_HOST/DB_PORT/DB_DATABASE对应的 PostgreSQL默认db_postgres:5432/dify即可直接查询apps、tenants、messages等表统计活跃度与用量。使用前提与限制是该路径依赖关系型数据库中的业务数据反映的是用量/活跃度类指标进程级的 trace、metric如请求延迟、队列深度请走 OpenTelemetry 路线——即 envs/core-services/shared.env.example 中的ENABLE_OTELtrue加OTLP_BASE_ENDPOINT默认http://localhost:4318配合OTEL_SAMPLING_RATE、OTEL_BATCH_EXPORT_SCHEDULE_DELAY等调参项接入你自己的 CollectorQUEUE_MONITOR_THRESHOLD默认 200与QUEUE_MONITOR_ALERT_EMAILS提供了队列积压邮件告警可视为监控的补充手段。三、部署到 Kubernetes若需要高可用部署docs/ADVANCED_SETUP.md 指出社区贡献了多个 Helm Chart 与 YAML 方案可将 Dify 部署到 Kubernetes。原文列出的社区资源链接见原文档Helm ChartLeoQuotedouban/charts的 Dify ChartBorisPolonsky 的 dify-helmmagicsong 的 ai-chartsK8s YAMLWinson-030 的 dify-kuberneteswyy-holding 的 dify-k8sZhoneym 的 DifyAI-Kubernetes支持 Dify v1.6.0 的较新方案选型建议从仓库结构推断Docker Compose 中通过COMPOSE_PROFILES切换向量库/数据库的做法在 K8s 上等价于部署时选择一组 StatefulSet/Deployment因此社区 Chart 通常也会把VECTOR_STORE、DB_TYPE抽象成 values 选项选用时应确认 Chart 支持的 Dify 版本与当前仓库版本匹配如 Zhoneym 方案明确标注支持 v1.6.0并复用本文第一节整理的变量语义来填写 values。3.1 Terraform 一键上云同一文档还收录了 Terraform 部署方案Azurenikawang 的 dify-azure-terraformAzure 全局区域Google CloudsotazumDeNA的 dify-google-cloud-terraform两者均以一条命令拉起整套依赖含向量库、对象存储、数据库为目标适合把 Dify 作为 IaC 的一部分纳入团队云资源管理。3.2 AWSCDK 部署KevinZhao 的 AWS CDK 方案基于EKStmokmss 的 AWS CDK 方案基于ECS两者同为 AWS CDK 实现差异在于运行时是 KubernetesEKS还是托管容器ECS可按团队既有运维栈选择。3.3 阿里云与 Azure 托管方案阿里云计算巢Computing Nest通过计算巢服务目录一键部署 Dify 社区版阿里云数据管理DMS通过阿里云 DMS 一键部署 DifyAKS Azure DevOps PipelineLeoZhang 提供基于 Helm Chart 的 Azure DevOps 流水线一键部署 Dify 到 AKS。四、小结与仓库入口索引进阶部署的主线可以概括为三层配置层——一切定制从docker/.env出发按主题把可选变量下沉到docker/envs/用VECTOR_STORE、DB_TYPE控制COMPOSE_PROFILES切换服务组合改完docker compose up -d生效升级时用 docker/dify-env-sync.sh 做单向变量同步。可观测层——业务指标用 Grafana PostgreSQL 看板进程级指标用ENABLE_OTEL走 OTLP 通道队列积压用QUEUE_MONITOR_*变量兜底。平台层——K8s 用户选社区 Helm Chart / YAML云用户选 Terraform / CDK / 计算巢 / 计算巢 DMS / AKS Pipeline均为社区与云厂商贡献方案注意核对版本兼容性。继续深入的仓库入口docker/README.mdCompose 部署、中间件开发模式docker-compose.middleware.yaml与迁移说明docker/.env.example启动必需变量全集docker/envs/按主题拆分的进阶配置core-services / databases / vectorstores / infrastructuredocker/docker-compose.yaml由模板自动生成的最终 Compose 文件只读参考勿手改docs/ADVANCED_SETUP.md本文的原始文档【免费下载链接】difyBuild Agentic workflows, RAG pipelines, with rich AI model and tool support on one collaborative workspace. Deploy on cloud, VPC, or self-hosted, so teams move from prototype to production without rebuilding the stack.项目地址: https://gitcode.com/GitHub_Trending/di/dify创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考