Generally Available: Valkey Helm Chart 1.0.0

Announcements 2026-11-12 · Edith Puclla, Silvio Gissi

The Valkey Helm chart 1.0.0 is now generally available. The chart deploys Valkey on Kubernetes. Since the first commit in July 2025, the chart has been published as a series of 0.x releases, ending with 0.12.1. The maintainers consider this the first stable release of the chart for production use.

The Valkey Helm chart allows you to define your configuration, topology, and resources for a Valkey deployment without cluster mode. The valkey-operator and valkey-resources charts in the same repository are not part of this release.

Deployment modes in the Valkey Helm chart 1.0.0

The Valkey Helm chart 1.0.0 offers three deployment modes:

Standalone (default): one Valkey pod with no replicas, behind one read-write Service.
Replicated: one primary and, by default, two replicas, plus a read-only Service that load-balances reads across all pods.
Sentinel (High Availability): Replicated mode plus three Sentinel pods, which promote a replica when the primary fails.

In all three modes, one primary holds the whole dataset. The chart does not support Valkey cluster mode, which shards the dataset across multiple primaries.

The Replicated and Sentinel modes require Kubernetes persistent storage: a PersistentVolumeClaim (PVC) for each Valkey pod (persistence.enabled). The Quick Start section of the chart README shows the install command for each mode.

Automatic failover with Sentinel in the Valkey Helm chart 1.0.0

Sentinel support is the biggest addition in 1.0.0. In Replicated mode without Sentinel, pod-0 is always the primary. If it fails, no replica takes over, and writes wait until pod-0 comes back. Enable Sentinel, and the chart adds a Sentinel StatefulSet that watches your Valkey pods and promotes a replica when the primary stops responding.

During a rolling update or a node drain, the primary's pod asks Sentinel for a coordinated failover before it shuts down. The primary pauses writes, waits for the replica to catch up, and then hands over. That way, no confirmed write is lost during the switch.

Unexpected failures, like a crashed pod or a lost node, are a different story: they follow Valkey's asynchronous replication, so the most recent writes can be lost. The Sentinel documentation explains the trade-offs.

For clients that do not support Sentinel, the optional HAProxy front-end gives you one endpoint that always points to the current primary.

Production features in the Valkey Helm chart 1.0.0

The chart also includes these production features, all disabled by default:

Authentication: ACL users with passwords from a Kubernetes Secret (auth.enabled).
TLS: encrypted connections with certificates from a Kubernetes Secret (tls.enabled).
Persistent storage: a PersistentVolumeClaim for the Valkey data directory (persistence.enabled), optional in Standalone mode and required in Replicated and Sentinel modes.
Prometheus metrics: a redis_exporter sidecar (metrics.enabled), with optional ServiceMonitor, PodMonitor, and PrometheusRule resources.
NetworkPolicy: a policy for the Valkey pods (networkPolicy.enabled); it does not cover the Sentinel or HAProxy pods.
PodDisruptionBudgets: for the Valkey pods in Replicated and Sentinel modes (podDisruptionBudget.enabled), with separate budgets for the Sentinel and HAProxy pods.

Get started

These commands install the chart in Standalone mode, without authentication:

helm repo add valkey https://valkey.io/valkey-helm/

helm repo update

helm install valkey valkey/valkey --version 1.0.0

The chart is also published as an OCI artifact:

helm install valkey oci://ghcr.io/valkey-io/valkey-helm/valkey --version 1.0.0

For Sentinel mode with authentication, start from the example values file examples/ha-sentinel.yaml. Replace its placeholder passwords with your own passwords or Kubernetes Secrets, then install:

helm install valkey valkey/valkey --version 1.0.0 -f ha-sentinel.yaml

When you are ready to deploy, be sure to follow the production recommendations.

Upgrade from the Valkey Helm chart 0.x to 1.0.0

The Valkey Helm chart 1.0.0 has breaking changes compared with 0.x:

