Valkey and Redis Operators on Kubernetes Compared

Search for "valkey operator" or "redis operator" and you get a dozen GitHub repositories, a vendor product, and Helm charts that stopped pulling images in 2025. The Spotahome operator that many Sentinel setups were built on is archived. The Bitnami charts default to image tags that Docker Hub now answers with a 404. The official Valkey operator reached v0.8.0 in October 2026 and still says it is not ready for production. This post checks each option's status as of November 2026, then compares topology, failover, persistence, TLS and ACLs, upgrades, backup, observability, and licence, so you can pick one for Valkey 9.x or Redis 7 and 8 before the first failover tests it for you.

Scope and review date: November 2026. This post covers Kubernetes operators and Helm charts for Valkey 7.2 to 9.1 and Redis 6 to 8. Release dates, licences, and archive status were read from each project's GitHub repository and documentation on 9 November 2026. The commands and manifests were checked against that documentation and were not run in a lab, so try them on a staging cluster first.

Which Valkey and Redis operators are maintained in November 2026?

The table shows each project's licence, latest release, and state as GitHub showed them on 9 November 2026. Canonical's valkey-operator, a Juju charm, is out of scope.

# Re-check any project before you adopt it (needs the GitHub CLI)
for r in valkey-io/valkey-operator OT-CONTAINER-KIT/redis-operator spotahome/redis-operator; do
  gh api repos/$r --jq '"\(.full_name) archived=\(.archived) license=\(.license.spdx_id) pushed=\(.pushed_at)"'
  gh api repos/$r/releases/latest --jq '"  latest: \(.tag_name) \(.published_at)"'
done

Interpretation: archived=true means nobody will merge fixes. A recent pushed date with an old latest release means the fixes you need may exist only on the main branch.

What does the official Valkey operator do today?

The valkey-io/valkey-operator repository was created in September 2025. Its first release, v0.1.0, came on 11 May 2026, and eight more followed by v0.8.0 on 22 October 2026. The README carries an early development notice: "not ready for production use", and the v1alpha1 API may change.

It manages one resource, ValkeyCluster: Valkey in Cluster mode with slot allocation, failover, rolling updates, and ACLs. The quickstart lists its limits: Cluster mode only, no backup or restore, no cert-manager integration (TLS uses a Secret you create), and scale-out and scale-in need Valkey 9.0 or later.

apiVersion: valkey.io/v1alpha1
kind: ValkeyCluster
metadata:
  name: my-cluster
spec:
  shards: 3
  replicas: 1
  image: valkey/valkey:9.0.7     # pin a tag; the operator default is valkey/valkey:9.0.0
  persistence:                   # cannot be added or removed after creation
    size: 10Gi
    storageClassName: gp3
  config:
    cluster-node-timeout: "5000" # Valkey default is 15000 ms; changing it rolls the pods
  networking:
    tls:
      certificates:
        server:
          secretName: valkey-tls

Interpretation: three primaries with one replica each, six pods. Every field is from the ValkeyCluster reference. Decide on persistence at creation time: the reference says it cannot be added or removed afterwards, the size can only grow, and storageClassName is immutable. Pin the image tag. With latest or a digest, the operator cannot detect the Valkey version and drops version-gated directives such as tls-auto-reload-interval, which needs Valkey 9.1.0.

Operator upgrades need care. The v0.8.0 release notes say to apply both CRDs first, because Helm does not upgrade CRDs, and warn that a cluster name over 41 characters (with single-digit indexes) blocks every later update.

kubectl apply --server-side --force-conflicts -f \
  https://raw.githubusercontent.com/valkey-io/valkey-operator/v0.8.0/config/crd/bases/valkey.io_valkeyclusters.yaml
kubectl apply --server-side --force-conflicts -f \
  https://raw.githubusercontent.com/valkey-io/valkey-operator/v0.8.0/config/crd/bases/valkey.io_valkeynodes.yaml

Interpretation: skip this and the cluster still reports Ready, but the API server silently prunes the new podMetadata and serviceAccountName fields. Read every release note of an alpha operator before you upgrade.

Can the OpsTree redis-operator run Valkey?

