When working seriously with Helm in production environments, one of the less-discussed but highly impactful topics is how Helm stores and manages release state. This is where Helm drivers come into play. Understanding Helm drivers is not just an academic exercise; it directly affects security, scalability, troubleshooting, and even disaster recovery strategies.
What Helm Drivers Are and How They Are Configured
A Helm driver defines the backend storage mechanism Helm uses to persist release information such as manifests, values, and revision history. Every Helm release has state, and that state must live somewhere. The driver determines where and how this data is stored.
Helm drivers are configured using the HELM_DRIVER environment variable. If the variable is not explicitly set, Helm defaults to using Kubernetes Secrets.
export HELM_DRIVER=secrets
This simple configuration choice can have deep operational consequences, especially in regulated environments or large-scale clusters.
Available Helm Drivers
Secrets Driver (Default)
The secrets driver stores release information as Kubernetes Secrets in the target namespace. This has been the default driver since Helm 3 was introduced.
Secrets are base64-encoded and can be encrypted at rest if Kubernetes encryption at rest is enabled. This makes the driver suitable for clusters with moderate security requirements without additional configuration.
ConfigMaps Driver
The configmaps driver stores Helm release state as Kubernetes ConfigMaps. Functionally, it behaves very similarly to the secrets driver but without any form of implicit confidentiality.
export HELM_DRIVER=configmaps
This driver is often used in development or troubleshooting scenarios where human readability is preferred.
Memory Driver
The memory driver stores release information only in memory. Once the Helm process exits, all state is lost.
export HELM_DRIVER=memory
This driver is rarely used outside of testing, CI pipelines, or ephemeral validation workflows.
Evolution of Helm Drivers
Helm drivers were significantly reworked with the release of Helm 3 in late 2019. Helm 2 relied on Tiller and ConfigMaps by default, which introduced security and operational complexity. Helm 3 removed Tiller entirely and introduced pluggable storage backends with Secrets as the secure default.
Since then, improvements have focused on performance, stability, and better error handling rather than introducing new drivers. The core abstraction has remained intentionally small to avoid fragmentation.
Practical Use Cases and When to Use Each Driver
In production Kubernetes clusters, the secrets driver is almost always the right choice. It integrates naturally with RBAC, supports encryption at rest, and aligns with Kubernetes-native security models.
ConfigMaps can be useful when debugging failed upgrades or learning Helm internals, as the stored data is easier to inspect. However, it should be avoided in environments handling sensitive values.
The memory driver shines in CI/CD pipelines where chart validation or rendering is needed without polluting a cluster with state.
Practical Examples
Switching drivers dynamically can be useful when inspecting a release:
HELM_DRIVER=configmaps helm get manifest my-release
Or running a dry validation in CI:
HELM_DRIVER=memory helm upgrade --install test ./chart --dry-run
Final Thoughts
Helm drivers are rarely discussed, yet they influence how reliable, secure, and observable your Helm workflows are. Treating the choice of driver as a deliberate architectural decision rather than a default setting is one of those small details that differentiate mature DevOps practices from ad-hoc automation.