Renamed values: for example, valkeyConfig is now extraConfig, and a single persistence block replaces dataStorage and replica.persistence.
Valkey server 9.0 or later: the chart 1.0.0 deploys Valkey 9.1.3 by default, so most users don't need to change anything. If you pinned an older Valkey server with image.tag, change it to a 9.x version. The chart requires Valkey 9.0 or later because its Sentinel mode uses the coordinated failover option of SENTINEL FAILOVER, which was added in Valkey 9.0 (valkey-io/valkey#1292, Valkey Sentinel docs).
Short downtime in Standalone mode: Standalone mode now defaults to the Recreate deployment strategy, so its upgrades briefly stop Valkey.

Review UPGRADE.md for more.

Open development, open community

The Valkey Helm chart is developed in the public valkey-io/valkey-helm repository, where changes are proposed and reviewed as pull requests. Its maintainers are Mykola Voroniuk (@mk-raven), Silvio Gissi (@sgissi), and Ishan Jain (@Bloodraven21). You can join the work through:

GitHub: issues, pull requests, and discussions in the valkey-helm repository.
Slack: the #valkey-helm channel in the Valkey OSS developer workspace, for questions and feedback.
Contributing guide: the chart has its own CONTRIBUTING.md that explains how to propose and test changes.
Weekly call: the Valkey Operator & Helm Tech Call, every Thursday at 14:00 UTC, where contributors discuss the Valkey Helm chart and the Valkey operator. Join the call.

The chart is released under the BSD 3-Clause license.

Thank you to the Valkey Helm chart contributors

As of November 2026, more than 40 people have authored commits to the Valkey Helm chart. These contributions shaped 1.0.0 directly:

Mykola Voroniuk wrote the first chart templates and has contributed the most commits since.
Patrick Schratz added Sentinel (#234) and the HAProxy front-end (#235).
Silvio Gissi prepared the chart for 1.0.0, including the breaking-change cleanup, graceful Sentinel failover without lost writes, and safer HAProxy routing (#272), plus Sentinel scheduling and PodDisruptionBudgets (#270).
Ishan Jain wrote the contributing guide (#186) and kept Valkey versions current.
somaz made the health probes configurable (#217).
Pierre Gindraud improved the metrics exporter and logging. They fixed the exporter’s TLS setup (#262) and corrected log level (#267).
Rushabh Shah reviewed 1.0.0-RC1, leading to the hardened authentication ahead of 1.0 (#277 and #285).
Joe Heyburn, Kyle J. Davis, and Ishan Jain; organized and led the weekly Helm chart call and set the direction for each of the project’s charts. They also reviewed the 1.0 changes and gave feedback along the way.

Thank you as well to everyone who opened an issue, reviewed a pull request, or told us how the chart behaved in your environment.

What's next

For the Valkey Helm chart, the next steps are:

Rework authentication for consistency and simplify how users, passwords and ACLs are configured across Valkey and Sentinel.
Include support for mTLS.
Add more storage options and review the persistence requirements.

Valkey cluster mode support on Kubernetes is being developed separately, in the valkey-operator and valkey-resources charts in the same repository.

Help improve the Valkey Helm chart 1.0.0

The maintainers want to hear how 1.0.0 behaves in your environment. Four kinds of feedback help the most:

Kubernetes distribution: install the chart on the distribution you run, such as Amazon EKS, Google GKE, Azure AKS, OpenShift, or k3s, and report what worked and what did not.
Sentinel failover: drain a node or run a rolling update on a Sentinel deployment, and report whether your application saw errors.
Client library: connect your client through Sentinel or the HAProxy front-end, and report how it handled a failover.
Upgrade from 0.x: upgrade a test installation from 0.x to 1.0.0, and report anything UPGRADE.md missed.

Report results and bugs as issues in valkey-io/valkey-helm, or ask questions in the #valkey-helm Slack channel.