langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 20:15:31 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

Feature: Workflow-Level Credential Override for Model Providers #20630

New Issue
Closed
opened 2026-02-21 20:08:15 -05:00 by yindo · 3 comments
yindo commented 2026-02-21 20:08:15 -05:00
Owner
Copy Link
Copy Source

Originally created by @jortegac on GitHub (Nov 27, 2025).

Originally assigned to: @fatelei on GitHub.

Self Checks

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.
Originally created by @jortegac on GitHub (Nov 27, 2025). Originally assigned to: @fatelei on GitHub. ## Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report. - [x] 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](https://github.com/langgenius/dify/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.
yindo added the 💪 enhancement label 2026-02-21 20:08:15 -05:00
yindo closed this issue 2026-02-21 20:08:15 -05:00
yindo commented 2026-02-21 20:08:15 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Dec 29, 2025):

Hi, @jortegac. I'm Dosu, and I'm helping the Dify team manage their backlog and am marking this issue as stale.

Issue Summary:

  • You requested a feature to enable workflow-level credential overrides for model providers in Dify.
  • This would allow different API keys per workflow within the same workspace for better cost tracking, environment separation, rate limit management, and auditing.
  • Currently, credentials can only be set at the workspace or model level, limiting flexibility.
  • Proposed solutions include adding credential fields to workflow nodes, variable-based credential selection, or app-level credential settings.
  • The issue remains unresolved with no recent updates.

Next Steps:

  • Please let me know if this feature request is still relevant to the latest version of Dify by commenting on this issue.
  • If I do not hear back within 15 days, I will automatically close the issue.

Thank you for your understanding and contribution!

@dosubot[bot] commented on GitHub (Dec 29, 2025): Hi, @jortegac. I'm [Dosu](https://dosu.dev), and I'm helping the Dify team manage their backlog and am marking this issue as stale. **Issue Summary:** - You requested a feature to enable workflow-level credential overrides for model providers in Dify. - This would allow different API keys per workflow within the same workspace for better cost tracking, environment separation, rate limit management, and auditing. - Currently, credentials can only be set at the workspace or model level, limiting flexibility. - Proposed solutions include adding credential fields to workflow nodes, variable-based credential selection, or app-level credential settings. - The issue remains unresolved with no recent updates. **Next Steps:** - Please let me know if this feature request is still relevant to the latest version of Dify by commenting on this issue. - If I do not hear back within 15 days, I will automatically close the issue. Thank you for your understanding and contribution!
yindo commented 2026-02-21 20:08:15 -05:00
Author
Owner
Copy Link
Copy Source

@jortegac commented on GitHub (Dec 30, 2025):

@dosubot Still relevant

@jortegac commented on GitHub (Dec 30, 2025): @dosubot Still relevant
yindo commented 2026-02-21 20:08:15 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Dec 30, 2025):

@crazywoola The user @jortegac has confirmed that the feature request for workflow-level credential overrides is still relevant. Could you please assist with this issue?

@dosubot[bot] commented on GitHub (Dec 30, 2025): @crazywoola The user @jortegac has confirmed that the feature request for workflow-level credential overrides is still relevant. Could you please assist with this issue?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 💪 enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#20630
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?