dify-helm: Running Dify on Kubernetes Without Writing the Manifests Yourself
Deploy langgenious/dify, an LLM based app on kubernetes with helm chart.
At a glance
- What is it?
- BorisPolonsky/dify-helm packages langgenius/dify, its worker, beat scheduler, plugin daemon, sandbox, agent backend, SSRF proxy and data layer into a single Helm chart. The chart is the value; the operational surface it exposes is the cost.
- Who is it for?
- Adopt dify-helm if you already run Kubernetes and want Dify's full service topology (api, worker, beat, web, plugin daemon, sandbox, SSRF proxy) expressed as one versioned release rather than a compose file. Do not adopt it if you have no cluster, no ingress controller and no intention of managing PVCs, or if you only want to evaluate Dify for an afternoon; the chart's own prerequisites start at Kubernetes 1.23 and Helm 3.12.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 13 days ago.
- What is it written in?
- Mainly Go Template, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap dify-helm fills between a Dify compose file and a production cluster
Dify is not one process. The chart's network diagram lists an API pod on port 5001, a web pod on port 3000, a worker pod, a beat pod for periodic scheduling, a plugin daemon on 5002 and 5003, a sandbox on 8194, an agent backend on 5050, a local sandbox on 5004, an SSRF proxy on 3128, plus PostgreSQL, Redis and a vector database. Anyone who has tried to move that from a docker-compose file to Kubernetes knows the work is not the containers. It is the Services, the wiring between them, the shared configuration, the storage class decisions and the upgrade path when upstream ships a new image tag. This chart exists to absorb that work. The audience is a platform or infrastructure engineer who already has a cluster and wants Dify as a release they can version, roll back and template, not as a set of YAML files copied from a blog post.
What the chart actually deploys: pods, ports and the routing layer
Traffic enters through one of three front doors the diagram names: an Ingress, a Gateway API resource, or a LoadBalancer. All three land on a proxy Service on port 80, which is backed by an nginx pod. The proxy is the router. It sends API endpoints to the API Service on 5001, web pages to the web Service on 3000, plugin routes to the plugin daemon on 5002, marketplace calls to an external marketplace API, and agent stub traffic to the agent backend on 5050. That design means the chart does not ask you to expose five separate hostnames; it asks you to expose one and let nginx fan out. Behind the proxy, the API pod and the worker pod share the same image (langgenius/dify-api in the diagram) but take different roles. The API pod handles code execution for non-streamed workflows and debugging; the worker handles streamed workflows. Both talk to the sandbox, both use the SSRF proxy before making outbound calls, and both invoke the plugin daemon. The beat pod does nothing but schedule periodic tasks through Redis. The agent backend has its own local sandbox for shell execution and calls back into the API for signed file URLs. This is a real topology, not a single-container wrapper, and the chart's job is to keep the wiring consistent across all of it.
Storage and vector database are the two decisions the chart pushes onto you
The diagram shows the API, worker and plugin daemon all reaching a storage type that branches four ways: a local PVC, AWS S3, Azure Blob or Google Cloud Storage. It shows the same three pods reaching a vector database service that branches into Weaviate on 8080, Qdrant on 6333, Milvus on 19530 or PGVector on 5432. It also shows a parallel column of external dependencies: an external PostgreSQL or MySQL, an external Redis, an external vector database, external object storage and an external E2B sandbox, all marked as alternatives to the bundled versions. This is where the chart stops being a one-command install and becomes a configuration exercise. A local PVC is the fastest path to a running instance and the worst path to a rescheduled pod, because the data does not follow the pod. Choosing PGVector collapses the vector store into the Postgres you may already be running, which removes one service but couples vector search to your relational database's capacity. The chart does not decide for you, and the documentation does not appear to rank these options, so the choice is yours to defend.
Installing it: three commands, then the values file
The README's TL;DR is three lines. helm repo add dify https://borispolonsky.github.io/dify-helm, then helm repo update, then helm install my-release dify/dify. That gets you a release with the chart's defaults. Everything past that lives in charts/dify/README.md, which the top-level README points to for customized installation. The prerequisites are stated plainly: Kubernetes 1.23 or newer and Helm 3.12 or newer. Two operational notes follow from the repository layout. First, the chart is published to GitHub Pages and indexed on Artifact Hub, so helm repo add is the supported consumption path; cloning the repository and installing from a local path is possible but puts you on master rather than a released version. Second, the releases listed for this project are chart versions (dify-0.38.0, dify-0.39.0-rc1) that carry upstream image tags inside them. Pinning the chart version pins the application version with it, which is the behaviour you want and also the behaviour that makes upgrades a deliberate act rather than a side effect of helm repo update.
Where the chart is the wrong tool
The honest limitation is that this chart is a Kubernetes artifact and inherits every Kubernetes prerequisite. If your team does not run a cluster, does not have an ingress controller or Gateway API implementation installed, and has no story for PersistentVolumeClaims, the chart will not simplify anything; it will add a control plane you now have to operate. The same applies to evaluation. If you want to see whether Dify fits your use case, standing up ten pods, a Postgres, a Redis and a vector database is a heavy way to find out. The second limitation is version coupling. Because the chart bundles upstream image tags, a chart upgrade can move the application version underneath you, and the release list shows release candidates (dify-0.39.0-rc1, dify-0.38.0-rc2) published alongside stable versions. Tracking master or installing an rc in a shared cluster is a choice you make knowingly. Third, the chart's defaults are a starting point, not a production posture: the storage and vector database branches in the diagram are decisions the chart exposes but does not make for you, and a default local PVC is a single point of data loss if the pod is rescheduled.
How this differs from running Dify with Docker Compose
The upstream project's most common self-hosting path is Docker Compose, and the difference is not cosmetic. Compose gives you containers on one host with a shared network and bind mounts; the chart gives you pods, Services, a proxy layer and PVCs spread across a cluster. Compose has no notion of a rolling update that keeps the API serving while the worker restarts, no resource requests and limits per component, and no built-in path to an object storage backend for file uploads. The chart's diagram shows S3, Azure Blob and GCS as first-class storage options alongside the local PVC, which is the difference between a single-host deployment and one that survives losing a node. The trade is operational surface. Compose is one file and one command; the chart is a release you upgrade, values you maintain per environment, and a cluster you already know how to run. If you have the cluster, the chart removes work. If you do not, Compose is the smaller commitment and the chart is overhead.
Maintenance cost, release cadence and the MIT licence
The repository is active: the last push is dated 2026-09-03, and the recent release list shows 0.38.0 in late August 2026 with 0.39.0-rc1 days later. That cadence is a maintenance signal in both directions. You get upstream Dify changes relatively quickly, and you also get a stream of chart versions to evaluate, including release candidates. Budget for reading the chart's changelog before each upgrade, because the image tags move with the chart version. The licence is MIT, which is permissive and places few obligations on how you use or redistribute the chart; it says nothing about the licences of the container images the chart pulls, which come from langgenius/dify and its related repositories and are governed separately. Check those before you ship anything commercial. This is not legal advice; read the licence files that ship with the images you deploy.
Editorial conclusion
Adopt dify-helm if you already run Kubernetes and want Dify's full service topology (api, worker, beat, web, plugin daemon, sandbox, SSRF proxy) expressed as one versioned release rather than a compose file. Do not adopt it if you have no cluster, no ingress controller and no intention of managing PVCs, or if you only want to evaluate Dify for an afternoon; the chart's own prerequisites start at Kubernetes 1.23 and Helm 3.12. Before installing, read charts/dify/README.md for the values that matter to you (storage type, vector database, external versus bundled Postgres and Redis), pin the chart version rather than tracking master, and confirm which image tags the release you pick actually references.
Community notes