如何用 export-app-migration 脚本化导出实现 Dify 应用的可重复跨环境迁移【免费下载链接】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 源环境里的 workflow工作流应用和 advanced-chatchatflow应用连同一个工作区内的自定义工具依赖周期性地、可重复地搬到另一个环境例如 staging 到 production而不是每次手动操作时可以使用 Dify 提供的脚本化导出链路先生成一份导出配置 JSON 模板编辑后用它跑export-app-migration生成迁移包再在目标环境用import-app-migration导入。因为整个流程由一个 JSON 配置文件驱动同一份配置可以反复执行适合放进自动化流程。Dify 官方同时提供了一个交互式向导app-migration-wizard文档建议一次性迁移优先用向导只有当你需要可重复的自动化时才走本文的脚本化路径见 docs/cross-env-app-migration/README.md。迁移包可以包含以下内容workflow 应用和 advanced-chat 应用自定义 API 工具 provider、workflow 工具 providerMCP 工具 provider但仅在显式开启 secrets 导出时MCP 工具、内置工具和插件工具的依赖元数据——这些工具本身不会被序列化进包里目标环境必须已经安装并配置好。注意两个边界条件只支持从单个源工作区导出source_tenant.mode必须为single源和目标工作区的名称不需要一致。准备条件在源环境的 Difyapi/目录下有可用的 Python 虚拟环境文档示例中通过source .venv/bin/activate激活后使用uv run flask执行命令。在include_secrets为false的默认情况下导入前需要在目标环境完成以下准备安装或启用所需内置/插件工具手动创建并配置对应的 MCP provider对自定义 API 工具在目标工作区重新填写凭据。这些步骤来自文档 FAQ 中列出的处理方式。第一步生成导出配置模板在源环境执行cd api source .venv/bin/activate uv run flask app-migration-template --output export-config.jsonapp-migration-template的参数--output可选写入模板 JSON 文件的路径省略时模板直接打印到 stdout。--overwrite可选允许覆盖已存在的输出文件不加此参数时如果--output指定的文件已存在命令会直接失败。第二步编辑 export-config.json命令生成的模板结构如下apps.name处的admins Workspace是模板自带的示例工作区名需要替换为你源环境中的真实工作区名{ source_tenant: { mode: single, id: , name: admins Workspace }, apps: { modes: [workflow, advanced-chat], ids: [], all: true }, include_referenced_tools: true, additional_tools: { api_tools: [], workflow_tools: [], mcp_tools: [] }, include_secrets: false, import_options: { create_app_api_token_on_import: false, id_strategy: preserve-id, conflict_strategy: fail } }各字段含义引自文档source_tenant.mode必须为single。source_tenant.id可选的源工作区 UUID。工作区重名或想严格指定源时使用一旦填写ID 和name必须匹配。source_tenant.name必填的源工作区名称。apps.modes可选应用类型校验列表支持workflow和advanced-chat。apps.all为true时导出所选源工作区的全部受支持应用为false时只导出apps.ids中列出的应用 ID。include_referenced_tools建议保持true。开启后 Dify 会扫描所选 workflow/chatflow 的图和 agent 工具配置自动发现并去重引用的自定义 API 工具、workflow 工具和 MCP 工具引用降低导入后工作流引用缺失 provider 的概率。additional_tools.api_tools/workflow_tools/mcp_tools可选在自动发现之外额外导出指定工具。api_tools填 provider 名称workflow_tools填 provider IDmcp_tools填 provider ID 或 server identifier。include_secrets默认false即安全默认值。为false时凭据被省略、MCP provider 只记录依赖元数据为true时包里会写入自定义 API 凭据、workflow/app DSL 密文值以及完整的 MCP 连接数据服务器 URL、请求头、认证数据、缓存的工具列表此时必须把迁移包 JSON 当作敏感数据保管和传输。import_options.create_app_api_token_on_import默认false。导入时为没有 token 的已导入应用创建 app API token或复用已有 token 的包级默认开关。import_options.id_strategypreserve-id或generate-new-id默认preserve-id。import_options.conflict_strategyfail、skip或update模板默认fail。ID 策略的选择依据来自文档 FAQ用preserve-id默认目标环境与源环境互为镜像如 staging 到 production、希望工作流和 provider 引用尽量保持稳定、且目标环境不存在占用相同 ID 的无关资源。用generate-new-id目标环境已有可能与源 ID 冲突的资源、把包当作拷贝而非镜像导入、或不想在目标环境保留源库 ID。注意导入会记录源到目标的 ID 映射生成新 ID 时 workflow DSL 中的 provider 引用会按映射改写纯依赖元数据如未导出 secrets 的 MCP provider仍需手动在目标侧配置。冲突策略fail在第一个目标资源冲突处停止已提交资源不回滚skip保留目标现有资源并跳过该资源update就地更新目标现有资源。文档特别提醒如果同一个 ID 在目标环境被不同资源占用使用update前必须仔细核对。第三步执行脚本化导出cd api source .venv/bin/activate uv run flask export-app-migration \ --input export-config.json \ --output migration-package.json参数说明--input必填导出配置 JSON 的路径。--output必填迁移包 JSON 的写入路径。--overwrite可选。不加时如果--output指向的文件已存在命令会失败这保证同一条自动化命令不会静默覆盖上一次导出的包。命令成功后终端输出Output written to migration-package.json随后打印一份导出报告按资源类型和状态逐行计数如workflow created: N并列出所有状态为dependency-only、skipped或unresolved且带说明信息的条目方便在导入前判断哪些资源需要目标侧手动跟进。第四步在目标环境导入把生成的migration-package.json复制到目标环境执行cd api source .venv/bin/activate uv run flask import-app-migration \ --input migration-package.json \ --target-tenant production Workspace参数说明--input必填迁移包 JSON 路径。--target-tenant当包元数据中尚未包含目标工作区时必填可传目标工作区名或工作区 UUID。它会覆盖包元数据文档建议可复用包都显式传这个参数。--operator-email可选目标工作区中作为导入操作者的账号邮箱省略时使用目标工作区最早的 owner 账号。--id-strategy/--conflict-strategy/--create-app-api-token-on-import或--no-create-app-api-token-on-import可选用于在导入时覆盖包内import_options的默认值取值与导出配置字段一致。结果验证导入命令完成后会打印一份导入报告包含解析出的目标工作区和操作者、各类资源的 created/updated/skipped 计数、未解析依赖unresolved dependencies、app API token 的创建与复用数量以及用于重写引用的 ID 映射源 ID - 目标 ID。验证时按这份报告逐项检查target tenant与operator是否为预期的目标工作区和账号状态为dependency-only、skipped、unresolved的条目通常需要手动跟进内置/插件工具要在目标环境单独提供MCP 工具在未导出 secrets 时需要手动配置 provider自定义 API 工具需要重新填写凭据ID 映射列表- {source_id} - {target_id}应覆盖被改写的 workflow 工具/provider 引用generate-new-id策略下尤其要完整核对。报告由 api/services/data_migration/report_service.py 渲染三个命令向导导出、脚本化导出、导入共用同一套报告逻辑命令实现见 api/commands/data_migration.py。限制与注意事项迁移包版本为1导入时会校验包版本不支持的版本会直接报错。内置工具和插件工具永远不会作为自定义迁移数据序列化只记录为依赖目标环境必须自行安装和配置。include_secrets: false意味着迁移包对敏感运行时配置“有意不完整”DSL 密文被省略或掩码导入后需要人工复查每个迁移应用的工具节点、agent 工具配置、环境变量、应用变量和凭据相关设置。如果需要包携带完整 MCP provider 配置或凭据用include_secrets: true重新导出并按文档要求把 JSON 包作为密钥保管、传输安全策略要求时导入后删除该包。文档给出的最短推荐路径仍是“向导导出 导入”uv run flask app-migration-wizard交互式完成选择并写出migration-data-YYYYMMDD-HHMMSS.json包再执行同样的import-app-migration导入。两者使用同一个导出服务脚本化路径的意义在于配置可固化、可重复执行。【免费下载链接】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），仅供参考 如何用 export-app-migration 脚本化导出实现 Dify 应用的可重复跨环境迁移
如何用 export-app-migration 脚本化导出实现 Dify 应用的可重复跨环境迁移【免费下载链接】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 源环境里的 workflow工作流应用和 advanced-chatchatflow应用连同一个工作区内的自定义工具依赖周期性地、可重复地搬到另一个环境例如 staging 到 production而不是每次手动操作时可以使用 Dify 提供的脚本化导出链路先生成一份导出配置 JSON 模板编辑后用它跑export-app-migration生成迁移包再在目标环境用import-app-migration导入。因为整个流程由一个 JSON 配置文件驱动同一份配置可以反复执行适合放进自动化流程。Dify 官方同时提供了一个交互式向导app-migration-wizard文档建议一次性迁移优先用向导只有当你需要可重复的自动化时才走本文的脚本化路径见 docs/cross-env-app-migration/README.md。迁移包可以包含以下内容workflow 应用和 advanced-chat 应用自定义 API 工具 provider、workflow 工具 providerMCP 工具 provider但仅在显式开启 secrets 导出时MCP 工具、内置工具和插件工具的依赖元数据——这些工具本身不会被序列化进包里目标环境必须已经安装并配置好。注意两个边界条件只支持从单个源工作区导出source_tenant.mode必须为single源和目标工作区的名称不需要一致。准备条件在源环境的 Difyapi/目录下有可用的 Python 虚拟环境文档示例中通过source .venv/bin/activate激活后使用uv run flask执行命令。在include_secrets为false的默认情况下导入前需要在目标环境完成以下准备安装或启用所需内置/插件工具手动创建并配置对应的 MCP provider对自定义 API 工具在目标工作区重新填写凭据。这些步骤来自文档 FAQ 中列出的处理方式。第一步生成导出配置模板在源环境执行cd api source .venv/bin/activate uv run flask app-migration-template --output export-config.jsonapp-migration-template的参数--output可选写入模板 JSON 文件的路径省略时模板直接打印到 stdout。--overwrite可选允许覆盖已存在的输出文件不加此参数时如果--output指定的文件已存在命令会直接失败。第二步编辑 export-config.json命令生成的模板结构如下apps.name处的admins Workspace是模板自带的示例工作区名需要替换为你源环境中的真实工作区名{ source_tenant: { mode: single, id: , name: admins Workspace }, apps: { modes: [workflow, advanced-chat], ids: [], all: true }, include_referenced_tools: true, additional_tools: { api_tools: [], workflow_tools: [], mcp_tools: [] }, include_secrets: false, import_options: { create_app_api_token_on_import: false, id_strategy: preserve-id, conflict_strategy: fail } }各字段含义引自文档source_tenant.mode必须为single。source_tenant.id可选的源工作区 UUID。工作区重名或想严格指定源时使用一旦填写ID 和name必须匹配。source_tenant.name必填的源工作区名称。apps.modes可选应用类型校验列表支持workflow和advanced-chat。apps.all为true时导出所选源工作区的全部受支持应用为false时只导出apps.ids中列出的应用 ID。include_referenced_tools建议保持true。开启后 Dify 会扫描所选 workflow/chatflow 的图和 agent 工具配置自动发现并去重引用的自定义 API 工具、workflow 工具和 MCP 工具引用降低导入后工作流引用缺失 provider 的概率。additional_tools.api_tools/workflow_tools/mcp_tools可选在自动发现之外额外导出指定工具。api_tools填 provider 名称workflow_tools填 provider IDmcp_tools填 provider ID 或 server identifier。include_secrets默认false即安全默认值。为false时凭据被省略、MCP provider 只记录依赖元数据为true时包里会写入自定义 API 凭据、workflow/app DSL 密文值以及完整的 MCP 连接数据服务器 URL、请求头、认证数据、缓存的工具列表此时必须把迁移包 JSON 当作敏感数据保管和传输。import_options.create_app_api_token_on_import默认false。导入时为没有 token 的已导入应用创建 app API token或复用已有 token 的包级默认开关。import_options.id_strategypreserve-id或generate-new-id默认preserve-id。import_options.conflict_strategyfail、skip或update模板默认fail。ID 策略的选择依据来自文档 FAQ用preserve-id默认目标环境与源环境互为镜像如 staging 到 production、希望工作流和 provider 引用尽量保持稳定、且目标环境不存在占用相同 ID 的无关资源。用generate-new-id目标环境已有可能与源 ID 冲突的资源、把包当作拷贝而非镜像导入、或不想在目标环境保留源库 ID。注意导入会记录源到目标的 ID 映射生成新 ID 时 workflow DSL 中的 provider 引用会按映射改写纯依赖元数据如未导出 secrets 的 MCP provider仍需手动在目标侧配置。冲突策略fail在第一个目标资源冲突处停止已提交资源不回滚skip保留目标现有资源并跳过该资源update就地更新目标现有资源。文档特别提醒如果同一个 ID 在目标环境被不同资源占用使用update前必须仔细核对。第三步执行脚本化导出cd api source .venv/bin/activate uv run flask export-app-migration \ --input export-config.json \ --output migration-package.json参数说明--input必填导出配置 JSON 的路径。--output必填迁移包 JSON 的写入路径。--overwrite可选。不加时如果--output指向的文件已存在命令会失败这保证同一条自动化命令不会静默覆盖上一次导出的包。命令成功后终端输出Output written to migration-package.json随后打印一份导出报告按资源类型和状态逐行计数如workflow created: N并列出所有状态为dependency-only、skipped或unresolved且带说明信息的条目方便在导入前判断哪些资源需要目标侧手动跟进。第四步在目标环境导入把生成的migration-package.json复制到目标环境执行cd api source .venv/bin/activate uv run flask import-app-migration \ --input migration-package.json \ --target-tenant production Workspace参数说明--input必填迁移包 JSON 路径。--target-tenant当包元数据中尚未包含目标工作区时必填可传目标工作区名或工作区 UUID。它会覆盖包元数据文档建议可复用包都显式传这个参数。--operator-email可选目标工作区中作为导入操作者的账号邮箱省略时使用目标工作区最早的 owner 账号。--id-strategy/--conflict-strategy/--create-app-api-token-on-import或--no-create-app-api-token-on-import可选用于在导入时覆盖包内import_options的默认值取值与导出配置字段一致。结果验证导入命令完成后会打印一份导入报告包含解析出的目标工作区和操作者、各类资源的 created/updated/skipped 计数、未解析依赖unresolved dependencies、app API token 的创建与复用数量以及用于重写引用的 ID 映射源 ID - 目标 ID。验证时按这份报告逐项检查target tenant与operator是否为预期的目标工作区和账号状态为dependency-only、skipped、unresolved的条目通常需要手动跟进内置/插件工具要在目标环境单独提供MCP 工具在未导出 secrets 时需要手动配置 provider自定义 API 工具需要重新填写凭据ID 映射列表- {source_id} - {target_id}应覆盖被改写的 workflow 工具/provider 引用generate-new-id策略下尤其要完整核对。报告由 api/services/data_migration/report_service.py 渲染三个命令向导导出、脚本化导出、导入共用同一套报告逻辑命令实现见 api/commands/data_migration.py。限制与注意事项迁移包版本为1导入时会校验包版本不支持的版本会直接报错。内置工具和插件工具永远不会作为自定义迁移数据序列化只记录为依赖目标环境必须自行安装和配置。include_secrets: false意味着迁移包对敏感运行时配置“有意不完整”DSL 密文被省略或掩码导入后需要人工复查每个迁移应用的工具节点、agent 工具配置、环境变量、应用变量和凭据相关设置。如果需要包携带完整 MCP provider 配置或凭据用include_secrets: true重新导出并按文档要求把 JSON 包作为密钥保管、传输安全策略要求时导入后删除该包。文档给出的最短推荐路径仍是“向导导出 导入”uv run flask app-migration-wizard交互式完成选择并写出migration-data-YYYYMMDD-HHMMSS.json包再执行同样的import-app-migration导入。两者使用同一个导出服务脚本化路径的意义在于配置可固化、可重复执行。【免费下载链接】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），仅供参考