When Dify Enterprise on Kubernetes fits your platform
A platform team that must run Dify for several business units, keep it available during node failures and sign users in through the corporate identity provider needs more than the Community edition offers. The Community Docker Compose stack runs on a single host and supports a single workspace, so high availability, SSO and multi-workspace management are the reasons to look at Dify Enterprise on Kubernetes. The Enterprise Helm chart deploys the Dify services into a cluster you control, and the platform team keeps ownership of the nodes, networking, storage and the external databases they connect to.
Before you plan around the chart, confirm your cluster meets the minimums in the Enterprise resources checklist: Kubernetes 1.24 or later and Helm 3.14 or later, along with PostgreSQL 14 or later, Redis 6 or later, a Qdrant vector database and S3-compatible or cloud object storage. Check these against the chart version you intend to install, because the checklist is the reference for the release you are deploying. Also confirm with Dify which Enterprise release and licence terms apply to your organization, since Enterprise is a commercial, custom-priced edition and its access is arranged through Dify rather than the public download.
Docker Compose remains the better fit when one team runs a single workspace for testing, a proof of concept, or a small internal group that does not need SSO or multi-workspace separation. It is also simpler when your organization has no Kubernetes operating model yet, because the Helm route adds cluster upgrades, ingress, secrets management and external data services to your run book. If you choose Compose for production, the reader should plan for the single-host recovery model; if you choose Kubernetes, plan the platform capacity and ownership before the first install.
Which services to run outside the cluster and which to size first
This table compares the stateful dependencies Dify Enterprise expects on Kubernetes, the decision each one drives and what to confirm before you commit. Read it as a sequence: fix the supported versions and storage backends first, then size the components that carry the most load. Most teams decide early whether PostgreSQL, Redis, Qdrant and object storage are provided by the cluster or by services you already operate.
| Component | Requirement or option | Decision it drives | What to confirm |
|---|---|---|---|
| PostgreSQL | 14 or later | Whether metadata runs on a managed or clustered instance you back up, instead of an in-cluster database | Exact supported minor versions, connection limits and TLS settings in the Enterprise resources checklist |
| Redis | 6 or later | Whether cache and task queue state sit on a service with its own availability and failover design | Required deployment mode, TLS and ACL options, and whether a shared instance is allowed |
| Qdrant | Vector database required by the Enterprise checklist | Whether retrieval runs on a dedicated cluster sized separately from the application nodes | Cluster topology the checklist expects, storage class requirements and backup method |
| Object storage | S3-compatible or cloud object storage | Where uploads, dataset documents and related files are kept, and which bucket and access policy the chart uses | Supported storage types in the Helm values and whether on-premises S3-compatible services are validated |
| Metadata database options | PostgreSQL (default), MySQL or OceanBase in the Community environment reference | Whether your standard database engine is an acceptable choice for Dify metadata | Whether the Enterprise chart supports each option or only PostgreSQL |
| Vector store options | Weaviate by default, with Qdrant, Milvus, pgvector, OpenSearch and Elasticsearch documented | Whether Qdrant is the single vector backend or one of several options you run | Which vector stores the Enterprise release supports for production |
| Application nodes | Production example uses six worker nodes with 8 CPUs and 32 GB of RAM each | How much capacity the cluster needs for application workloads once dependencies sit outside it | Whether the example fits your workload, and the testing profile for pre-production environments |
What each external dependency must provide before the install
The Dify Enterprise chart runs on infrastructure your team supplies. Each dependency below needs a version floor, a sizing decision and a set of operational owners before the first helm install. Confirm the exact minimums against the chart release notes for the version you deploy, since the supplied resources checklist sets the floor for the release it documents.
Kubernetes cluster version
The Enterprise resources checklist requires Kubernetes 1.24 or later. The chart schedules the api, worker, web and plugin components across nodes, so the cluster needs enough schedulable capacity for the production profile, which the checklist describes as six worker nodes with 8 CPUs and 32 GB of RAM each. Confirm node pool sizing, ingress class, storage class and whether your distribution's admission policies allow the chart's security context. Ask Dify for the version matrix that matches your chart release.
Helm client version
The checklist requires Helm 3.14 or later on the machine that runs the install and upgrade commands. Helm stores release state in the cluster, so pin the client version in your deployment pipeline and record it with each release. Confirm that the chart values file you use is the one shipped for your Dify Enterprise release, because value keys change between chart versions and an upgrade with stale values can silently drop settings.
PostgreSQL metadata database
PostgreSQL 14 or later holds application metadata, workflow definitions and account records. The chart points at it through external connection settings, so the database is a service you operate, not a container the chart manages. Prepare a dedicated database and role, TLS for connections, a connection limit that covers api and worker replicas, and point-in-time recovery with a restore test. Confirm with the chart notes which databases must exist before the first install, since missing ones fail startup.
Redis broker and cache
Redis 6 or later carries Celery task queues and cached state between the api and worker pods. Losing it interrupts queued indexing and workflow jobs, so decide whether a managed service with failover meets your recovery targets or whether Sentinel or Cluster mode is needed. Prepare a password or ACL user, TLS if the traffic leaves the node network, and a separate logical database for the broker where your chart version expects one. Confirm eviction policy settings, because an aggressive policy can drop queued tasks.
Qdrant vector cluster
Qdrant stores vector indexes for knowledge bases, and the checklist's production example uses a three-node Qdrant cluster. Index size grows with the documents you ingest and the embedding model's dimensions, so size storage from your corpus, not from the chart defaults. Prepare persistent volumes, an API key, TLS and a snapshot schedule, and confirm that the chart's Qdrant connection settings match your cluster endpoint and collection naming. Test restore from snapshot before go-live.
S3-compatible object storage
Object storage holds uploaded files, dataset documents and related artifacts that the chart does not keep in the cluster. The checklist accepts S3-compatible or cloud object storage. Prepare a bucket per environment, an access key scoped to that bucket, versioning or lifecycle rules for your retention policy, and a network path from the worker and api pods. Confirm the endpoint and region format your chart version expects, and whether path-style addressing is required for your storage product.
Installing Dify Enterprise with Helm in the right order
This sequence takes a cluster from version checks to a running Dify Enterprise release that uses external PostgreSQL, Redis, Qdrant and object storage, with each dependency confirmed before the chart is installed.
Confirm cluster and Helm versions
The platform team checks that the Kubernetes cluster is version 1.24 or later and that the Helm client is version 3.14 or later, using the values in the Dify Enterprise resources checklist. Confirm that the cluster has enough worker nodes and capacity for the profile you plan to run, and that the target namespace can pull images from your registry. Done means the version output from both tools is recorded in your change ticket and a test pod can schedule and pull an image.
Provision PostgreSQL, Redis, Qdrant and object storage
Before touching the chart, stand up the four external services the Enterprise deployment expects: PostgreSQL 14 or later, Redis 6 or later, a Qdrant vector database and S3-compatible or cloud object storage. The checklist also describes a three-node Qdrant cluster in its production example, so confirm the topology with your database and storage owners. Record hostnames, ports, TLS requirements and bucket names. Done means each service accepts a connection from a debug pod inside the cluster network.
Create namespaces and generate secrets
Create the Dify namespace and store credentials for PostgreSQL, Redis, Qdrant and object storage as Kubernetes secrets, not in values files committed to source control. Generate SECRET_KEY once, store it in your secrets manager, and keep it unchanged for the life of the installation, because the environment reference says changing it after deployment logs out all users and affects encrypted OAuth credentials. Done means the secrets exist in the namespace, and the team has a documented, access-controlled copy of SECRET_KEY outside the cluster.
Set chart values for external services
Write a values file that disables any bundled database or cache the chart would otherwise start, and points the api, worker and plugin components at your external endpoints using the secret references from the previous step. Set the public URL variables to the hostname users will reach, and confirm the outbound proxy settings for SSRF filtering match your network policy. Render the chart with a template or dry-run command and review the output. Done means the rendered manifests contain no default passwords and every external address matches your inventory.
Install the Helm release
Install the chart from the official Dify Enterprise source into the prepared namespace, using the reviewed values file and a pinned chart version rather than the latest tag. Watch the rollout until the deployments report ready, and capture any events that show image pull errors, failed migrations or missing secrets. Done means the release status shows deployed and the database migration job has completed without errors in its logs.
Verify pod health and service connectivity
Check that every pod is running and that health probes pass, then confirm from inside the cluster that the api and worker reach PostgreSQL, Redis and Qdrant, and that uploads reach the object storage bucket. Review logs for connection refusals or certificate errors on each dependency. Done means a test upload to a knowledge base completes and the vector index for it is written to Qdrant, which proves the storage and vector paths work end to end.
Confirm SSO and first login
Configure one identity provider using the protocol your organization standardizes on, such as OpenID Connect, SAML or OAuth2, and confirm that the SSO documentation's workspace access scope matches your intended roles. Sign in with a test account that is not an administrator and then with an administrator account. Done means both logins succeed, the expected workspace appears, and a denied user without the right group membership is refused. Record the result in your deployment runbook before any business users are invited.
Testing versus production resources and the OpenShift differences
Testing profiles let a team prove that the chart installs, that all six domains start and that integrations work before committing production capacity. This guide does not fix testing sizes. Take the testing values from the Enterprise resources checklist for the exact Dify Enterprise version you plan to run, because requirements can change between releases.
- Node count: A test cluster can run fewer nodes than production, but confirm the scheduler can place every workload the chart creates, including Qdrant and any in-cluster database pods.
- Dependency choice: Use in-cluster PostgreSQL, Redis, Qdrant or object storage only if your policy allows it, and label those components as throwaway so they are not promoted by accident.
- Data: Load synthetic documents and non-production model credentials. A test cluster that holds real knowledge bases tends to become a production system in practice.
- Version pinning: Record the chart and image versions you tested so the production install uses the same combination.
Before you treat the test results as valid, confirm that the test cluster meets the Kubernetes 1.24 or later and Helm 3.14 or later minimums.
The supplied production example in the Enterprise resources checklist uses six worker nodes with 8 CPUs and 32 GB of RAM each, plus a three-node Qdrant cluster. Use it as a planning reference. Actual capacity depends on indexing volume, number of workspaces and concurrent workflow runs, so measure those during testing and size from the results.
- Worker capacity: Plan spare capacity so that a node failure or rolling upgrade does not push the remaining workers below the load they must carry.
- Qdrant cluster: Run the vector database on nodes or storage separate from the application pods, so index growth does not compete with API and worker resources.
- External services: The checklist requires PostgreSQL 14 or later, Redis 6 or later and S3-compatible or cloud object storage. You own their sizing, high availability and backups outside the chart's lifecycle.
- Failure domains: Spread nodes across failure domains your infrastructure supports, and confirm with your platform team how those domains map to the cluster.
- Quote scope: Ask the vendor to state in writing which sizing applies to your expected knowledge base volume and concurrency.
Before procurement, compare the production example with your own test measurements and record every gap as a scope item.
OpenShift enforces its own security context constraints, and pods that install cleanly on a generic Kubernetes cluster may need permissions that OpenShift does not grant by default. Root or security context requirements therefore differ from standard Kubernetes, and a chart that works on one platform should not be assumed to run unchanged on the other. Confirm the chart documentation and your cluster's security policy before the first install.
- Container user: Determine whether the chart's containers run as root or as a fixed non-root user, and whether the UID ranges OpenShift assigns to projects allow that user.
- Security context constraints: Identify which constraint the chart's service accounts would need, and get platform security approval for any elevated permission in writing.
- Storage and volumes: Check that persistent volume claims, storage classes and group ownership settings work with the volumes OpenShift provisions for your projects.
- Ingress and routes: Confirm whether the chart's ingress objects are supported directly or need an adaptation step in your environment.
- Exceptions: Record every policy exception with its owner, justification and review date.
Run the chart's pre-install checks in a non-production OpenShift project and keep the security findings before you request production change approval.
Keeping the release current after the first install
Upgrading an Enterprise Helm release is not the same job as pulling newer images in Compose. In the Compose path, the Dify docs tell operators to read the upgrade guide for the target version on the GitHub Releases page, take a backup before every upgrade and check .env.example for new variables. Those same concerns carry over to the cluster, where the new variables live in the chart values and the Secret objects that feed them. Minor releases arrive roughly monthly: 1.16.0 on July 17, 2026, 1.17.0 on August 25, 2026 and 1.17.1 on September 10, 2026. At that cadence, an install that is not on a schedule will fall behind quickly, and a long gap makes each jump harder to review.
Set up three things before the first upgrade. First, a non-production cluster or namespace that mirrors the production values, external PostgreSQL, Redis, Qdrant and object storage settings, so each target version is exercised before it reaches users. Second, pin the chart to a specific version in your deployment tooling rather than tracking the latest chart, and record which Dify application version that chart deploys. Third, name one owner who reads the release notes for each version in the upgrade window, including the security changes, and who signs off on the values diff. Release notes for 1.16.1 described agent sandbox network isolation through a Squid proxy, token-based API authentication between services and sandboxed Jinja2 template rendering, so changes like these can alter behavior that your tests must cover.
The Enterprise upgrade procedure is not described in the sources used for this page, so confirm the exact steps, chart compatibility, database migration behavior and rollback path in the Enterprise documentation before you schedule a change. Ask the vendor which chart versions support upgrades from your current release, whether a direct jump is allowed across several minor versions, and what backup scope they expect for the database and object storage. Plan for the SECRET_KEY value to remain unchanged across upgrades, because changing it logs out all users, and confirm that your secret store keeps it intact.
Security controls to set during the Kubernetes install
Several of these controls are decided at install time, when the Helm values are written, and they are hard to change later without disruption. Together they cover how Dify signs and encrypts, which outbound and inter-service traffic is trusted, where keys live and how people sign in.
SECRET_KEY management
Changing SECRET_KEY after deployment logs out every user. It signs session cookies and JWTs and encrypts OAuth credentials, so the value should be generated once, stored in your secret manager and fed into the chart from there. Confirm how the chart reads it, that it is not committed to values files in Git, and who holds the recovery copy.
SSRF proxy for outbound requests
The SSRF_PROXY settings route outbound requests through a proxy that blocks internal and private IP ranges. This limits what a workflow HTTP node or tool can reach from inside your cluster, such as metadata endpoints or internal databases. Confirm the proxy is enabled in your values, and test that a request to a private address fails.
Workspace key storage options
Workspace encryption keys can be stored locally or in Azure Key Vault. Local storage keeps the operational footprint small but puts key custody inside the cluster, while Key Vault moves custody to a service you already audit. Decide this before creating workspaces, and confirm how key backup and rotation are handled for the option you choose.
Token-based service authentication
Dify 1.16.1 added token-based API authentication between its services. Confirm your Enterprise release includes this change and that the chart version you deploy carries it, since internal service calls are the path an attacker inside the cluster would try to reach. Record the version in your change log so auditors can match it to the release notes.
Sandbox network isolation
Dify 1.16.1 routes agent sandbox traffic through a Squid proxy for network isolation. Pair this with Kubernetes network policies that deny sandbox pods access to cluster services and internal ranges. Confirm with your platform team which egress destinations are allowed and verify the policy blocks anything else.
SSO protocol and scope choices
Dify Enterprise SSO supports OpenID Connect, SAML and OAuth2, with identity providers such as Microsoft Entra ID, Okta and GitHub. Separate scopes control workspace access and web app access, so decide them independently. Confirm the protocol your identity provider supports, and plan group mapping before go-live.
Questions buyers ask before installing Dify Enterprise on Kubernetes
What does the effort of installing Dify Enterprise on Kubernetes depend on?
The effort depends mostly on how ready your cluster and data services are, not on the chart itself. The published resources checklist requires Kubernetes 1.24 or later, Helm 3.14 or later, PostgreSQL 14 or later, Redis 6 or later, a Qdrant vector database and S3-compatible or cloud object storage. Teams that already run those components in a supported state move quickly. Teams that must build them first, or that need a production profile sized to the checklist's example of six worker nodes with 8 CPUs and 32 GB of RAM each plus a three-node Qdrant cluster, carry more work. Identity integration, network policy, and how many workspaces and environments you need also change the effort.
Can our internal platform team install Dify Enterprise without a partner?
Often yes, if the team already operates Kubernetes, Helm releases, PostgreSQL and object storage in production and has an owner for the Dify application itself. The harder parts are usually outside the chart: configuring external PostgreSQL, Redis, Qdrant and object storage, wiring SSO, handling TLS, and setting SECRET_KEY and other secrets so they are stored and rotated safely. Check whether your team has capacity for upgrades, since Dify ships minor releases roughly monthly, so the install is the start of an ongoing maintenance load. Confirm your Enterprise license and support path with Dify before you commit.
What does a fixed-scope engagement from DeployOpen cover?
A fixed-scope engagement covers the work agreed in writing before it starts. Typical items for this topic include planning the cluster layout against the resources checklist, installing the Helm release, connecting external PostgreSQL, Redis, Qdrant and object storage, configuring the identity provider, documenting the configuration and running acceptance checks. Scope, deliverables and timelines are fixed in that document, and changes are handled through a written change request. Items outside the agreed scope, such as building custom plugins or moving existing applications, need their own scope. DeployOpen does not publish a price list, so the quote follows from the written scope.
What must we provide before the installation starts?
You need to provide working access, and the decisions only your organization can make. Expect to provide:
- Kubernetes cluster access with a namespace, storage classes and network policy approved by your platform team
- Managed or clustered PostgreSQL 14 or later, Redis 6 or later, a Qdrant deployment, and S3-compatible or cloud object storage
- An identity provider such as Microsoft Entra ID, Okta or another OpenID Connect, SAML or OAuth2 provider, with administrator rights to register the application
- TLS certificates for public hostnames and the internal certificate authority trust your cluster needs
Confirm the exact requirements for your Dify Enterprise version in the resources checklist before procurement.
How long does the installation take, and what drives that duration?
No duration can be stated here without a written scope, because it depends on what you provide and what is in scope. The biggest drivers are the readiness of your data services, the number of environments (testing and production are sized differently), how long identity and certificate approvals take inside your organization, and how many workspaces and workloads you migrate. Ask any partner for a timeline tied to named dependencies and the dates each client-side item is due, and ask which steps are blocked if an approval slips.
How does the Dify license relate to the Enterprise edition?
The Community edition is free and limited to a single workspace under the Dify Open Source License, a modified Apache License 2.0. That license forbids operating the source code as a multi-tenant environment without written authorization and forbids removing or modifying the logo or copyright information in the console. Dify Enterprise adds SSO, multiple workspaces, advanced security, a commercial license and professional support. Its pricing is custom, so the cost of Enterprise is quoted from written scope and the Dify contract. Read the Dify pricing page and the LICENSE file before you decide which edition fits your use.
Is the Kubernetes install suitable for a regulated workload on day one?
Not by default. The chart gives you a highly available platform, but regulated use also needs secrets handling, outbound request controls, access reviews, backups tested by restore, logging, and evidence that your controls work. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, and independent auditors and certification bodies make that determination. Ask your partner which hardening and evidence items are in scope and which remain your responsibility.
Limits to confirm for your environment and chart version
The Enterprise chart and its supported platforms change with each release, so several details in this plan must be confirmed against the chart version you intend to deploy. The cards below list the questions to put to Dify and to check in the Enterprise documentation before a design is locked.
Six domains and ingress mapping
Confirm the current list of six domains the chart configures and the hostname each one expects. Ask how each domain maps to your ingress controller, which TLS certificates it needs, and whether the public URL variables must match each external hostname. Mismatched hostnames often surface first as broken login redirects or failed file uploads, so map every domain to a DNS record and certificate before testing begins.
Exact Enterprise version and Kubernetes range
Ask Dify which Enterprise release the chart package corresponds to and which Kubernetes versions that release supports. The public checklist sets minimum floors for Kubernetes and Helm, but a newer release may raise them or add upper bounds. Record the exact chart version, application version and cluster version together so that an upgrade can be planned against a known pairing.
Qdrant and object storage support
Confirm that your planned Qdrant topology and object storage product are supported by the chart version you select. Ask whether the chart expects an external Qdrant endpoint, whether a three-node cluster is the tested layout, and which S3-compatible implementations have been validated. Also ask how Qdrant API keys and bucket credentials are injected, since these choices determine your secret management and backup design.
OpenShift root requirements
If you run OpenShift, ask which containers in the chart need root or a specific user ID and whether those requirements can be met under your Security Context Constraints. Ask which service accounts need elevated permissions, and whether any requirement conflicts with your cluster policy on privileged workloads. Obtain the answer in writing before your security team approves the namespace design.
Workspace licensing scope
Confirm how the Enterprise license counts workspaces, tenants and environments, and whether separate staging and production installs need separate entitlements. The Community edition is limited to a single workspace, so verify how Enterprise multi-workspace use is measured. Ask for the license terms in writing, including what happens to workspaces created during a trial.
Enterprise support boundaries
Ask Dify which components are covered by professional support, including the chart, the bundled dependencies and any customizations, and which responsibilities stay with your team. Clarify who handles PostgreSQL, Redis, Qdrant and object storage incidents when those services run outside the chart. Agree on response channels and the process for upgrading between chart versions before go-live.
How DeployOpen scopes and delivers a Dify Enterprise Kubernetes install
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, and Dify Enterprise on Kubernetes is handled the same way. The work starts with a written scope that fixes what the Helm install covers, then moves through build, handover and an optional support arrangement.
How we scope
- Confirm Kubernetes and Helm versions against the Enterprise resources checklist before any install work begins.
- Agree in writing which of the six domains, external PostgreSQL, Redis, Qdrant and object storage are in the install.
- Define the testing and production resource profiles, and record which environment each one applies to.
How we build
- Deploy the official Helm chart into your cluster, with values files kept in your own version control.
- Connect external PostgreSQL, Redis, Qdrant and S3-compatible object storage, with secrets stored outside the chart values.
- Test SSO sign-in, workspace access, document ingestion and backup restore before the environment is accepted.
How we hand over
- Provide runbooks for install, upgrade, scaling, backup and restore, written for your platform team.
- Document the OpenShift root requirements and any security context settings if your cluster needs them.
- Walk your operators through the upgrade procedure so each release follows the same tested steps.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, separate from the initial fixed-scope work.
- Plan upgrades against each Dify release and its upgrade guide, with a backup taken before every change.
- Confirm with your team which support terms, response expectations and Enterprise license terms apply before signing.
