Valkey's official Helm chart makes deployment ownership explicit

An installation can keep running after the image needed to recreate it becomes difficult to obtain. Valkey's January 6 announcement of its official Helm chart starts from that operating problem. Changes to Bitnami distribution made chart and image availability a concern for deployments, including rollback.

I default to Valkey where Redis semantics are appropriate. Its permissive licensing and continuity with the earlier ecosystem are part of that preference. A maintained deployment chart extends the same concern into packaging, where an operator needs to know who controls the artifacts used to recreate a service.

The community-maintained chart gives the project a deployment path it can document alongside the server. It does not make every topology highly available or turn migration into a chart-name substitution. Those distinctions are visible in the announcement and the README pinned to chart 0.9.2.

Chart identity and server identity are separate inputs

A Helm release selects templates and their values. The server image is another input to the resulting deployment. The pinned README exposes image repository and tag settings, so a chart version alone does not fully describe the executable being deployed.

That distinction matters for reproducibility. Two installations that share a values file but resolve different chart or image versions may not be equivalent. A deployment record needs enough information to identify both the resource definitions and the server package.

The announcement recommends pinning a chart release and the image tag. That creates a reviewable upgrade boundary. A change to packaging can be examined separately from a server update, even when an operator chooses to promote them together.

My preference for Valkey depends on having an understandable operating path. Project maintenance of the chart helps because its configuration can be checked against the server's own documentation. Artifact availability remains part of the deployment requirement, especially for recreating an earlier installation.

Replicas provide a topology with specific limits

The chart defaults to standalone mode and can enable a primary-replica arrangement. The pinned README describes a write service and a read service that balances across pods, along with a headless discovery service. These endpoints represent different roles for client traffic.

A read endpoint is therefore an application decision as well as a chart setting. Sending a write to the endpoint intended for reads is not equivalent to connecting through the write service. Client configuration has to preserve the topology the deployment declares.

The README also exposes a minimum-replica write condition. The example below is the documented setting for requiring one sufficiently current replica before accepting writes.

replica:
  minReplicasToWrite: 1
  minReplicasMaxLag: 10

The documented consequence is that the primary rejects writes when fewer than the required number of replicas are available. That is an availability tradeoff. Increasing the required replica count changes the conditions under which the deployment can accept work.

This setting should not be described as automatic failover. The announcement lists Sentinel-based high availability as upcoming work. Replication can provide additional copies and read capacity while leaving promotion and recovery as separate responsibilities.

Persistence remains a deliberate configuration

Standalone persistence is optional in the pinned chart documentation. Without it, the README describes storage as ephemeral and says data is lost on pod restart. Persistent storage can instead be configured through a new or existing claim.

Replication mode requires persistent storage. The README explains the failure it is trying to avoid. A primary that returns with an empty dataset can cause its replicas to synchronize with that empty state. Additional running replicas would not make that restart behavior safe.

This makes persistence configuration part of the replication design. A deployment description that counts pods but omits the primary's storage behavior leaves out a material failure condition. The chart's requirement forces that question into the configuration.

The persistence setting also differs between standalone and replicated modes. Standalone configuration uses dataStorage, while replication has its own persistence section. Copying a value from another chart without checking its meaning can produce a deployment that looks familiar but has different storage.

Authentication needs a defined default user

The README supports ACL users and an existing Kubernetes Secret for passwords. It warns that enabling authentication also requires defining the default user in the generated or raw ACL configuration. Otherwise the default user can leave access available without credentials.

That warning is more specific than an authentication-enabled flag. The resulting ACL configuration determines access. A declarative setting is useful only when its generated server configuration expresses the intended policy.

The chart also supports a dedicated replication user. Its documented permissions include PSYNC, REPLCONF and PING. Replication credentials therefore belong in the deployment configuration alongside application credentials, even when both are supplied through the same Secret mechanism.

TLS uses another existing Secret containing the server certificate and key with a CA certificate. These configuration choices show why adopting the official chart still requires reading its values. A familiar protocol does not make chart schemas interchangeable.

Metrics are another explicit option. The chart can enable an exporter sidecar and a ServiceMonitor for Prometheus Operator discovery, so installing the server does not automatically establish monitoring.

Bitnami migration changes the resource set

The announcement explicitly rejects an in-place upgrade from the Bitnami chart because resource names and management differ. Its proposed approach deploys the official chart alongside the existing installation, transfers data through replication and changes client endpoints during a maintenance window.

The important mechanism is that the replacement first follows the existing primary. Promotion and client redirection happen after replication has established the replacement's state. Merely creating the new Kubernetes resources would leave the data transition incomplete.

That process also changes the meaning of rollback. Restoring an old Helm release and deciding which server now owns writes are separate actions once clients have moved. A migration procedure needs a defined point of authority for writes throughout the switch.

The official chart makes the project's supported deployment configuration easier to identify. Its present scope still requires an operator to choose storage and client endpoints explicitly. The pinned documentation gives those choices concrete names, which makes the deployment easier to reproduce and the migration easier to describe.