[{"_1":2,"_144":-5,"_145":-5},"loaderData",{"_3":4,"_13":14,"_21":22,"_138":139},"root",{"_5":-5,"_6":-7,"_7":8,"_9":-7,"_10":11,"_12":-7},"currentUser","primaryEmail","siteVerification","6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI","toast","enableDev",false,"incidentStatus","routes/_layout",{"_15":-5,"_16":17,"_18":17,"_19":11,"_20":11},"username","isAskGordonEnabled",true,"isUsingNewTemplate","showMinimalLanding","showHoneypotTrap","routes/_layout.layers.$namespace.$reponame.$tag.(images).($imageUrlDigest)",{"_23":24,"_25":26,"_55":56,"_57":-7,"_58":-7,"_59":-7,"_60":-7,"_61":-5,"_62":-5,"_63":11,"_64":11,"_48":65,"_129":17,"_96":97,"_130":95,"_131":47,"_31":32,"_132":11,"_133":17,"_134":135,"_136":-5,"_137":11},"scanningType","none","tagData",{"_27":28,"_29":30,"_31":32,"_33":34,"_35":36,"_37":38,"_39":40,"_41":30,"_42":43,"_44":45,"_46":47,"_48":49,"_50":-5,"_51":40,"_52":53,"_54":17},"content_type","unrecognized","creator",35095401,"digest","sha256:082902ac01ecaab0fcf5d3ee1ddda5bd319706789955f45c92bcd3572fbe0c61","full_size",899021,"id",1208310087,"images",[],"last_updated","2026-06-22T20:20:50.44045Z","last_updater","last_updater_username","bitnamibot508","media_type","application/vnd.vmware.tac.metadata.config.v1+json","name","sha256-6e8c6696366d37fe8057b86819cdff34095b3d9992e8021182e05a7b67213a99.metadata","repository",19064289,"tag_last_pulled","tag_last_pushed","tag_status","inactive","v2","tagImages",[],"layerOrdinals","packageName","cveId","sbom","scoutSummary","staticSummary","isScoutPaymentRequired","canSeeVulnerabilities",{"_66":67,"_78":79,"_82":83,"_84":85,"_86":11,"_39":87,"_88":89,"_90":91,"_46":95,"_96":97,"_98":99,"_100":81,"_101":102,"_103":104,"_105":106,"_107":-5,"_108":109,"_110":111,"_112":11,"_113":97,"_114":115,"_120":11,"_121":122,"_126":97,"_127":128},"categories",[68,72,75],{"_46":69,"_70":71},"Message queues","slug","message-queues",{"_46":73,"_70":74},"Databases & storage","databases-and-storage",{"_46":76,"_70":77},"Monitoring & observability","monitoring-and-observability","content_types",[80,81,28],"helm","image","date_registered","2023-01-24T10:49:57.751222Z","description","Bitnami Helm chart for Redis(R)","is_private","2026-09-19T18:43:55.656183Z","last_modified","2026-03-16T14:25:13.982641Z","media_types",[92,93,94,45],"application/vnd.cncf.helm.config.v1+json","application/vnd.oci.image.config.v1+json","application/vnd.oci.image.index.v1+json","redis","namespace","bitnamicharts","pull_count",89127404,"repository_type","star_count",37,"status",1,"status_description","active","source","collaborator_count",0,"full_description","\n\n# Bitnami Secure Images Helm chart for Redis®\n\nRedis® is an open source, advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets.\n\n[Overview of Redis®](http://redis.io)\n\nDisclaimer: Redis is a registered trademark of Redis Ltd. Any rights therein are reserved to Redis Ltd. Any use by Bitnami is for referential purposes only and does not indicate any sponsorship, endorsement, or affiliation between Redis Ltd.\n\n## TL;DR\n\n```console\nhelm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/redis\n```\n\n> Note: You need to substitute the placeholders `REGISTRY_NAME` and `REPOSITORY_NAME` with a reference to your Helm chart registry and repository.\n\n## Introduction\n\nThis chart bootstraps a [Redis®](https://github.com/bitnami/containers/tree/main/bitnami/redis) deployment on a [Kubernetes](https://kubernetes.io) cluster using the [Helm](https://helm.sh) package manager.\n\n### Choose between Redis® Helm Chart and Redis® Cluster Helm Chart\n\nYou can choose any of the two Redis® Helm charts for deploying a Redis® cluster.\n\n1. [Redis® Helm Chart](https://github.com/bitnami/charts/tree/main/bitnami/redis) will deploy a master-replica cluster, with the [option](https://github.com/bitnami/charts/tree/main/bitnami/redis#redis-sentinel-configuration-parameters) of enabling using Redis® Sentinel.\n2. [Redis® Cluster Helm Chart](https://github.com/bitnami/charts/tree/main/bitnami/redis-cluster) will deploy a Redis® Cluster topology with sharding.\n\nThe main features of each chart are the following:\n\n| Redis® | Redis® Cluster |\n|--------------------------------------------------------|------------------------------------------------------------------------|\n| Supports multiple databases | Supports only one database. Better if you have a big dataset |\n| Single write point (single master) | Multiple write points (multiple masters) |\n| ![Redis® Topology](img/redis-topology.png) | ![Redis® Cluster Topology](img/redis-cluster-topology.png) |\n\n## Before you begin\n\n- Kubernetes 1.23+\n- Helm 3.8.0+\n- PV provisioner support in the underlying infrastructure\n\n## Installing the Chart\n\nTo install the chart with the release name `my-release`:\n\n```console\nhelm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/redis\n```\n\n> Note: You need to substitute the placeholders `REGISTRY_NAME` and `REPOSITORY_NAME` with a reference to your Helm chart registry and repository. For example, in the case of Bitnami, you need to use `REGISTRY_NAME=registry-1.docker.io` and `REPOSITORY_NAME=bitnamicharts`.\n\nThe command deploys Redis® on the Kubernetes cluster in the default configuration. The [Parameters](#parameters) section lists the parameters that can be configured during installation.\n\n> **Tip**: List all releases using `helm list`\n\n## Configuration and installation details\n\nThis section describes credentials, configuration, and other installation options.\n\n### Resource requests and limits\n\nBitnami charts allow setting resource requests and limits for all containers inside the chart deployment. These are inside the `resources` value (check parameter table). Setting requests is essential for production workloads and these should be adapted to your specific use case.\n\nTo make this process easier, the chart contains the `resourcesPreset` values, which automatically sets the `resources` section according to different presets. Check these presets in [the bitnami/common chart](https://github.com/bitnami/charts/blob/main/bitnami/common/templates/_resources.tpl#L15). However, in production workloads using `resourcesPreset` is discouraged as it may not fully adapt to your specific needs. Find more information on container resource management in the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/).\n\n### Prometheus metrics\n\nThis chart can be integrated with Prometheus by setting `metrics.enabled` to `true`. This will deploy a sidecar container with [redis_exporter](https://github.com/oliver006/redis_exporter) in all pods and a `metrics` service, which can be configured under the `metrics.service` section. This `metrics` service will have the necessary annotations to be automatically scraped by Prometheus.\n\n#### Prometheus requirements\n\nIt is necessary to have a working installation of Prometheus or Prometheus Operator for the integration to work. Install the [Bitnami Prometheus helm chart](https://github.com/bitnami/charts/tree/main/bitnami/prometheus) or the [Bitnami Kube Prometheus helm chart](https://github.com/bitnami/charts/tree/main/bitnami/kube-prometheus) to easily have a working Prometheus in your cluster.\n\n#### Integration with Prometheus Operator\n\nThe chart can deploy `ServiceMonitor` objects for integration with Prometheus Operator installations. To do so, set the value `metrics.serviceMonitor.enabled=true`. Ensure that the Prometheus Operator `CustomResourceDefinitions` are installed in the cluster or it will fail with the following error:\n\n```text\nno matches for kind \"ServiceMonitor\" in version \"monitoring.coreos.com/v1\"\n```\n\nInstall the [Bitnami Kube Prometheus helm chart](https://github.com/bitnami/charts/tree/main/bitnami/kube-prometheus) for having the necessary CRDs and the Prometheus Operator.\n\n### [Rolling VS Immutable tags](https://techdocs.broadcom.com/us/en/vmware-tanzu/bitnami-secure-images/bitnami-secure-images/services/bsi-doc/apps-tutorials-understand-rolling-tags-containers-index.html)\n\nIt is strongly recommended to use immutable tags in a production environment. This ensures your deployment does not change automatically if the same tag is updated with a different image.\n\nBitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.\n\n### Use a different Redis® version\n\nTo modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter.\n\n### Load custom modules in Redis®\n\nYou can use the `commonConfiguration` parameter to specify the modules to load. For example, to load the RediSearch, RedisBloom, RedisJSON and RedisTimeSeries modules supported from Redis® 8+, you can set the following:\n\n```yaml\ncommonConfiguration: |\n loadmodule /opt/bitnami/redis/lib/redis/modules/redisbloom.so\n loadmodule /opt/bitnami/redis/lib/redis/modules/redisearch.so\n loadmodule /opt/bitnami/redis/lib/redis/modules/rejson.so\n loadmodule /opt/bitnami/redis/lib/redis/modules/redistimeseries.so\n```\n\n### Bootstrapping with an External Cluster\n\nThis chart is equipped with the ability to bring online a set of Pods that connect to an existing Redis deployment that lies outside of Kubernetes. This effectively creates a hybrid Redis Deployment where both Pods in Kubernetes and Instances such as Virtual Machines can partake in a single Redis Deployment. This is helpful in situations where one may be migrating Redis from Virtual Machines into Kubernetes, for example. To take advantage of this, use the following as an example configuration:\n\n```yaml\nreplica:\n externalMaster:\n enabled: true\n host: external-redis-0.internal\nsentinel:\n externalMaster:\n enabled: true\n host: external-redis-0.internal\n```\n\n:warning: This is currently limited to clusters in which Sentinel and Redis run on the same node! :warning:\n\nPlease also note that the external sentinel must be listening on port `26379`, and this is currently not configurable.\n\nOnce the Kubernetes Redis Deployment is online and confirmed to be working with the existing cluster, the configuration can then be removed and the cluster will remain connected.\n\n### External DNS\n\nThis chart is equipped to allow leveraging the ExternalDNS project. Doing so will enable ExternalDNS to publish the FQDN for each instance, in the format of `..`.\nExample, when using the following configuration:\n\n```yaml\nuseExternalDNS:\n enabled: true\n suffix: prod.example.org\n additionalAnnotations:\n ttl: 10\n```\n\nOn a cluster where the name of the Helm release is `a`, the hostname of a Pod is generated as: `a-redis-node-0.a-redis.prod.example.org`. The IP of that FQDN will match that of the associated Pod. This modifies the following parameters of the Redis/Sentinel configuration using this new FQDN:\n\n- `replica-announce-ip`\n- `known-sentinel`\n- `known-replica`\n- `announce-ip`\n\n:warning: This requires a working installation of `external-dns` to be fully functional. :warning:\n\nSee the [official ExternalDNS documentation](https://github.com/kubernetes-sigs/external-dns) for additional configuration options.\n\n### Cluster topologies\n\n#### Default: Master-Replicas\n\nWhen installing the chart with `architecture=replication`, it will deploy a Redis® master StatefulSet and a Redis® replicas StatefulSet. The replicas will be read-replicas of the master. Two services will be exposed:\n\n- Redis® Master service: Points to the master, where read-write operations can be performed\n- Redis® Replicas service: Points to the replicas, where only read operations are allowed by default.\n\nIn case the master crashes, the replicas will wait until the master node is respawned again by the Kubernetes Controller Manager.\n\n#### Standalone\n\nWhen installing the chart with `architecture=standalone`, it will deploy a standalone Redis® StatefulSet. A single service will be exposed:\n\n- Redis® Master service: Points to the master, where read-write operations can be performed\n\n#### Master-Replicas with Sentinel\n\nWhen installing the chart with `architecture=replication` and `sentinel.enabled=true`, it will deploy a Redis® master StatefulSet (only one master allowed) and a Redis® replicas StatefulSet. In this case, the pods will contain an extra container with Redis® Sentinel. This container will form a cluster of Redis® Sentinel nodes, which will promote a new master in case the actual one fails.\n\nOn graceful termination of the Redis® master pod, a failover of the master is initiated to promote a new master. The Redis® Sentinel container in this pod will wait for the failover to occur before terminating. If `sentinel.redisShutdownWaitFailover=true` is set (the default), the Redis® container will wait for the failover as well before terminating. This increases availability for reads during failover, but may cause stale reads until all clients have switched to the new master.\n\nIn addition to this, only one service is exposed:\n\n- Redis® service: Exposes port 6379 for Redis® read-only operations and port 26379 for accessing Redis® Sentinel.\n\nFor read-only operations, access the service using port 6379. For write operations, it's necessary to access the Redis® Sentinel cluster and query the current master using the command below (using redis-cli or similar):\n\n```console\nSENTINEL get-master-addr-by-name \n```\n\nThis command will return the address of the current master, which can be accessed from inside the cluster.\n\nIn case the current master crashes, the Sentinel containers will elect a new master node.\n\n`master.count` greater than `1` is not designed for use when `sentinel.enabled=true`.\n\n### Multiple masters (experimental)\n\nWhen `master.count` is greater than `1`, special care must be taken to create a consistent setup.\n\nAn example of use case is the creation of a redundant set of standalone masters or master-replicas per Kubernetes node where you must ensure:\n\n- No more than `1` master can be deployed per Kubernetes node\n- Replicas and writers can only see the single master of their own Kubernetes node\n\nOne way of achieving this is by setting `master.service.internalTrafficPolicy=Local` in combination with a `master.affinity.podAntiAffinity` spec to never schedule more than one master per Kubernetes node.\n\nIt's recommended to only change `master.count` if you know what you are doing.\n`master.count` greater than `1` is not designed for use when `sentinel.enabled=true`.\n\n### Update credentials\n\nThe Bitnami Redis chart, when upgrading, reuses the secret previously rendered by the chart or the one specified in `auth.existingSecret`. To update credentials, use one of the following:\n\n- Run `helm upgrade` specifying a new password in `auth.password`\n- Run `helm upgrade` specifying a new secret in `auth.existingSecret`\n\n### Using a password file\n\nTo use a password file for Redis® you need to create a secret containing the password and then deploy the chart using that secret. Follow these instructions:\n\n- Create the secret with the password. It is important that the file with the password must be called `redis-password`.\n\n```console\nkubectl create secret generic redis-password-secret --from-file=redis-password.yaml\n```\n\n- Deploy the Helm Chart using the secret name as parameter:\n\n```text\nusePassword=true\nusePasswordFiles=true\nexistingSecret=redis-password-secret\nsentinels.enabled=true\nmetrics.enabled=true\n```\n\n### Securing traffic using TLS\n\nTLS support can be enabled in the chart by specifying the `tls.` parameters while creating a release. The following parameters should be configured to properly enable the TLS support in the cluster:\n\n- `tls.enabled`: Enable TLS support. Defaults to `false`\n- `tls.existingSecret`: Name of the secret that contains the certificates. No defaults.\n- `tls.certFilename`: Certificate filename. No defaults.\n- `tls.certKeyFilename`: Certificate key filename. No defaults.\n- `tls.certCAFilename`: CA Certificate filename. No defaults.\n\nFor example:\n\nFirst, create the secret with the certificates files:\n\n```console\nkubectl create secret generic certificates-tls-secret --from-file=./cert.pem --from-file=./cert.key --from-file=./ca.pem\n```\n\nThen, use the following parameters:\n\n```console\ntls.enabled=\"true\"\ntls.existingSecret=\"certificates-tls-secret\"\ntls.certFilename=\"cert.pem\"\ntls.certKeyFilename=\"cert.key\"\ntls.certCAFilename=\"ca.pem\"\n```\n\n### Metrics\n\nThe chart optionally can start a metrics exporter for [prometheus](https://prometheus.io). The metrics endpoint (port 9121) is exposed in the service. Metrics can be scraped from within the cluster using something similar as the described in the [example Prometheus scrape configuration](https://github.com/prometheus/prometheus/blob/master/documentation/examples/prometheus-kubernetes.yml). If metrics are to be scraped from outside the cluster, the Kubernetes API proxy can be utilized to access the endpoint.\n\nIf you have enabled TLS by specifying `tls.enabled=true` you also need to specify TLS option to the metrics exporter. You can do that via `metrics.extraArgs`. You can find the metrics exporter CLI flags for TLS [here](https://github.com/oliver006/redis_exporter#command-line-flags). For example:\n\nYou can either specify `metrics.extraArgs.skip-tls-verification=true` to skip TLS verification or providing the following values under `metrics.extraArgs` for TLS client authentication:\n\n```console\ntls-client-key-file\ntls-client-cert-file\ntls-ca-cert-file\n```\n\n### Deploy a custom metrics script in the sidecar\n\nA custom Lua script can be added to the `redis-exporter` sidecar by way of the `metrics.extraArgs.script` parameter. The pathname of the script must exist on the container, or the `redis_exporter` process (and therefore the whole pod) will refuse to start. The script can be provided to the sidecar containers via the `metrics.extraVolumes` and `metrics.extraVolumeMounts` parameters:\n\n```yaml\nmetrics:\n extraVolumeMounts:\n - name: '{{ printf \"%s-metrics-script-file\" (include \"common.names.fullname\" .) }}'\n mountPath: '{{ printf \"/mnt/%s/\" (include \"common.names.name\" .) }}'\n readOnly: true\n extraVolumes:\n - name: '{{ printf \"%s-metrics-script-file\" (include \"common.names.fullname\" .) }}'\n configMap:\n name: '{{ printf \"%s-metrics-script\" (include \"common.names.fullname\" .) }}'\n extraArgs:\n script: '{{ printf \"/mnt/%s/my_custom_metrics.lua\" (include \"common.names.name\" .) }}'\n```\n\nThen deploy the script into the correct location via `extraDeploy`:\n\n```yaml\nextraDeploy:\n - apiVersion: v1\n kind: ConfigMap\n metadata:\n name: '{{ printf \"%s-metrics-script\" (include \"common.names.fullname\" .) }}'\n data:\n my_custom_metrics.lua: |\n -- LUA SCRIPT CODE HERE, e.g.,\n return {'bitnami_makes_the_best_charts', '1'}\n```\n\n### Host Kernel Settings\n\nRedis® may require some changes in the kernel of the host machine to work as expected, in particular increasing the `somaxconn` value and disabling transparent huge pages. To do so, you can set up a privileged `initContainer` with the `sysctlImage` config values, for example:\n\n```yaml\nsysctlImage:\n enabled: true\n mountHostSys: true\n command:\n - /bin/sh\n - -c\n - |-\n install_packages procps\n sysctl -w net.core.somaxconn=10000\n echo never > /host-sys/kernel/mm/transparent_hugepage/enabled\n```\n\nAlternatively, for Kubernetes 1.12+ you can set `securityContext.sysctls` which will configure `sysctls` for master and slave pods. Example:\n\n```yaml\nsecurityContext:\n sysctls:\n - name: net.core.somaxconn\n value: \"10000\"\n```\n\nNote that this will not disable transparent huge tables.\n\n### FIPS parameters\n\nThe FIPS parameters only have effect if you are using images from the [Bitnami Secure Images catalog](https://go-vmware.broadcom.com/contact-us).\n\nFor more information on this new support, please refer to the [FIPS Compliance section](https://techdocs.broadcom.com/us/en/vmware-tanzu/bitnami-secure-images/bitnami-secure-images/services/bsi-doc/security-frameworks-FIPS-compliance.html).\n\n### Backup and restore\n\nTo backup and restore Redis deployments on Kubernetes, you will need to create a snapshot of the data in the source cluster, and later restore it in a new cluster with the new parameters. Follow the instructions below:\n\n#### Step 1: Backup the deployment\n\n- Connect to one of the nodes and start the Redis CLI tool. Then, run the commands below:\n\n ```text\n $ kubectl exec -it my-release-master-0 bash\n $ redis-cli\n 127.0.0.1:6379> auth your_current_redis_password\n OK\n 127.0.0.1:6379> save\n OK\n ```\n\n- Copy the dump file from the Redis node:\n\n ```console\n kubectl cp my-release-master-0:/data/dump.rdb dump.rdb -c redis\n ```\n\n#### Step 2: Restore the data on the destination cluster\n\nTo restore the data in a new cluster, you will need to create a PVC and then upload the *dump.rdb* file to the new volume.\n\nFollow the following steps:\n\n- In the [*values.yaml*](https://github.com/bitnami/charts/blob/main/bitnami/redis/values.yaml) file set the *appendonly* parameter to *no*. You can skip this step if it is already configured as *no*\n\n ```yaml\n commonConfiguration: |-\n # Enable AOF https://redis.io/topics/persistence#append-only-file\n appendonly no\n # Disable RDB persistence, AOF persistence already enabled.\n save \"\"\n ```\n\n > *Note that the `Enable AOF` comment belongs to the original config file and what you're actually doing is disabling it. This change will only be necessary for the temporal cluster you're creating to upload the dump.*\n\n- Start the new cluster to create the PVCs. Use the command below as an example:\n\n ```console\n helm install new-redis -f values.yaml . --set cluster.enabled=true --set cluster.slaveCount=3\n ```\n\n- Now that the PVC were created, stop it and copy the *dump.rdp* file on the persisted data by using a helping pod.\n\n ```text\n $ helm delete new-redis\n\n $ kubectl run --generator=run-pod/v1 -i --rm --tty volpod --overrides='\n {\n \"apiVersion\": \"v1\",\n \"kind\": \"Pod\",\n \"metadata\": {\n \"name\": \"redisvolpod\"\n },\n \"spec\": {\n \"containers\": [{\n \"command\": [\n \"tail\",\n \"-f\",\n \"/dev/null\"\n ],\n \"image\": \"bitnami/minideb\",\n \"name\": \"mycontainer\",\n \"volumeMounts\": [{\n \"mountPath\": \"/mnt\",\n \"name\": \"redisdata\"\n }]\n }],\n \"restartPolicy\": \"Never\",\n \"volumes\": [{\n \"name\": \"redisdata\",\n \"persistentVolumeClaim\": {\n \"claimName\": \"redis-data-new-redis-master-0\"\n }\n }]\n }\n }' --image=\"bitnami/minideb\"\n\n $ kubectl cp dump.rdb redisvolpod:/mnt/dump.rdb\n $ kubectl delete pod volpod\n ```\n\n- Restart the cluster:\n\n > **INFO:** The *appendonly* parameter can be safely restored to your desired value.\n\n ```console\n helm install new-redis -f values.yaml . --set cluster.enabled=true --set cluster.slaveCount=3\n ```\n\n### NetworkPolicy\n\nTo enable network policy for Redis®, install [a networking plugin that implements the Kubernetes NetworkPolicy spec](https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy#before-you-begin), and set `networkPolicy.enabled` to `true`.\n\nWith NetworkPolicy enabled, only pods with the generated client label will be able to connect to Redis. This label will be displayed in the output after a successful install.\n\nWith `networkPolicy.ingressNSMatchLabels` pods from other namespaces can connect to Redis. Set `networkPolicy.ingressNSPodMatchLabels` to match pod labels in matched namespace. For example, for a namespace labeled `redis=external` and pods in that namespace labeled `redis-client=true` the fields should be set:\n\n```yaml\nnetworkPolicy:\n enabled: true\n ingressNSMatchLabels:\n redis: external\n ingressNSPodMatchLabels:\n redis-client: true\n```\n\n#### Setting Pod's affinity\n\nThis chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). Find more information about Pod's affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity).\n\nAs an alternative, you can use of the preset configurations for pod affinity, pod anti-affinity, and node affinity available at the [bitnami/common](https://github.com/bitnami/charts/tree/main/bitnami/common#affinities) chart. To do so, set the `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters.\n\n## Persistence\n\nBy default, the chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at the `/data` path. The volume is created using dynamic volume provisioning. If a Persistent Volume Claim already exists, specify it during installation.\n\n### Existing PersistentVolumeClaim\n\n1. Create the PersistentVolume\n2. Create the PersistentVolumeClaim\n3. Install the chart\n\n```console\nhelm install my-release --set master.persistence.existingClaim=PVC_NAME oci://REGISTRY_NAME/REPOSITORY_NAME/redis\n```\n\n> Note: You need to substitute the placeholders `REGISTRY_NAME` and `REPOSITORY_NAME` with a reference to your Helm chart registry and repository. For example, in the case of Bitnami, you need to use `REGISTRY_NAME=registry-1.docker.io` and `REPOSITORY_NAME=bitnamicharts`.\n\n## Parameters\n\nThe following subsections list global, common, and component-specific parameters.\n\n### Global parameters\n\n| Name | Description \n\n_Note: the README for this chart is longer than the DockerHub length limit of 25000, so it has been trimmed. The full README can be found at https://techdocs.broadcom.com/us/en/vmware-tanzu/bitnami-secure-images/bitnami-secure-images/services/bsi-app-doc/apps-charts-redis-index.html_","has_starred","hub_user","immutable_tags_settings",{"_116":11,"_117":118},"enabled","rules",[119],".*","is_automated","permissions",{"_123":17,"_124":11,"_125":11},"read","write","admin","user","storage_size",86086495,"isOrg","reponame","tag","canDeleteTags","isHubSbxKitsEnabled","currentTab","","tagAttestations","displaySecurityMetadata","routes/_layout.layers.$namespace.$reponame.$tag.(images).($imageUrlDigest)._index",{"_23":24,"_59":-7,"_57":-7,"_58":-7,"_25":140,"_31":32,"_142":-7,"_143":11},{"_27":28,"_29":30,"_31":32,"_33":34,"_35":36,"_37":141,"_39":40,"_41":30,"_42":43,"_44":45,"_46":47,"_48":49,"_50":-5,"_51":40,"_52":53,"_54":17},[],"imageWithLayers","hasPermissionToViewRepoSettings","actionData","errors"]

bitnamicharts/redis:sha256-6e8c6696366d37fe8057b86819cdff34095b3d9992e8021182e05a7b67213a99.metadata