Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Helm Chart Deployment values.yaml Key Parameters Explained: What Must Be Changed vs. What Can Stay Default

When deploying Dify Enterprise with Helm, values.yaml is the most critical configuration file. What truly affects deployment success rate and long-term operational cost is not having more parameters, but knowing which ones must be changed, which should be customized per environment, and which can temporarily remain at their defaults.

This point is already directly supported by the Enterprise official public documentation. The official Helm documentation explicitly recommends viewing configurable items via helm show values dify/dify, and provides configuration guidance around ingress, external Redis, persistence, License mode, and other key items. Additionally, the official team provides a values generator project, which indirectly indicates that values.yaml complexity has reached a level requiring dedicated tooling to assist generation. Therefore, categorizing values into “must change / change per environment / can keep default” is a very practical approach.

1. Key values Focus Areas Confirmed from Public Sources

1. values.yaml Is Indeed the Primary Control Surface for Helm Deployment

The public documentation uses helm upgrade -i dify -f values.yaml dify/dify as the standard installation method, meaning that deployment differences in production environments will essentially all be captured in values.

2. Official Focus Areas Primarily Center on Domain, Storage, External Dependencies, and License

From the Helm documentation, Kubernetes documentation, and License activation documentation, the most critical parameter categories are clearly:

  • ingress / domain
  • persistence
  • external database / redis / vector store
  • enterprise licenseMode
  • resource settings

3. A Single values File Should Not Be the Only Version

While official documentation mostly discusses a single values file, from production practice and public examples, at least dev / staging / prod configurations should be separated to avoid carrying test parameters directly into production.

2. Parameters That Should Be Changed First

1. Domain and Ingress Configuration

The domains and entry points for console, api, app, upload, enterprise, trigger, and others should be explicitly configured.

2. Secrets and Internal Communication Keys

Including app secret, inner API key, and similar values — production environments must use strong random values and should not reuse example defaults.

3. Storage Configuration

Object storage, database, Redis, and vector store external connection information should be rewritten according to the actual infrastructure.

4. Enterprise License Mode

If using offline activation, licenseMode must be explicitly adjusted in values.

5. Resource requests / limits

Production environments should explicitly define these based on concurrency and node types. Long-term reliance on defaults is not recommended.

3. Parameters That Depend on the Environment

  • Replica count
  • Log retention and monitoring configuration
  • Whether to enable external Redis / external PostgreSQL / external vector store
  • Sandbox network policy
  • SMTP and SSO configuration

4. Parameters That Can Initially Stay at Default

  • Non-critical experimental toggles
  • Plugin-related configurations that are not yet enabled
  • Storage parameters unrelated to the currently integrated cloud provider

5. Version Management Recommendations

values.yaml should be managed in a dedicated configuration repository, with at least these variants:

  • dev
  • staging
  • prod

6. Conclusion

For Helm deployment, what truly matters is not “understanding every single parameter,” but first identifying the core items that affect domain, secrets, storage, resources, and License.

Public Source References

note.com

  • No particularly strong directly matching note.com articles at this time. The current basis relies more on Enterprise official Helm documentation.

zenn.dev / Official Documentation / Other Public Pages

  • Dify Helm Chart - Dify Enterprise Docs | https://enterprise-docs.dify.ai/en-us/deployment/advanced-configuration/dify-helm-chart
  • Kubernetes - Dify Enterprise Docs | https://enterprise-docs.dify.ai/en-us/deployment/prerequisites/kubernetes
  • License Activation - Dify Enterprise Docs | https://enterprise-docs.dify.ai/versions/3-0-x/en-us/deployment/license-activation
  • langgenius/dify-ee-helm-chart-values-generator | https://github.com/langgenius/dify-ee-helm-chart-values-generator

Verified Information from Public Sources for This Article

  • values.yaml is the core configuration surface for Enterprise Helm deployment
  • Official focus areas center on ingress, storage, external dependencies, resources, and License mode
  • The values complexity has reached a level requiring a dedicated generator tool to assist management