Skip to content

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

@dimitrisalo

Description

@dimitrisalo

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions