Valkey is an open-source fork of Redis, an in-memory key/value database. These kinds of databases are often used for temporary storage of small data that needs very low latency, such as storing user session states or caches. The major cause for this fork was that Redis company relicensed the Redis software from BSD to dual SSPL and proprietary licensing. A number of these kinds of relicensing situations have happened recently and often result in community-made forks, such as with OpenTofu forking from Terraform. Preferably, I prefer the community fork as in almost all areas they tend to have many advantages, especially in a home lab, whereas businesses will likely prefer the paid support proprietary software has.

And this is what lead me to switch over to Valkey from Redis in my homelab.

Helm

One of the delays from immediately switching over was another notable point of contention in the cloud-native community, and that was the restrictions of public Bitnami charts. These were fairly popular, stable, and consistent and offered an easy way to deploy common supporting apps. Fortunately Valkey now supports their own chart and this is what I am now using. They are also in development of an operator, which once that becomes stable I may quickly switch over to that.

In my situation I like to use a preconfigured chart that is set with default values I will use across all my services. How this works is that I take the Valkey official chart as a dependency of this chart. While this creates a few layers of nesting dependencies, it's very linear and uncomplicated, so I don't expect many issues.

apiVersion: v2
name: valkey
version: 0.4.0
description: Valkey chart with preconfigured settings
keywords:
  - valkey
  - redis
  - storage
  - kubernetes
sources:
  - https://github.com/valkey-io/valkey
  - https://github.com/valkey-io/valkey-helm
maintainers:
  - name: alexlebens
dependencies:
  - name: valkey
    repository: https://valkey.io/valkey-helm/
    version: 0.9.3
icon: https://dyltqmyl993wv.cloudfront.net/assets/stacks/valkey/img/valkey-stack-220x234.png
# renovate: datasource=github-releases depName=valkey-io/valkey
appVersion: 9.0.3

I set the values to the common settings that I want for the cluster. What I've set here is mostly just the resources, adding replicas, and metrics with rules. My specific settings can be found in my values file here.

Deployment

What this allows me to do is simplify and very easily add and manage all the Valkey instances across my cluster. Such as here in my Authentik chart, all I need to do is add my chart as a dependency.

apiVersion: v2
name: authentik
version: 1.0.0
description: Authentik
keywords:
  - authentik
  - sso
  - oidc
  - ldap
  - idp
  - authentication
home: https://wiki.alexlebens.dev/s/45ca5171-581f-41d2-b6fb-2b0915029a2d
sources:
  - https://github.com/goauthentik/authentik
  - https://github.com/cloudflare/cloudflared
  - https://github.com/cloudnative-pg/cloudnative-pg
  - https://github.com/goauthentik/helm
  - https://gitea.alexlebens.dev/alexlebens/helm-charts/src/branch/main/charts/cloudflared
  - https://gitea.alexlebens.dev/alexlebens/helm-charts/src/branch/main/charts/postgres-cluster
maintainers:
  - name: alexlebens
dependencies:
  - name: authentik
    version: 2026.2.1
    repository: https://charts.goauthentik.io/
  - name: cloudflared
    repository: oci://harbor.alexlebens.net/helm-charts
    version: 2.4.0
  - name: postgres-cluster
    alias: postgres-18-cluster
    version: 7.10.0
    repository: oci://harbor.alexlebens.net/helm-charts
  - name: valkey
    alias: valkey
    version: 0.4.0
    repository: oci://harbor.alexlebens.net/helm-charts
icon: https://cdn.jsdelivr.net/gh/selfhst/icons/png/authentik.png
# renovate: datasource=github-releases depName=goauthentik/authentik
appVersion: 2025.10.2

In this case I need to add nothing more to configure that chart, just supply Authentik with the host name which is predictably just "authentik-valkey". Whenever I add a new app that needs a Redis compatible database all I do is just add that block in and often just supply the host name, uri, or connection string.

Highly Available

The major downside of the current chart is a lack of Highly Available support, specifically in the case here would be Sentinel. Sentinel is a feature of Redis/Valkey that monitors running instances and if they become unhealthy or unresponsive will automatically manage the fail-over to a healthy standby replica.

There is a pending PR that will add this feature, also incorporating HAProxy a load balancer service, to seamlessly integrate support. While Sentinel will manage the fail-over, HAProxy will keep the connection stable and manage the client's transition to the new primary instance.

In my case, with using a preconfigured chart, I can update that single chart with the new settings for supporting HA which will then propagate down to all my instances. I am looking forward to seeing this change merged in, and so far reading the PR it seems good work is being done before it's release to ensure reliability.

Future Operator

Under active development is a Valkey Operator. Operators are a type of pattern in Kubernetes to more deeply integrate a service into its API and structure. It kind of functions like an automated system admin. For Valkey it will manage deployments using CRDs instead of Helm charts. In some ways it's a little like how I manage my own charts, but in much more seamless way.