One Year From the Hallway: The State of the Valkey Operator

TL;DR: Valkey can run on Kubernetes, but managing distributed clusters takes more than keeping pods alive. One year after a hallway conversation sparked the effort, Valkey Operator maintainers Joe Heyburn and Björn Svensson returned to ValkeyConf 2026 to discuss cluster reconciliation, topology-aware scheduling, access controls, and the road to 1.0.

Why Valkey Needs an Operator

Valkey is known for its speed as an open source, in-memory data store. But what happens when you need to run and manage Valkey clusters on Kubernetes?

Kubernetes can restart a failed pod. What it doesn't automatically understand is which Valkey node should become primary, where replicas belong, or how to upgrade a cluster without disrupting traffic.

That's where the Valkey Operator comes in.

A Kubernetes Operator extends Kubernetes with application-specific knowledge. For Valkey, that means automating cluster deployment, failover, upgrades, and recovery.

The idea started with a hallway conversation at Valkey Keyspace in Amsterdam. One year later, at ValkeyConf 2026 in Prague, Valkey Operator maintainers Joe Heyburn of Braze and Björn Svensson of Ericsson showed what the community has built since then and what's next.

An Operator Is More Than a YAML Generator

Kubernetes is good at keeping declared workloads running. A Valkey cluster has additional rules: primaries own hash slots, replicas follow specific primaries, and membership changes must respect data state.

During upgrades, the operator must handle failover, replace containers, and verify replication without interruption.

A Kubernetes operator turns that operational knowledge into a reconciliation loop. Users describe the desired cluster through a custom resource, and a controller watches actual state and moves it toward that desired configuration.

The Valkey Operator's initial design deliberately prioritizes cluster mode, zero-downtime lifecycle operations, resilience, security, and observability. Standalone, primary-replica, and Sentinel deployments have different semantics.

Why One PodSpec Doesn't Solve Placement

A StatefulSet gives pods a shared template and scheduling policy. But a Valkey cluster needs more specific placement decisions. Separating pods matters only if the right instances are separated. A primary and its replica should not share a failure domain.

Generic pod affinity rules don't automatically understand shard identity, primary/replica relationships, or the consequences of losing a particular host.

The operator introduces placement controls at the Valkey topology level, including scheduling modes for distributing primaries and replicas across infrastructure. In the session, the team showed how required and preferred placement policies express the difference between a hard rule and a best-effort preference.

Hard constraints protect availability but can leave pods unscheduled when capacity is tight. The tradeoff needs to be explicit.

Meet ValkeyNode: A Smaller Unit of Control

The architecture also introduces a ValkeyNode resource alongside ValkeyCluster.

A cluster-level resource captures the intended deployment, including shard and replica counts. Node-level resources let the controller track individual instances and their roles, even when Kubernetes objects and Valkey topology change separately.

The presentation walked through the ownership chain from ValkeyCluster to Kubernetes workloads and pods, and showed how ValkeyNode participates in reconciliation. A kubectl get valkeynodes example made the model tangible: the operator exposes node identity, readiness, and primary/replica roles through the Kubernetes API.

A healthy pod doesn't necessarily mean a healthy Valkey cluster.

ACLs and Day-Two Operations Are Part of the Design

The session showed declarative Valkey access-control lists (ACLs), including users, command permissions, and key-access patterns. Declaring permissions in the cluster specification makes access configuration repeatable across deployments.

The team also demonstrated the operator managing a live cluster, with the controller updating both Kubernetes resources and Valkey state.

There is still substantial work ahead. The public repository continues to describe the v1alpha1 API as early development and not production-ready. That warning matters more than any demo. The controller has to stay correct through node failure, interrupted upgrades, and partial recovery.

From Hallway Idea to 200+ Merged PRs

The community growth is part of the technical story. As of ValkeyConf in October 2026, the speakers reported more than 200 merged pull requests and over 25 contributors from multiple companies. Those contributions cover implementation, testing, and the operational edge cases that determine reliability.

As presented at ValkeyConf, the team is targeting a December 2026 feature freeze and release candidates, followed by a 1.0 milestone in January 2027 with a v1beta1 API.

The longer-term ideas are broader still: backup and restore, autoscaling, external access, rollout strategies, and support for more deployment patterns. The presenters also introduced ValkeyCell as a possible abstraction for groups of standalone Valkey instances and non-cluster-compatible workloads.

But the team's immediate challenge is clear: make the cluster lifecycle predictable before expanding the surface area.

The Real Feature Is Less Manual Recovery

Operating Valkey correctly on Kubernetes is the problem the operator exists to solve. A growing community is encoding that operational knowledge into a controller. Beyond the 1.0 milestone, the real test is whether it turns manual runbooks into repeatable behavior while leaving developers and operators in control.

Follow the work, review the open design decisions, or contribute at github.com/valkey-io/valkey-operator.