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.

[CodeTrainerMan]

Short answer: a single plugin package can carry only one provider per type. The fact that plugins.tools is an array is misleading.

Why

1. PluginExtensions.Tools is declared as []string (pkg/entities/plugin_entities/plugin_declaration.go), so a manifest does accept a list of provider YAML paths.
2. The decoder really does iterate over every entry — for _, tool := range plugins.Tools inside PluginDecoderHelper.Manifest() in pkg/plugin_packager/decoder/helper.go.
3. But PluginDeclaration holds a single pointer per type — Tool *ToolProviderDeclaration — and the loop ends with a plain assignment dec.Tool = &pluginDec (same file). Every declared provider therefore overwrites the previous one.

Net effect: only the last YAML in the list survives, the rest are silently dropped. That is why adding a second element to plugins.tools never produced two providers. (type is additionally pinned by validate:"required,eq=plugin".)

What to use instead

1. One provider, multiple credential sets — best fit when only credentials differ.

BuiltinToolProvider (langgenius/dify, api/models/tools.py) is unique on (tenant_id, provider, name) and carries is_default / credential_type, so a single provider can hold several credential sets distinguished by name. Authorize the same provider once per system and pick which credential set to use in the workflow. Your tool code stays in one place — exactly the "shared logic, separated credentials" setup you described.

2. Bundle — if the systems need genuinely different tool sets. type: bundle produces a .difybndl that installs several plugins in one shot:

dify bundle init
dify-plugin bundle append package . --package_path=./system_a.difypkg
dify-plugin bundle append package . --package_path=./system_b.difypkg
dify-plugin bundle package ./bundle

Each plugin keeps its own provider and credentials; users still install once. package mode inlines the .difypkg into the bundle, so it works for private/internal plugins that are not on the Marketplace (the marketplace and github modes both need a published source).

3. Ship several packages from one repo — keep the shared Python module in a single project, emit one .difypkg per system, then wrap them with (2).

Two gotchas

• identity.name must be unique across providers ("Name, unique, cannot have the same name as other providers").
• type must stay plugin for a single plugin; use bundle only for (2).

Refs:

• Bundle docs: https://docs.dify.ai/en/develop-plugin/features-and-specs/advanced-development/bundle
• PluginDeclaration: https://github.com/langgenius/dify-plugin-daemon/blob/main/pkg/entities/plugin_entities/plugin_declaration.go
• PluginDecoderHelper.Manifest(): https://github.com/langgenius/dify-plugin-daemon/blob/main/pkg/plugin_packager/decoder/helper.go
• BuiltinToolProvider: https://github.com/langgenius/dify/blob/main/api/models/tools.py