Support for multi providers in a single plugin?

[bromine0x23]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• 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 developing tool plugins for our internal systems.
While some logic shared across systems, credentials are separated, so each system should have an individual plugin.
Maintaining these plugins is a hard work, so I started seeking some simplify way.

I noticed that in manifest.yaml the plugins has array subfields for providers.
So I tried give it more than one element. but didn't work.
Only the last provider installed.

After some digging, I found that dify-plugin-daemon take only a element from the list: pkg/plugin_packager/decoder/helper.go.

Which side shows current design intent? One plugin to only single provider, or multi providers?

2. Additional context or comments

dify: 1.15.0
dify-plugin-daemon: 0.6.3

[dosubot[bot]]

Good question. Based on looking at the codebase, the current design intent is one provider per plugin, even though the manifest schema technically uses list fields.

The plugins field in manifest.yaml is defined with list types (tools: list[str], models: list[str], etc.) [1], so it looks like multiple providers should work. However, as you discovered in the daemon's decoder, only a single element is actually consumed. Every official plugin also follows the single-provider pattern — multiple tools/capabilities are achieved within the one provider definition file rather than through multiple providers [2].

So in practice, the intended approach for your use case would be to either:

1. One plugin per system — each internal system gets its own plugin with its own provider and credentials.
2. One plugin, one provider, multiple tools — if the logic is truly shared and only credentials differ, you could define a single provider with a credential schema that accommodates multiple systems (e.g., separate credential fields per system), then expose tools for each system under that one provider.

Option 1 is more aligned with the current architecture. If you want to reduce maintenance burden for shared logic, you could extract common code into a shared library/module that each plugin imports internally.

It might be worth filing a feature request if you'd like the daemon to actually honor the full list in the plugins field — the schema supports it, but the implementation doesn't currently.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.