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

Per-App / Per-Workflow Model Provider Credentials (API Key Selection) #22162

New Issue
Open
opened 2026-02-21 20:16:00 -05:00 by yindo · 1 comment
yindo commented 2026-02-21 20:16:00 -05:00
Owner
Copy Link
Copy Source

Originally created by @DmytroVons on GitHub (Feb 9, 2026).

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.

Currently, Model Provider configurations (like OpenAI API keys) are managed at the Workspace level. Once an API key is added, it becomes a global resource for all applications and workflows within that workspace.

This creates significant limitations for developers building multi-tenant SaaS products or agencies serving multiple clients:

1. Billing Isolation: It is impossible to separate API usage and costs within the OpenAI dashboard for different clients if they share the same workspace.
2. Quota Management: One "heavy" workflow can exhaust the Rate Limits (RPM/TPM) for all other apps in the same workspace.
3. Security: Agencies often need to use a client's own API key for their specific workflow without giving that key access to other internal projects.

I would like to see an option to select specific credentials at a more granular level (App or Node level):

1. Credential Selection in LLM Nodes: Similar to how "Tools" allow selecting a credential_id, the LLM node in Workflow/Chatflow should allow choosing from a list of previously configured credentials for that provider.
2. App-level Override: The ability to define an API key in the App Settings that overrides the default Workspace key for all nodes within that specific application.
3. Dynamic Credential Input: (Optional) The ability to pass an API key as a variable to an LLM node, allowing for truly dynamic, user-provided key usage.

Separate Workspaces: Currently, the only way to achieve this is by creating a new workspace for every client. This is hard to manage at scale and prevents sharing knowledge bases or internal tools across clients.

HTTP Request Nodes: Manually calling the OpenAI API via HTTP nodes. This works but loses all the benefits of Dify’s native LLM features (streaming, easy prompt formatting, vision support, etc.).

External AI Gateways: Using LiteLLM or One API as a proxy. This adds infrastructure complexity and overhead.

2. Additional context or comments

This request aligns with previous community discussions, such as Discussion #25955, where users expressed the need for per-agent/per-client billing separation. Adding this feature would make Dify a much more powerful tool for professional service providers and SaaS builders.

3. Can you help us with this feature?

  • I am interested in contributing to this feature.
Originally created by @DmytroVons on GitHub (Feb 9, 2026). ### 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, otherwise it will be closed. - [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. Currently, Model Provider configurations (like OpenAI API keys) are managed at the Workspace level. Once an API key is added, it becomes a global resource for all applications and workflows within that workspace. This creates significant limitations for developers building multi-tenant SaaS products or agencies serving multiple clients: 1. Billing Isolation: It is impossible to separate API usage and costs within the OpenAI dashboard for different clients if they share the same workspace. 2. Quota Management: One "heavy" workflow can exhaust the Rate Limits (RPM/TPM) for all other apps in the same workspace. 3. Security: Agencies often need to use a client's own API key for their specific workflow without giving that key access to other internal projects. I would like to see an option to select specific credentials at a more granular level (App or Node level): 1. Credential Selection in LLM Nodes: Similar to how "Tools" allow selecting a credential_id, the LLM node in Workflow/Chatflow should allow choosing from a list of previously configured credentials for that provider. 2. App-level Override: The ability to define an API key in the App Settings that overrides the default Workspace key for all nodes within that specific application. 3. Dynamic Credential Input: (Optional) The ability to pass an API key as a variable to an LLM node, allowing for truly dynamic, user-provided key usage. Separate Workspaces: Currently, the only way to achieve this is by creating a new workspace for every client. This is hard to manage at scale and prevents sharing knowledge bases or internal tools across clients. HTTP Request Nodes: Manually calling the OpenAI API via HTTP nodes. This works but loses all the benefits of Dify’s native LLM features (streaming, easy prompt formatting, vision support, etc.). External AI Gateways: Using LiteLLM or One API as a proxy. This adds infrastructure complexity and overhead. ### 2. Additional context or comments This request aligns with previous community discussions, such as Discussion #25955, where users expressed the need for per-agent/per-client billing separation. Adding this feature would make Dify a much more powerful tool for professional service providers and SaaS builders. ### 3. Can you help us with this feature? - [x] I am interested in contributing to this feature.
yindo added the 💪 enhancement label 2026-02-21 20:16:00 -05:00
yindo commented 2026-02-21 20:16:01 -05:00
Author
Owner
Copy Link
Copy Source

@lucamorettibuilds commented on GitHub (Feb 17, 2026):

This is a common pain point — I hit the same issue running multi-tenant agent workflows.

A couple of patterns I have seen work well for per-app credential isolation:

  1. Credential scope tags — each API key gets tagged with an app/workflow ID. At runtime the credential resolver filters by scope, so App A only sees its own OpenAI key even though they share a workspace. This is simpler than full RBAC but covers the billing isolation use case.

  2. External credential backend via MCP — rather than storing all keys in Dify itself, delegate credential resolution to an MCP secrets server. The app/workflow passes its identity, the secrets server returns only the credentials that app is authorized to use. This also solves the audit trail problem since every credential access is logged externally.

For approach #2, something like janee (MCP-native secrets manager) could serve as the backend — it already supports scoped access policies and session-based credential leasing. The MCP transport means Dify could integrate it like any other tool provider.

The key design question is whether credential scoping should be a first-class Dify concept (built into the workspace model) or delegated to an external system. First-class is better UX for simple cases, but external delegation scales better for the multi-tenant SaaS scenario you describe.

Would love to see this get traction — per-app credential isolation is table stakes for production agent platforms.

@lucamorettibuilds commented on GitHub (Feb 17, 2026): This is a common pain point — I hit the same issue running multi-tenant agent workflows. A couple of patterns I have seen work well for per-app credential isolation: 1. **Credential scope tags** — each API key gets tagged with an app/workflow ID. At runtime the credential resolver filters by scope, so App A only sees its own OpenAI key even though they share a workspace. This is simpler than full RBAC but covers the billing isolation use case. 2. **External credential backend via MCP** — rather than storing all keys in Dify itself, delegate credential resolution to an MCP secrets server. The app/workflow passes its identity, the secrets server returns only the credentials that app is authorized to use. This also solves the audit trail problem since every credential access is logged externally. For approach #2, something like [janee](https://github.com/rsdouglas/janee) (MCP-native secrets manager) could serve as the backend — it already supports scoped access policies and session-based credential leasing. The MCP transport means Dify could integrate it like any other tool provider. The key design question is whether credential scoping should be a first-class Dify concept (built into the workspace model) or delegated to an external system. First-class is better UX for simple cases, but external delegation scales better for the multi-tenant SaaS scenario you describe. Would love to see this get traction — per-app credential isolation is table stakes for production agent platforms.
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#22162
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?