dify - 💡(How to fix) Fix Proposal: Add workspace-level tracing provider configurations with per-app assignment [1 participants]

Self Checks

• I have read the Contributing Guide and Language Policy.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

Dify currently configures tracing providers at the app level. Each app stores whether tracing is enabled and which provider it uses, while the provider credentials and project settings are also saved per app.

This works for small setups, but it becomes hard to manage in a workspace with many apps:

• The same tracing provider credentials need to be configured repeatedly across apps.
• Rotating a provider API key or changing an endpoint requires updating every app that uses it.
• Workspace administrators cannot define a workspace-wide default tracing destination.
• Administrators cannot easily assign different groups of apps to different tracing configurations, such as five apps using "Langfuse Production" and another five using "Phoenix Team A".
• App editors may see tracing as an app-local setting even though tracing destination and credentials are often workspace governance concerns.

I would like Dify to support workspace-level tracing provider configurations, with per-app assignment controls.

The proposed product semantics:

1. A workspace owner/admin can configure one or more tracing provider configs at the workspace level.

   • Multiple configs of the same provider type should be allowed, for example "Langfuse Production" and "Langfuse Staging".
   • Each config should have a workspace-unique display name, provider type, and encrypted provider settings.

2. A workspace owner/admin can explicitly set one workspace tracing config as the default.

   • Creating the first config should not automatically set it as default.
   • If no default is set, apps that are not explicitly assigned to a config should be effectively disabled for tracing.

3. Each app can be assigned by a workspace owner/admin to one of these states:

   • Use workspace default: the app dynamically follows the current workspace default config.
   • Use a specific workspace config: the app always uses the selected config, even if the workspace default changes.
   • Disabled: tracing is explicitly disabled for this app, even if a workspace default exists.

4. If the workspace default changes from config A to config B:

   • Apps using workspace default should automatically switch to B.
   • Apps explicitly assigned to A should continue using A.
   • Apps explicitly disabled should remain disabled.

5. Deleting a workspace tracing config should be protected:

   • If the config is the current workspace default, deletion should be blocked.
   • If any app explicitly references the config, deletion should be blocked and Dify should show how many apps are using it.
   • If no default or app assignment references it, deletion can proceed.

6. Only workspace owner/admin users should manage workspace tracing configs and app tracing assignments.

   • App editors should be able to view the effective tracing status, but should not be able to edit credentials, select providers, or disable tracing.

7. Existing app-level tracing configs should be preserved as legacy behavior for a transition period.

   • Legacy app-level tracing should continue to work.
   • Legacy app-level tracing should take precedence over workspace default to avoid silently changing existing apps when a workspace default is introduced.
   • The UI should show a deprecation notice encouraging administrators to migrate legacy app-level tracing to workspace tracing configs.
   • Once an admin explicitly assigns a workspace config to an app or disables tracing for that app, the legacy app-level config should no longer participate in effective tracing resolution.

This would make tracing easier to govern at workspace scale while preserving existing app behavior during migration.

2. Additional context or comments

The current design is effectively app-centric:

erDiagram
    TENANTS ||--o{ APPS : owns
    APPS ||--o{ TRACE_APP_CONFIG : has

    APPS {
      uuid id
      uuid tenant_id
      text tracing "JSON: enabled + tracing_provider"
    }

    TRACE_APP_CONFIG {
      uuid id
      uuid app_id
      string tracing_provider
      json tracing_config "encrypted provider config"
    }

The proposed design would make provider configs workspace-owned and app selection lightweight:

erDiagram
    TENANTS ||--o{ APPS : owns
    TENANTS ||--o{ WORKSPACE_TRACE_CONFIGS : owns
    TENANTS ||--o| WORKSPACE_TRACE_SETTINGS : has
    APPS ||--o| APP_TRACE_ASSIGNMENTS : has
    WORKSPACE_TRACE_CONFIGS ||--o{ APP_TRACE_ASSIGNMENTS : selected_by
    WORKSPACE_TRACE_CONFIGS ||--o| WORKSPACE_TRACE_SETTINGS : default_for

    WORKSPACE_TRACE_CONFIGS {
      uuid id
      uuid tenant_id
      string display_name
      string tracing_provider
      json tracing_config "encrypted provider config"
    }

    WORKSPACE_TRACE_SETTINGS {
      uuid tenant_id
      uuid default_config_id "nullable"
    }

    APP_TRACE_ASSIGNMENTS {
      uuid app_id
      uuid tenant_id
      string mode "use_config | disabled"
      uuid config_id "nullable"
    }

Suggested effective resolution order:

1. App assignment is disabled: tracing is disabled.
2. App assignment is use_config: use that workspace tracing config.
3. Legacy app-level tracing is enabled: use the legacy app-level config and show a deprecation notice.
4. Workspace default exists: use the workspace default config.
5. Otherwise: tracing is disabled.

This keeps existing apps stable while allowing new workspace-level governance for tracing providers.

3. Can you help us with this feature?

• I am interested in contributing to this feature.