redis-to-valkey

name	redis-to-valkey
description	Migrate Redis deployments (especially Bitnami Redis Helm charts in Sentinel HA mode) to Valkey on Kubernetes, including fully air-gapped clusters. Core knowledge: the RDB-version wall (Valkey replicates/loads only from Redis ≤ 7.2.x; Redis 7.4+ writes RDB v12 which Valkey rejects; Valkey 9 writes its own v80 — a one-way door), the two transfer layers (version-bound REPLICAOF/DUMP-RESTORE vs version-agnostic logical replay with RedisShake or rdb-cli), a side-by-side cutover runbook, Valkey chart selection (groundhog2k / CloudPirates / official valkey-io tradeoffs), Bitnami-redis→valkey values translation, consumer-app reconnection (Sentinel discovery, master-set names, frozen redis_version 7.2.4), Prometheus exporter continuity, air-gap tool/image mirroring, and Argo CD source rewiring away from charts.bitnami.com. Part of the bitnami-exit suite.
when_to_use	Use whenever the task involves replacing Redis with Valkey or retiring Bitnami Redis: "migrate redis to valkey", "replace bitnami redis", "valkey sentinel chart", "bitnami exit", "bitnami alternative", "REPLICAOF valkey", "RedisShake", "copy redis data to valkey", "can valkey read my dump.rdb". Symptoms: failing docker.io/bitnami/redis image pulls, "Can't handle RDB format version 12", a Valkey replica coming up empty after pointing at Redis, charts pinned to charts.bitnami.com/bitnamilegacy, server version misreported as 7.2.4, dual-channel Sentinel failover bugs. Covers Helm and Argo CD. NOT for Redis Cluster (sharded) topologies or tuning a healthy Valkey.
argument-hint	[chart|data|cutover|apps|airgap] (optional focus area)

redis-to-valkey

Migrate Redis (Bitnami-chart Sentinel HA or any standalone/replicated Redis) to Valkey on Kubernetes with data intact, clients reconnected, and no dependency left on dead-ended Bitnami artifacts. Facts below were verified 2026-07-18 against primary sources (valkey source at release tags, chart repos, vendor docs); re-verify anything version-gated before relying on it in a later year.

Why this migration exists

Broadcom locked down the free Bitnami catalog (effective 2025-09-29): versioned images moved to frozen docker.io/bitnamilegacy and most charts froze. charts.bitnami.com still serves, so pinned charts sync fine and the failure arrives later, at image-pull time — the first pod reschedule onto a node without the tag cached fails. Migrate deliberately, but don't assume the status quo is stable (full risk model: references/airgap-gitops.md). Valkey (Linux Foundation fork of Redis 7.2.4, BSD-licensed) is the sanctioned successor — major consumers (Harbor, GitLab) have adopted or officially support it.

The one fact that shapes every plan: the RDB-version wall

Valkey forked at Redis 7.2. Its replication and snapshot formats stayed at the fork point, then diverged on their own path:

Server	Writes RDB	Can load
Redis 7.0	v10	≤ v10
Redis 7.2	v11	≤ v11
Redis 7.4 / 8.x	v12	≤ v12
Valkey 8.0 / 8.1	v11	≤ v11 (v12+ rejected as foreign)
Valkey 9.0 / 9.1	v80 (own numbering)	v11 and v80; Redis v12+ rejected

(Verified in src/rdb.h at release tags: RDB_VERSION, RDB_FOREIGN_VERSION_MIN 12.)

Consequences:

