// OSSeva Blog
OperationsValkey Kubernetes Operator: Official and Community Options, Helm Charts After Bitnami, and HA Modes
The short answer
There is an official Valkey operator, but it is not production-ready yet. The Valkey project publishes valkey-io/valkey-operator, Apache 2.0, which manages sharded Valkey clusters through a ValkeyCluster resource. Its README states it is in active development and "not ready for production use", with a v1alpha1 API that may change. For production today, the practical choices are the project's own valkey Helm chart, which runs standalone, replicated or Sentinel-managed Valkey without an operator, or a community operator such as chideat/valkey-operator when they need cluster mode under an operator.
If you are on Bitnami's valkey or valkey-cluster charts, the charts still exist, but their default images come from the Bitnami catalogue that changed in 2025, and the legacy Valkey image has not been updated since August 2025.
Valkey on Kubernetes: the options
Checked against each project's repository on 7 October 2026.
| Option | Maintainer | Licence | Modes | Status |
|---|---|---|---|---|
| valkey Helm chart (valkey-helm) | Valkey project | BSD 3-Clause | Standalone, replication, Sentinel | Chart 0.12.0, 2 September 2026, Valkey 9.1.2 by default |
| valkey-operator | Valkey project | Apache 2.0 | Cluster mode (shards with replicas) | v0.7.1, 28 September 2026; "not ready for production use" |
| chideat/valkey-operator | Community | Apache 2.0 | Standalone, Sentinel, cluster | v2.1.0, 28 September 2026; lists Valkey 7.2 to 9.1 as stable |
| SAP/valkey-operator | SAP | Apache 2.0 | Primary with replicas, or Sentinel; no sharding | v0.1.15, 7 October 2026; installs the Bitnami valkey chart underneath |
| hyperspike/valkey-operator | Community | Apache 2.0 | Cluster | Latest release v0.0.61, 12 October 2025 |
| Bitnami valkey and valkey-cluster charts | Broadcom | Apache 2.0 (chart source) | Replication, Sentinel; cluster with valkey-cluster | Chart 4.0.3 defaults to bitnami/valkey:8.1.3; the legacy image was last updated 8 August 2025 |
The official valkey Helm chart
The Valkey project's valkey-helm repository holds three charts: valkey for deployments without an operator, valkey-operator to install the operator, and valkey-resources for the custom resources the operator manages. The valkey chart is the practical choice for most production workloads today:
helm repo add valkey https://valkey.io/valkey-helm/
helm install valkey valkey/valkey \
--set replica.enabled=true \
--set replica.persistence.size=5Gi
Replication mode gives read scaling and a copy of the data, but the chart's own README is clear that it does not fail over: the master is always pod 0, and clients keep writing to it until someone intervenes. For automatic failover, enable Sentinel. The chart then adds a separate StatefulSet of three Sentinel pods by default, which monitor the Valkey pods and promote a replica when the master stops responding. Clients must ask Sentinel for the current master rather than connecting to a fixed pod. Spread the Sentinel pods across nodes or zones so one failure cannot remove the quorum.
The official valkey-operator
The operator manages Valkey in cluster mode. A ValkeyCluster resource declares the number of shards and replicas per shard, and the operator handles scaling, rolling upgrades, failover, TLS and access control:
apiVersion: valkey.io/v1alpha1
kind: ValkeyCluster
metadata:
name: my-cluster
spec:
shards: 3
replicas: 1
That creates three primaries and three replicas. It needs Kubernetes 1.31 or later. The project holds a weekly community call and takes design input on GitHub. Watch it, test it, but treat the alpha API and the README's warning as reasons to keep it out of production for now.
Community operators
chideat/valkey-operator covers all three topologies, standalone, Sentinel and cluster, and lists Valkey 7.2, 8.0, 8.1, 9.0 and 9.1 as stable. It supports ACLs, online scaling and version upgrades, and describes itself as production-ready. It is a community project, so review its release history and issue tracker the way you would any dependency.
SAP/valkey-operator adds a Valkey resource for cluster-internal caches. Under the hood it installs the Bitnami valkey chart, which gives it a primary with read replicas or a Sentinel-managed set, but no sharding. Check which images it pulls given the Bitnami catalogue change.
hyperspike/valkey-operator provisions Valkey clusters. Its most recent release is from October 2025, so check activity before adopting it.
Choosing a mode: replication, Sentinel or cluster
- Replication without Sentinel suits caches where a short outage on master failure is acceptable. It needs no client changes.
- Sentinel gives automatic failover for a single dataset that fits on one primary. Clients need a Sentinel-aware connection. Use at least three Sentinels.
- Cluster mode shards the keyspace across several primaries, each with replicas, for datasets or write loads one primary cannot hold. Clients must be cluster-aware, and multi-key operations only work when the keys hash to the same slot, which hash tags can arrange.
Moving from Sentinel to cluster mode is a data migration plus a client change, so choose with a year of growth in mind.
Leaving Bitnami's Valkey charts
Bitnami's valkey chart, at version 4.0.3, still points at docker.io/bitnami/valkey:8.1.3-debian-12-r3, and the frozen copy in bitnamilegacy/valkey was last updated on 8 August 2025. Three routes out:
- Move to the official valkey chart. Closest in shape for replication and Sentinel deployments. Plan a data copy and new values, because the chart layout and variables differ.
- Move to an operator if you run
valkey-clusterand want cluster mode managed for you. - Keep the Bitnami chart and change the image. Our guide to replacing bitnamilegacy images in Helm charts covers the mechanics, and what replaced the Bitnami catalogue covers the background. For Redis-based Bitnami releases, OSSeva publishes a Bitnami-compatible Redis image that also covers Valkey.
Where OSSeva fits
OSSeva for Redis and Valkey supports Valkey 7.2.x and 8.x and community Redis 6.2, 7.0 and 7.2. OSSeva's Redis builds are binary-compatible with upstream and run in Cluster, Sentinel and standalone modes, so the support follows the topology you choose rather than dictating one. If you are on Valkey 9 or depend on a particular operator, raise it on the discovery call. Valkey sits under one contract with PostgreSQL, MySQL, MariaDB and Kafka, priced per cluster. For the move off Redis itself, see migrating from Redis to Valkey and Valkey vs Redis; for vector workloads, vector search on Valkey. Book a discovery call for a quote.
Frequently asked questions
Is there an official Valkey Kubernetes operator?
Yes. The Valkey project publishes valkey-operator under Apache 2.0, but its README says it is not ready for production use and its API is v1alpha1.
What is the best way to run Valkey on Kubernetes today?
For a single dataset, the official valkey Helm chart with Sentinel enabled. For cluster mode under an operator, a community operator such as chideat/valkey-operator, after you have reviewed it.
Does the valkey Helm chart support Sentinel?
Yes. Enabling Sentinel adds three Sentinel pods by default, which promote a replica when the master fails. Without Sentinel, replication mode does not fail over.
Can I still use the Bitnami Valkey Helm chart?
The chart source is still published, but its default images come from the changed Bitnami catalogue, and the legacy Valkey image stopped receiving updates in August 2025. Running it in production means supplying a maintained image.
Valkey Sentinel or cluster mode on Kubernetes?
Sentinel when one primary can hold the data and you want simple clients. Cluster mode when you need to shard writes or memory across primaries, and your clients are cluster-aware.
Tags
Ready to get your open source under control?
Talk to an OSSeva engineer about CVE coverage, compliance, and migration support for your stack.