Skip to content

Home

Jump to bottom
Hamza Masood edited this page Dec 8, 2025 · 15 revisions

Camunda Helm chart repo wiki

This page targets the wiki related to Camunda Helm chart internals.

Topics

Purpose of the Camunda Helm Chart

The Camunda Helm Chart serves as the primary deployment mechanism for running Camunda 8 on Kubernetes. It's purpose is to abstract the complexity of Kubernetes manifests and Camunda’s internal components, enabling users to perform installations and deployments with minimal Kubernetes expertise.

The Helm chart provide a simple, reliable, and consistent way to configure and deploy Camunda while exposing only the most essential and commonly used configuration parameters.

Guiding Principles of the Camunda Helm Chart

The Helm Charts are designed with the following principles:

  • Expose configuration options that are common, minimal, and useful, maintaining a balance between simplicity and flexibility.
  • Ensure each exposed configuration or feature results from a conscious, user-driven decision, validated by product management.
  • Allow users to define specific or advanced configuration in a clear, extensible, and generic manner outside of the chart defaults.
  • Maintain a 1:1 mapping between application configuration and Helm values, wherever possible.
  • Establish reasonable defaults and facilitate configuration of common deployment scenarios, avoiding unnecessary complexity.

What the Camunda Helm Chart is NOT

The Helm Charts have defined boundaries to maintain clarity, consistency, and long-term maintainability. They are not intended to:

  • Expose arbitrary or exhaustive Camunda application configuration.
  • Implement or promote opinionated solutions from individual engineers. Instead, they should provide generic and composable mechanisms that enable flexible and pluggable architectures.
    • For example, they should not embed opinionated choices for monitoring, security, or identity management solutions. The charts should remain extensible through community and external tooling such as the Vertical Pod Autoscaler (VPA), security plugins, or GitOps integrations.
  • Bundle or depend on external components that are not part of Camunda’s core product (e.g. OpenSearch, Bitnami-based dependencies).
  • Abstract away or bypass the intrinsic complexity of Camunda’s architecture or its operational model.
  • Serve as a mechanism to patch, override, or work around application-level issues or technical debt.
  • Modify or override core application defaults unless a change aligns with Camunda’s default behavior or best practices.

Release Lifecycle

Please refer to our Release Policy to learn about our release cadence, maintenance periods, etc.

Clone this wiki locally