1. REPLICAOF, RDB file copy, DUMP/RESTORE, and MIGRATE work only from Redis ≤ 7.2.x sources. A full sync ships an RDB stream; a DUMP payload embeds RDB encodings. From Redis 7.4+ these fail with Can't handle RDB format version 12.
2. Worse than failing: a Valkey replica FLUSHES its own dataset before it discovers the incoming RDB is unreadable (valkey-io/valkey#2588). Never point a Valkey holding data at a source "to see if replication works".
3. Valkey 9 is a one-way door. Its v80 snapshots load on nothing else — not Redis, not Valkey 8. The final pre-cutover Redis RDB is the only rollback artifact; archive it before decommissioning.
4. The wall is about persistence formats, not the wire protocol. Any client speaking RESP to Redis 7.2 works against Valkey — which is exactly why logical replay (next section) is version-agnostic.

Choosing a transfer method

Two layers exist; pick by source version and data class:

Version-bound (physical) — only for Redis ≤ 7.2.x sources:

• Live: on Valkey run REPLICAOF <redis-host> 6379, wait for master_link_status:up + offset convergence, repoint clients, REPLICAOF NO ONE.
• Offline: BGSAVE → poll LASTSAVE → stop Redis → place dump.rdb in Valkey's data dir → start Valkey with AOF disabled for the first boot (an enabled AOF silently wins over the RDB and the server boots empty), re-enable after.

Version-agnostic (logical replay) — any Redis version → any Valkey: Tools that decode the data themselves and re-issue plain commands; the target only ever sees ordinary RESP traffic.

• RedisShake (tair-opensource, v4.6+): live PSync sync (keeps target in sync while apps are repointed one at a time), RDB-file reader, SCAN reader. Supports Redis 2.8–8.4.x → Valkey 8–9, standalone/Sentinel/cluster. Caveats: no resume (restart = full recopy); panics on topology change — quiesce failovers during the run.
• rdb-cli (redis/librdb): parses any-version dump.rdb offline and replays it as commands. Best for maintenance-window cutovers.

No transfer (fresh start) — legitimate for disposable data classes:

Data class	Examples	Loss consequence	Verdict
Pure cache	page/object caches	cold-cache latency blip	fresh start
Sessions	encrypted web sessions	users re-authenticate once	fresh start (announce it)
Job queues / app state	Sidekiq, jobservice queues, schedules	enqueued work permanently lost	must transfer (or drain queues to empty in maintenance mode first)

Read references/data-transfer.md for full recipes (RedisShake configs incl. Sentinel endpoints, rdb-cli build, verification commands, air-gap delivery of both tools).

Cutover runbook (side-by-side, any method)

Never upgrade in place — resource naming, UIDs, and formats differ across charts. Deploy Valkey next to Redis, move data, repoint, decommission:

1. Deploy the Valkey release side-by-side (new release name). Decide the Sentinel master-set name up front — keeping the old name (commonly mymaster) means zero client-side master-set changes.
2. Pre-verify the empty Valkey: SENTINEL ckquorum <group> returns OK, SENTINEL get-master-addr-by-name <group> answers, auth works.
3. Quiesce writers: scale client Deployments to 0 or enable the app's maintenance mode. (For live RedisShake sync, start the sync before this step and quiesce only for the final repoint.)
4. Move the data per the method chosen above. Skip for fresh-start classes.
5. Repoint the app: sentinel endpoint list + master-set name + password secret (shape may change per chart — see values translation). For URL-style single-endpoint apps note that some Valkey charts' HA service exposes ONLY the sentinel port — the app must actually speak Sentinel.
6. Scale up and verify: DBSIZE comparison, sampled keys with TTLs intact, app functional probe, exporter metrics flowing.
7. Archive the final Redis RDB (rollback artifact — see one-way door), soak, then delete the Bitnami release, its PVCs, and its image pins.

Chart selection and values translation

As of 2026-07-18: groundhog2k/valkey (Sentinel HA haMode, upstream valkey/valkey images, tracks Valkey releases within days, bus-factor 1) and CloudPirates valkey (Sentinel + an externalReplica migration mode, multi-maintainer, cosign-signed, but one extra OCI library-chart to mirror) are the production-ready Sentinel options. The official valkey-io chart has no Sentinel yet (replication without automatic failover; Sentinel PR pending — recheck before new deployments, a first-party chart likely wins long-term). The Bitnami valkey chart is frozen with dead-ended images. The official valkey-operator is cluster-mode-only and self-declared not production-ready.

Bitnami-redis values do NOT translate 1:1. The traps that break clients or lose data are: auth as config-file fragments instead of a bare password secret, an HA service exposing only 26379, a different default master-set name, persistence defaulting to emptyDir, ServiceMonitor defaulting ON, and UID 999 vs Bitnami's 1001. Full mapping table, behavioral diffs, and exporter wiring: references/chart-migration.md.

Reconnecting consumer applications

Apps fall into config-surface classes — identify the class, then the translation is mechanical: Sentinel-aware (endpoint list + master-set + possibly a separate sentinel password), URL-based single endpoint (needs a real 6379 service or must be switched to its Sentinel mode), DB-index multiplexed (one server, many logical DBs — preserve index assignments), and version-parsing (Valkey hardcodes redis_version:7.2.4 forever — real version is in valkey_version; two-part 7.2 builds have crashed naive parsers). Classes, verification steps, and the dated per-product compatibility log (Harbor, GitLab, oauth2-proxy, Open WebUI, Sidekiq, Sentry): references/app-cutover.md and references/known-consumers.md.

Air-gap and GitOps rewiring

The complete mirror list for a Sentinel HA migration is short: 2 images (docker.io/valkey/valkey, exporter oliver006/redis_exporter — also on ghcr.io and quay.io), 1 vendored chart tarball, and optionally the RedisShake static binary (single-file Go binary from GitHub releases; also ghcr.io/tair-opensource/redisshake as an image). For Argo CD: keep the multi-source $values pattern and swap only the chart source; vendoring the chart into git is the only bootstrap-safe option when the migrated Redis backs the cluster's own registry (a registry cannot host the chart for its own dependency's replacement). Details, OCI syntax (no oci:// prefix in Argo repoURL), Bitnami-endpoint risk model, and Renovate notes: references/airgap-gitops.md.

Pitfalls quick index

Before executing any plan, scan references/pitfalls.md (19 entries by severity). Beyond the traps already covered above: dual-channel replication

• Sentinel phantom replicas on Kubernetes (#2338 — fix shipped in Valkey 9.1.0 ONLY; keep dual-channel-replication-enabled no below that); HEXPIRE absent until Valkey 9; io-threads default-on in Valkey 8+ raising per-pod CPU vs single-threaded Redis sizing.

Reference files

File	Read when
references/data-transfer.md	moving data: recipes for REPLICAOF / RDB copy / RedisShake / rdb-cli, verification, tool delivery offline
references/chart-migration.md	selecting a chart or translating Bitnami redis values
references/app-cutover.md	repointing applications; config-surface classes; verification checklist
references/known-consumers.md	dated per-product compatibility findings (log-style, append-only)
references/airgap-gitops.md	air-gapped mirroring, chart vendoring, Argo CD source rewiring
references/pitfalls.md	always, before executing a migration plan