Feature: Workflow-Level Credential Override for Model Providers

[jortegac]

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.
• 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.

I'm building multiple workflows within the same Dify workspace that need to use different API credentials for the same model provider (e.g., Vertex AI, Gemini, OpenAI).

Current limitation: Credentials are managed at the workspace level (via ProviderCredential) or model level (via ProviderModelCredential), but there is no mechanism to override credentials at the workflow or application level.

Use case examples:

1. Cost tracking per workflow: Different workflows need separate API keys to track costs and usage independently
2. Environment separation: Production vs staging workflows in the same workspace need different credentials
3. Rate limit management: Distribute load across different API keys per workflow to avoid rate limits
4. Audit and tracing: Separate API keys allow better tracing and debugging of specific workflow executions

Current workarounds (all have significant drawbacks):

• Create separate workspaces (duplicates workflows, loses sharing benefits)
• Use Load Balancing (distributes randomly, cannot assign specific keys to specific workflows)
• External API proxy (additional infrastructure complexity)

Proposed solution: Allow workflows/apps to specify a credential override, either by:

1. Adding a credential_id field to workflow node configuration
2. Supporting credential selection via workflow variables
3. Adding app-level credential configuration

2. Additional context or comments

Related issues:

• #4330 - Request for multiple API keys (closed as not planned, but Model-Level Credentials was later added)

Technical context (from codebase analysis):

• Credentials are resolved in ProviderManager.get_configurations(tenant_id) at /api/core/provider_manager.py
• The resolution flow passes only tenant_id, with no workflow/app context
• ProviderConfiguration.get_current_credentials() at /api/core/entities/provider_configuration.py handles credential selection
• Database schema already supports multiple credentials per provider via ProviderCredential and ProviderModelCredential tables

Suggested implementation approach:

1. Extend workflow LLM node schema to include optional credential_id or credential_name
2. Pass workflow context through ModelManager.get_model_instance()
3. Add credential override logic in ProviderConfiguration.get_current_credentials()
4. Update frontend to allow credential selection in workflow node configuration

3. Can you help us with this feature?

• I am interested in contributing to this feature.