Bitnami Redis alternative
Replacing bitnamilegacy/redis

Bitnami Redis variables and their official equivalents

Bitnami Redis image to official redis (or valkey/valkey):

What breaks when you switch

• The official image has almost no environment-variable configuration. Bitnami's REDIS_* variables have to become redis.conf directives.
• Data moves from /bitnami/redis/data to /data.
• Redis 7.4 and later are not BSD-licensed. If licence matters, move to Valkey rather than a newer Redis.

bitnami/redis Helm chart values the drop-in image reads

The bitnami/redis chart starts Redis through its own scripts rather than the image's default command. Those scripts source Bitnami shell libraries from /opt/bitnami/scripts, copy redis.conf from /opt/bitnami/redis/mounted-etc into /opt/bitnami/redis/etc, and hand REDIS_PASSWORD to redis-server as --requirepass and --masterauth. The official redis image has none of those files. The OSSeva image keeps them, so each value below behaves as it did on bitnamilegacy/redis. Checked against chart 16.13.2 (Redis 6.2) and 19.6.4 (Redis 7.2).

Redis versions OSSeva publishes

Each line below has a patched OSSeva image. The second column shows which bitnami/redis chart releases defaulted to that line, which tells you the chart major to stay on during the swap.

Replication and high availability in the Redis charts

What happened to the Bitnami Redis image

How to migrate Redis off Bitnami safely

1. Find every reference to bitnami/redis and bitnamilegacy/redis in running workloads, Helm values files and CI pipelines, including init containers.
2. Record the Redis version each deployment pins. Versions past upstream end of life are not covered by the free open source images.
3. Take a backup and test a restore before touching a stateful workload.
4. Mirror the replacement container images into your own registry, and scan them before you deploy.
5. Move one replica or one environment at a time, and confirm the data path, file ownership and credentials on the new image.
6. Remove every remaining legacy reference so nothing falls back to the archive on the next deploy.

Your options

Repoint the Bitnami Redis Helm chart

1. Run helm list to record the chart version, then helm get values <release> to save what is deployed.
2. Keep that chart version. bitnami/redis 20.x moves the default to Redis 7.4, which is no longer BSD-licensed, and 21.x moves to Redis 8.
3. Override image.registry, image.repository and image.tag, with the tag on the Redis line you run today.
4. If sentinel.enabled is true, repoint sentinel.image the same way. Do the same for metrics.image, volumePermissions.image and sysctl.image if those features are on; they are off by default and also pull from Bitnami repositories.
5. Leave out global.security.allowInsecureImages. Bitnami added that image check in December 2024 (redis 20.5.0), after the last chart for Redis 7.2.
6. Run helm upgrade with --reuse-values and the override, then check INFO replication on the master to confirm every replica has reconnected.

# values-osseva.yaml
# helm upgrade my-redis oci://registry-1.docker.io/bitnamicharts/redis \
#   --version 19.6.4 --reuse-values -f values-osseva.yaml
image:
  registry: registry.example.com   # OSSeva registry or your mirror of it
  repository: redis
  tag: "<7.2.x tag>"               # the Redis line you run today
global:
  imagePullSecrets:
    - registry-credentials

This works only with an image that keeps Bitnami's layout. With the official image, rewrite the chart or move to an operator. See replacing bitnamilegacy images for the full inventory and rollout steps.