Not officially. The OpsTree redis-operator README says it supports Redis 6 and later, using images from quay.io/opstree. A GitHub issue titled "Valkey support?" (#1395) has been open since 9 June 2025, and the project's roadmap lists Valkey standalone, replication, and cluster support as future work. Running Valkey images under it is untested by the project, so treat it as a Redis operator.

For Redis it is the broadest open-source option. It has four CRDs: Redis (standalone), RedisReplication, RedisSentinel, and RedisCluster. A RedisReplication can also run Sentinel inline:

apiVersion: redis.redis.opstreelabs.in/v1beta2
kind: RedisReplication
metadata:
  name: redis-replication
spec:
  clusterSize: 3
  sentinel:
    size: 3
    image: quay.io/opstree/redis-sentinel:v7.0.15
  kubernetesConfig:
    image: quay.io/opstree/redis:v7.0.15
  storage:
    volumeClaimTemplate:
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 1Gi

Interpretation: this is the example from the OpsTree replication guide. Its Sentinel defaults are quorum 2, downAfterMilliseconds 5000, failoverTimeout 10000, and parallelSyncs 1. The image tags in the docs are old; pick a current tag from quay.io/opstree/redis and check its licence (below).

Standalone upgrades are an outage, as the upgrade guide says; cluster mode rolls leaders, then followers. Backups are scripts, not a resource: scripts/backup targets S3, Google Cloud Storage, and Azure Blob, run as a Job you build and own.

kubectl apply --server-side -f \
  https://raw.githubusercontent.com/OT-CONTAINER-KIT/redis-operator/v0.27.0/charts/redis-operator/crds/crds.yaml
helm upgrade redis-operator ot-helm/redis-operator --namespace ot-operators --version 0.27.0

Interpretation: CRDs first, because the v0.27.0 notes say three CRDs changed and helm upgrade does not update them. The same release fixed several Sentinel reconcile bugs, a reason to move off older versions.

How does a Sentinel failover work under an operator?

Sentinel does the failover; the operator keeps Kubernetes in step with it. The Valkey Sentinel documentation separates the two votes. The quorum only detects the failure, and the failover itself needs a vote from a majority of Sentinel processes. That is why three Sentinels is the documented minimum.

In OpsTree's code, the <name>-master Service selects pods labelled redis-role=master, and the operator rewrites that label to match each pod's real role. Between step 2 and step 3, clients on the Service can still reach the old pod or nothing. A Sentinel-aware client asks Sentinel directly instead:

# Inline Sentinel of a RedisReplication named redis-replication: StatefulSet redis-replication-s
kubectl exec -n ot-operators redis-replication-s-0 -- \
  redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster

Interpretation: this returns the IP and port of the current primary. In the v0.27.0 source, inline Sentinel uses the master name mymaster and sets the quorum to a majority of sentinel.size (2 for 3 Sentinels), while a separate RedisSentinel resource defaults to myMaster. Confirm both with SENTINEL masters. If the answer differs from the pod the -master Service selects, the operator has not reconciled yet; if that lasts, read the operator logs. The official Valkey Helm chart 1.0.0-rc.1 makes the same point: the primary can be any pod, so clients need a Sentinel-aware library or the chart's HAProxy front-end.

What should you do if you run the Spotahome redis-operator?

Plan a migration. The spotahome/redis-operator repository is archived. Its last release, v1.2.4, is from 28 December 2022, and its README says it was tested against Kubernetes 1.25 to 1.27 and Redis 6. It managed one resource, RedisFailover: Redis with Sentinel, no Cluster mode.

# Find every RedisFailover still running, and the images they use
kubectl get redisfailovers.databases.spotahome.com -A
kubectl get pods -A -l redisfailovers.databases.spotahome.com/name \
  -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

Interpretation: the first command lists the instances to move; the second prints the images of pods carrying the label the operator's source sets. Nothing breaks the day a repository is archived; the risk is the next Kubernetes API removal or CVE. For Redis Sentinel, OpsTree's RedisReplication with sentinel is the closest fit. For Valkey, look at chideat's operator or the official chart's Sentinel mode once it leaves release candidate.

What do the 2025 Bitnami changes mean for Redis and Valkey charts now?

Bitnami announced the change in bitnami/containers issue #83267 on 16 July 2025. From 28 August 2025, Bitnami stopped publishing new images and charts to Docker Hub in OCI format. Versioned tags moved from docker.io/bitnami to docker.io/bitnamilegacy, which gets no further updates. The free bitnamisecure images are limited to the latest tag and meant for development. Source stays on GitHub under Apache 2.0; production images with version history are part of the paid Bitnami Secure Images offering. On 9 November 2026, Docker Hub's API showed:

• docker.io/bitnami/valkey and docker.io/bitnami/redis expose only the latest tag.
• The bitnami/valkey chart (4.0.3) on GitHub defaults to docker.io/bitnami/valkey:8.1.3-debian-12-r3. Docker Hub returns 404 for that tag, so a fresh install with defaults cannot pull its image.
• The same tag exists in bitnamilegacy/valkey, last pushed on 8 August 2025. The newest Redis tag in bitnamilegacy/redis is 8.2.1-debian-12-r0, pushed on 22 August 2025. Neither will get a CVE fix.
• The SAP Valkey operator renders the Bitnami chart and defaults to bitnamilegacy/valkey, so it inherits the same frozen images.

# Every Bitnami image still running in the cluster
kubectl get pods -A -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{end}' \
  | grep -E 'bitnami(legacy|secure)?/' | sort | uniq -c

Interpretation: a versioned bitnami/ image fails the next time a node must pull it, such as after a node replacement. A bitnamilegacy/ image runs but is frozen. Budget a move to the official images, the official Valkey Helm chart, or an operator.

When does the Redis Enterprise operator make sense?

When you want Redis Software features on Kubernetes and will pay for them. Operator 8.2.6-21, released on 29 October 2026 under the newer name Redis Software for Kubernetes, added Gateway API exposure. The model differs from the open-source operators. A RedisEnterpriseCluster (REC) runs Redis Software nodes, and each database is a RedisEnterpriseDatabase (REDB). The cluster manager handles replication and failover; there is no Sentinel.

The quick start sets the floor: at least three worker nodes, each REC node requesting 2 CPUs and 4 GB of memory by default, one REC per namespace, and no single-node RECs. Without a licence key, the cluster runs in trial mode: 30 days and 4 shards, counting primary and replica shards. After the licence expires you cannot add databases or change their settings.

apiVersion: app.redislabs.com/v1alpha1
kind: RedisEnterpriseDatabase
metadata:
  name: sessions
spec:
  memorySize: 2GB
  shardCount: 2
  replication: true          # one replica shard per primary shard
  persistence: aofEverySecond
  tlsMode: enabled
  backup:
    interval: 86400          # seconds; daily
    s3:
      awsSecretName: s3-backup-creds
      bucketName: my-redis-backups

Interpretation: with replication on, two primary shards make four shards, the whole trial allowance. The fields come from the REDB API reference; spec.backup also accepts GCS, Azure, SFTP, FTP, Swift, and mount targets.

How do the operators compare feature by feature?

The three most likely shortlist candidates, on the same rows, from each project's documentation as of November 2026.

The other options in brief:

How do you choose and roll out an operator?

Start from the topology your clients already speak. A client that is not cluster-aware cannot move to Cluster mode by a config change, and a single-host client needs a Service that follows the primary.

Frequently asked questions

Key takeaways

Run Valkey or Redis on Kubernetes with JusDB

JusDB's Valkey on Kubernetes team can review your Valkey or Redis deployments, check operators, charts, and image sources against their maintenance status, and plan a move off an archived operator or frozen Bitnami images, with failover and restore drills before cutover. For Redis, see Redis on Kubernetes.

Bring your topology, client libraries, image list, and maintenance windows. Your team approves every production change.

Related reading

• Redis Sentinel vs Redis Cluster: choosing the right HA architecture
• Redis vs Valkey: a complete guide to the future of in-memory databases
• Valkey performance tuning: memory, persistence, and cluster config
• valkey-operator documentation: Quickstart and current limitations