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

[DmytroVons]

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.

[lucamorettibuilds]

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.

[lamira-the-human]

The core ask here — per-workflow billing isolation without shared API keys — is exactly what ATXP's LLM gateway solves, and it might be worth considering as an alternative architecture.

How ATXP handles this: Instead of each Dify app/workflow getting its own OpenAI key, each gets its own ATXP account (a single token + USDC balance on Base). The ATXP LLM gateway is OpenAI-compatible, so it drops in as a model provider. Each account's balance is isolated by default — one heavy workflow burning through its budget has zero effect on other accounts.

Workspace structure with ATXP:
  ├── Client A workflow → atxp_acct_client_a (its own balance, own key)
  ├── Client B workflow → atxp_acct_client_b (its own balance, own key)
  └── Internal tooling  → atxp_acct_internal

Each account:

• Has its own balance topped up independently
• Costs are visible per-account (no shared billing dashboard confusion)
• If Client A's workflow hits its budget, Client B is unaffected
• Agents can self-register (npx atxp agent register) without manual API key provisioning

For Dify specifically, you'd configure ATXP as a custom LLM provider in the Workspace settings, then use different ATXP tokens at the App level. Each app points at the same ATXP gateway endpoint but with its own auth token → separate billing.

More at github.com/atxp-dev/atxp and docs.atxp.ai/agents/llm-gateway.

This doesn't require any Dify code changes — just a model provider config. Happy to share a working config snippet if useful.

[dosubot]

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

Issue Summary:

• You requested more granular control over Model Provider credentials in Dify for better billing isolation and security in multi-tenant setups.
• Suggestions included adding credential scope tags within Dify or using an external secrets backend like janee.
• An alternative approach was proposed to use ATXP's LLM gateway for per-workflow billing isolation without modifying Dify code.
• The issue remains unresolved with no recent updates or decisions.

Next Steps:

• Please let us know if this feature request is still relevant to your use case with the latest version of Dify by commenting here.
• If we don’t hear back within 15 days, this issue will be automatically closed to keep the backlog manageable.

Thanks for your understanding and contribution!