apiVersion: v2
name: valkey
description: A Helm chart to deploy a single Valkey instance (cache or queue backend) for one application on Kubernetes
icon: https://avatars.githubusercontent.com/u/164458127

type: application

# appVersion is the exact image tag, "9.1.2-alpine" - the version AND the base
# flavour, so the "+up" suffix carries both with the dash normalized to a dot.
#
# Why "-alpine" and not the fully numbered "-alpine3.24" (Gitea #46, third plan
# comment): neither tag is immutable. Upstream rebuilds the whole tag matrix
# periodically, and the build timestamps prove it - "9.1-alpine" and
# "9.0.6-alpine3.24" were pushed within minutes of each other on 2026-09-21
# although 9.0.6 is the older release line. Only a digest is immutable. So the
# choice was never "immutable vs. moving" but between two equally moving tags
# with different Renovate behaviour, and "-alpine" is the better one: docker
# versioning splits at the first dash, reads 9.1.2 as the version and "alpine"
# as the compatibility suffix, so the suffix stays constant forever and the
# update path can never freeze. With "-alpine3.24" it would: upstream builds
# exactly one Alpine base per Valkey release, so the next base arrives as
# "9.1.3-alpine3.25" - a candidate a suffix-bound rule never offers, and
# "no update" looks identical to a working rule.
#
# The price, named rather than discovered: a rebuild of 9.1.2-alpine changes the
# running image with no change in this repository and nothing reports it. The
# remedy if that ever matters is pinDigests for this one image - see the valkey
# block in renovate.json5.
version: 1.0.0+up9.1.2.alpine
appVersion: "9.1.2-alpine"

maintainers:
  - name: jklein