langgenius/dify-plugin-daemon
1
0
Fork 0
mirror of https://github.com/langgenius/dify-plugin-daemon.git synced 2026-07-21 17:25:23 -04:00
Code Issues 111 Packages Projects Releases 10 Wiki Activity

dify-plugin-daemon documentation with K8S deployments and scaling-out issues #159

New Issue
Open
opened 2026-02-16 00:20:12 -05:00 by yindo · 2 comments
yindo commented 2026-02-16 00:20:12 -05:00
Owner
Copy Link
Copy Source

Originally created by @dimitrisalo on GitHub (Jul 10, 2025).

Self Checks

To make sure we get to you in time, please check the following :)

  • 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."

Is your feature request related to a problem? Please describe.
We are currently using Dify version 0.15.0 for our production workloads (deployed in our production Kubernetes cluster). Since this version is already significantly outdated, we would like to upgrade to the latest available version. Unfortunately, we are blocked by the Kubernetes scale-out limitations that the plugin-daemon currently faces.

Describe the solution you'd like

  • At the very least, we would appreciate a mitigation path that allows us to continue using our production Kubernetes-deployed Dify installation. Currently, our only viable alternative seems to be replacing Dify entirely. While we don’t yet have enough user adoption to justify migrating to the cloud-based Dify solution, we anticipate this will change as we develop more features.
  • Ideally, we would like to see an implementation that supports Kubernetes deployments with scale-out capability.
  • Regardless of which of the above is feasible, we would like to understand the underlying issue and its root cause. This would help us evaluate whether it makes sense to contribute resources toward a solution for the community edition. A better documentation of the issue would very helpful on this area.

Describe alternatives you've considered

  • Currently, we’re only using Dify for a small set of secondary features, which doesn’t justify investing in a cloud-based or enterprise self-hosted license. Due to the nature of the issue, however, we’re blocked from making further progress with the tool. This leaves us with two (very limited) options:
  • Continue using the outdated version a bit longer—until security concerns force us to replace or remove it—hoping a fix will be introduced.
  • Port all Dify-based features to custom implementations and gradually phase out Dify altogether.

Additional context
none

Originally created by @dimitrisalo on GitHub (Jul 10, 2025). **Self Checks** To make sure we get to you in time, please check the following :) - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify-plugin-daemon/issues), including closed ones. - [x] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [ ] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:) - [x] "Please do not modify this template :) and fill in all the required fields." **Is your feature request related to a problem? Please describe.** We are currently using Dify version 0.15.0 for our production workloads (deployed in our production Kubernetes cluster). Since this version is already significantly outdated, we would like to upgrade to the latest available version. Unfortunately, we are blocked by the [Kubernetes scale-out limitations](https://github.com/langgenius/dify-plugin-daemon/blob/33c023b37507cfc9f179d4bffbaebf70b7a00664/README.md?plain=1#L75-L77) that the plugin-daemon currently faces. **Describe the solution you'd like** - **At the very least**, we would appreciate a mitigation path that allows us to continue using our production Kubernetes-deployed Dify installation. Currently, our only viable alternative seems to be replacing Dify entirely. While we don’t yet have enough user adoption to justify migrating to the cloud-based Dify solution, we anticipate this will change as we develop more features. - **Ideally**, we would like to see an implementation that supports Kubernetes deployments with scale-out capability. - Regardless of which of the above is feasible, we would like to understand the underlying issue and its root cause. This would help us evaluate whether it makes sense to contribute resources toward a solution for the community edition. A better documentation of the issue would very helpful on this area. **Describe alternatives you've considered** - Currently, we’re only using Dify for a small set of secondary features, which doesn’t justify investing in a cloud-based or enterprise self-hosted license. Due to the nature of the issue, however, we’re blocked from making further progress with the tool. This leaves us with two (very limited) options: - Continue using the outdated version a bit longer—until security concerns force us to replace or remove it—hoping a fix will be introduced. - Port all Dify-based features to custom implementations and gradually phase out Dify altogether. **Additional context** _none_
yindo commented 2026-02-16 00:20:13 -05:00
Author
Owner
Copy Link
Copy Source

@zengruizhao commented on GitHub (Sep 23, 2025):

It clearly has a clustering mechanism to ensure multi-instance expansion, but I don't know why it says in the README that it is not supported.

@zengruizhao commented on GitHub (Sep 23, 2025): It clearly has a clustering mechanism to ensure multi-instance expansion, but I don't know why it says in the README that it is not supported.
yindo commented 2026-02-16 00:20:13 -05:00
Author
Owner
Copy Link
Copy Source

@zengruizhao commented on GitHub (Sep 24, 2025):

It clearly has a clustering mechanism to ensure multi-instance expansion, but I don't know why it says in the README that it is not supported.

I understand what the official means. It supports scale out, but not smooth

@zengruizhao commented on GitHub (Sep 24, 2025): > It clearly has a clustering mechanism to ensure multi-instance expansion, but I don't know why it says in the README that it is not supported. I understand what the official means. It supports scale out, but not smooth
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Windows
bug
cmd
documentation
enhancement
go
good first issue
plugin-daemon
pull-request
Mirrored from GitHub Pull Request
 question
No Label
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-plugin-daemon#159
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?