# dify-helm puts eleven Dify workloads behind one nginx proxy > BorisPolonsky/dify-helm is a Helm chart that deploys langgenius/dify on Kubernetes with eleven components, thirteen nginx routing rules and support for Redis, two databases, seven object stores and eight vector stores. Four of its images are tagged latest, and the chart release version does not match the images it ships. **BorisPolonsky/dify-helm** — Deploy langgenious/dify, an LLM based app on kubernetes with helm chart. - Repository: https://github.com/BorisPolonsky/dify-helm - Stars: 676 · Forks: 189 - Language: Go Template - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/borispolonsky-dify-helm ## One image backs four workloads on port 5001 The component table has eleven rows but only eight distinct images, and the reuse is deliberate. langgenius/dify-api:1.17.0 appears four times: as the API, a RESTful server doing business logic on port 5001; as the API WebSocket, a Socket.IO process on the same port 5001 for workflow collaboration; as the Worker, background task processing through Celery; and as Beat, the periodic task scheduler through Celery Beat. The frontend is separate, langgenius/dify-web:1.17.0 on port 3000. Three agent-related services sit alongside them: dify-sandbox:0.2.15 as the secure code execution environment on 8194, dify-agent-backend:1.17.0 for agent run orchestration on 5050, and dify-agent-local-sandbox:1.17.0 for agent shellctl execution on 5004. That reuse is why upgrading is simple and why a resource limit set too low on one image can starve four different roles. ## The proxy and the SSRF proxy both track latest Two components in that table are not version pinned at all. The reverse proxy is nginx:latest on port 80, described as handling reverse proxying and load balancing, and the external request security proxy is ubuntu/squid:latest on port 3128. Squid is the interesting one for security review: its role is to be the egress path for outbound requests from Dify, which means it is the component that decides what the platform can reach, and it is the one moving when a tag moves. Two more images are pinned to versions that are not the Dify release either: the sandbox sits at 0.2.15 and the plugin daemon, which handles plugin management and execution on ports 5002 and 5003, is pinned to 0.6.10-local, a build suffixed for local use. So of eight images, two float with latest and two carry versions from a different numbering line than the chart itself. ## Thirteen routes, and one of them leaves the cluster All external traffic lands on the nginx proxy, and the routing rules are written out explicitly rather than left to defaults: ```nginx /console/api → API Service (5001) /api → API Service (5001) /v1 → API Service (5001) /files → API Service (5001) /openapi → API Service (5001) /explore → Web Service (3000) /e/ → Plugin Daemon (5002) /marketplace → External Marketplace API /mcp → API Service (5001) /triggers → API Service (5001) /socket.io/ → API WebSocket Service (5001) /agent-stub → Agent Backend Service (5050) / → Web Service (3000) [Default Route] ``` Eight of the thirteen go to the API on 5001, including the console API, the versioned v1 path, files, openapi, mcp, triggers and the Socket.IO prefix used by workflow collaboration. Two serve the web frontend on 3000, with / as the default route. One goes to the plugin daemon on 5002 and one to the agent backend on 5050. The twelfth rule, /marketplace, is the exception: it points at an external marketplace API rather than at any service in the chart. ## The chart says 0.39.0 and the images say 1.17.0 Release tags in this repository track the upstream application rather than the chart. The three most recent are dify-0.38.0-rc2 on 11 August 2026, dify-0.38.0 on 26 August, and dify-0.39.0-rc1 on 28 August, so a release candidate for the next minor arrives after the stable of the previous one and the naming carries the rc suffix through. The gap to watch is between that version line and the container tags: the chart release is 0.39.0-rc1 while the images it deploys are langgenius/dify-api:1.17.0, dify-web:1.17.0, dify-agent-backend:1.17.0 and dify-agent-local-sandbox:1.17.0. Nothing in the repository reconciles the two numbering schemes, so the release name tells you which chart build you installed and the image tags tell you which Dify you actually run. The last commit to the repository was 3 September 2026, and the project publishes no homepage beyond the chart repository URL. ## Two version floors and three Helm commands The whole documented install is short enough to memorise. The prerequisites are Kubernetes 1.23 or newer and Helm 3.12 or newer, and the quick path is three commands: ```shell helm repo add dify https://borispolonsky.github.io/dify-helm helm repo update helm install my-release dify/dify ``` The chart is served from a GitHub Pages URL rather than from a packaged registry index, and the release name in the example is arbitrary, so my-release is a placeholder for whatever you want to call the instance. That example installs defaults and nothing else: there is no values walkthrough in the top-level file, and customisation is delegated to the chart's own README at charts/dify/README.md in the master branch. Two release badges point at a GitHub Actions release workflow and at an Artifact Hub package listing, which is where you would look for published versions rather than guessing at a chart version. ## Seven object stores and eight vector stores The supported external components are the part that decides whether the chart fits your infrastructure, and they are grouped by role. Redis is supported in standalone and Sentinel modes. For the database, an external PostgreSQL or MySQL can be used instead of the bundled one. Object storage covers seven providers: Amazon S3, Microsoft Azure Blob Storage, Alibaba Cloud OSS, Google Cloud Storage, Tencent Cloud COS, Huawei Cloud OBS and Volcengine TOS. External vector databases list eight: Weaviate, Qdrant, Milvus, PGVector, Tencent Vector DB, MyScaleDB, TableStore and Elasticsearch. All of these are marked as supported rather than planned, so the chart can be pointed at existing infrastructure on any of those clouds. What the top-level file does not do is say which values keys set them, so the mapping from each provider to a values entry lives in the chart README and in the upstream Dify configuration conventions. ## The architecture diagram ends on an unfinished edge The network architecture section is a mermaid graph, and it is the one place in the documentation that stops mid-thought. The graph opens with a cluster ingress subgraph holding three entry points, a standard Ingress, a Gateway API object and a LoadBalancer service, with the internet feeding into that subgraph. From there it draws the proxy service on port 80 into a proxy pod running nginx:latest on port 80, then two labelled edges out of the pod, one to the API service on 5001 for API endpoints and one to the web service on 3000 for web pages. The final line of the graph is an edge from the proxy pod with an empty label after the arrow, so the topology as published stops before it reaches the remaining backends. The rest of the repository is tidier: an editorconfig, a ci directory, a ct.yaml for chart testing, a charts directory, and a contributors graph. ## Conclusion dify-helm is the shortest documented path to running Dify on a cluster you already operate, and its component and routing tables are specific enough to plan capacity and firewall rules against. Two cautions before you install. The proxy and the SSRF proxy are both pinned to latest tags, so a helm upgrade can change what runs without a version bump in your values. And the chart tag says 0.39.0 while the Dify images it deploys are 1.17.0, so read the image tags in the values rather than trusting the release number. For anything beyond the default, the chart's own README under charts/dify is the only customization documentation. ## FAQ ### What is Dify and what does it do? Dify is an LLM-based chatbot application, and this chart deploys the upstream langgenius/dify project onto Kubernetes. It runs an API server, a web frontend, Celery worker and scheduler processes, sandboxed code execution, an agent backend with its own local sandbox, a plugin daemon, plus an SSRF proxy and an nginx reverse proxy in front of them. ### Can Dify.AI be self-hosted? That is what this chart is for. It installs Dify into your own cluster with helm repo add dify https://borispolonsky.github.io/dify-helm followed by helm install, and it supports pointing the deployment at external infrastructure including Redis in standalone or Sentinel mode, PostgreSQL or MySQL, seven object storage providers and eight vector databases. ### What is Helm and what does the dify-helm install require? Helm is the package manager the chart is written for, and this chart needs Helm 3.12 or newer on Kubernetes 1.23 or newer. The chart repository is added from a GitHub Pages URL, then the release is installed by name with the chart reference dify/dify. ## Sources - [BorisPolonsky/dify-helm on GitHub](https://github.com/BorisPolonsky/dify-helm) - [Issues](https://github.com/BorisPolonsky/dify-helm/issues) - [License: MIT](https://github.com/BorisPolonsky/dify-helm/blob/master/LICENSE) - [README](https://github.com/BorisPolonsky/dify-helm/blob/master/README.md) - [Releases](https://github.com/BorisPolonsky/dify-helm/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/borispolonsky-dify-helm