Docs Self-Managed Manage Kubernetes Customize the Helm Chart Configure Redpanda in Kubernetes To configure the cluster and the Kubernetes components that the chart deploys, you can customize the values of the Redpanda Helm chart. Helm does a three-way merge with the following: Your overridden values The values in the existing Helm release The default values in the new Helm release (if you’re upgrading) Find configuration options To see what options you can override in the chart, use the helm show values command: helm repo add redpanda https://charts.redpanda.com helm repo update helm show values redpanda/redpanda This command displays all the values, descriptions, and defaults, which are also documented in the Redpanda Helm Chart Specification. Configure Redpanda Operator Helm To customize the values of the Redpanda Helm chart, you can override the defaults in the Redpanda custom resource. You must add all your overrides to the spec.clusterSpec configuration. redpanda-cluster.yaml apiVersion: cluster.redpanda.com/v1alpha2 kind: Redpanda metadata: name: redpanda spec: chartRef: {} clusterSpec: {} For example, to override the storage.persistentVolume.storageClass configuration: redpanda-cluster.yaml apiVersion: cluster.redpanda.com/v1alpha2 kind: Redpanda metadata: name: redpanda spec: chartRef: {} clusterSpec: storage: persistentVolume: storageClass: "<storage-class>" kubectl apply -f redpanda-cluster.yaml --namespace <namespace> The values in your Redpanda custom resource override their counterparts in the Helm chart’s values.yaml file. Any values that are not overridden maintain their defaults. To customize the values of the Redpanda Helm chart, you can override the defaults in your own YAML file with the --values option or in the command line with the --set option. Redpanda Data recommends using the --values option and creating separate YAML files for each configuration block that you need to override. The Redpanda documentation follows this best practice. This way, it’s clearer to understand what you’ve overridden from the helm command. You can pass more than one --values option in the same command. For example, if you wanted to override the TLS configuration and the storage configuration, you could put those overrides in separate files: helm upgrade --install redpanda redpanda/redpanda \ --namespace <namespace> --create-namespace \ --values custom-storage-class.yaml \ --values enable-tls.yaml --values --set The --values option enables you to keep your overrides in one or more YAML files. If you specify multiple files and then override the same values in two or more of them, the rightmost file takes precedence. For example, you might override the storage.persistentVolume.storageClass configuration in a file called storage-class.yaml: storage-class.yaml storage: persistentVolume: storageClass: "my-storage-class" The helm command to apply this configuration override looks something like the following: helm upgrade --install redpanda redpanda/redpanda \ --namespace <namespace> --create-namespace \ --values storage-class.yaml --reuse-values The values in your YAML files override their counterparts in the Helm chart’s values.yaml file. Any values that are not overridden maintain their defaults. Use the --reuse-values flag to apply your overrides on top of existing overrides that you’ve already made. Don’t include this flag if you’re upgrading to a new version of the Helm chart. If you’re upgrading to a new version of the Helm chart, this flag prevents any values in the new release from being applied. The --set option allows you to specify configuration overrides in the command line. For example, you might override the storage.persistentVolume.storageClass configuration like so: helm upgrade --install redpanda redpanda/redpanda \ --namespace <namespace> --create-namespace \ --set storage.persistentVolume.storageClass=my-storage-class For more details, see the Helm documentation. The values in the --set options override their counterparts in the Helm chart’s values.yaml file. Any values that are not overridden maintain their defaults. If you’re upgrading and you already have Redpanda Console installed, set console.enabled to false to stop Helm from trying to deploy it again. Specify Redpanda CLI flags in the Helm Chart The Redpanda Helm chart allows you to specify Redpanda CLI flags, such as --smp, --memory, or --reserve-memory, directly rather than having to find the appropriate configuration in the chart’s values. When you specify CLI flags, those values take precedence over the values defined in the chart’s values. Operator Helm redpanda-cluster.yaml apiVersion: cluster.redpanda.com/v1alpha2 kind: Redpanda metadata: name: redpanda spec: chartRef: {} clusterSpec: statefulset: additionalRedpandaCmdFlags: - <flag> kubectl apply -f redpanda-cluster.yaml --namespace <namespace> --values --set redpanda-flags.yaml statefulset: additionalRedpandaCmdFlags: - <flag> helm upgrade --install redpanda redpanda/redpanda \ --namespace <namespace> --create-namespace \ --values redpanda-flags.yaml --reuse-values helm upgrade --install redpanda redpanda/redpanda \ --namespace <namespace> --create-namespace \ --set "statefulset.additionalRedpandaCmdFlags=[<flags>]" Set Redpanda cluster properties from Kubernetes Secrets or ConfigMaps Starting in v25.1.1 of the Redpanda Operator and Redpanda Helm chart, you can set any Redpanda cluster configuration property by referencing Kubernetes Secrets or ConfigMaps using the config.extraClusterConfiguration field. This feature provides a more secure, maintainable, and declarative way to manage sensitive or shared configuration values across your Redpanda deployment. Use this method to: Securely inject sensitive values, such as credentials for Iceberg, TLS, or object storage. Reuse the same value across multiple features, such as Tiered Storage, Iceberg, and disaster recovery, without duplication. Centralize config management in Kubernetes-native resources to support GitOps and reduce drift. For example, to set iceberg_rest_catalog_client_secret using a Secret called iceberg-config: Operator Helm redpanda-cluster.yaml apiVersion: cluster.redpanda.com/v1alpha2 kind: Redpanda metadata: name: redpanda spec: clusterSpec: config: extraClusterConfiguration: iceberg_rest_catalog_client_secret: secretKeyRef: name: iceberg-config key: iceberg_rest_catalog_client_secret kubectl apply -f redpanda-cluster.yaml --namespace <namespace> --values --set redpanda-config.yaml config: extraClusterConfiguration: iceberg_rest_catalog_client_secret: secretKeyRef: name: iceberg-config key: iceberg_rest_catalog_client_secret helm upgrade --install redpanda redpanda/redpanda \ --namespace <namespace> --create-namespace \ --values redpanda-config.yaml --reuse-values helm upgrade --install redpanda redpanda/redpanda \ --namespace <namespace> \ --create-namespace \ --set config.extraClusterConfiguration.iceberg_rest_catalog_client_secret.secretKeyRef.name=iceberg-config \ --set config.extraClusterConfiguration.iceberg_rest_catalog_client_secret.secretKeyRef.key=iceberg_rest_catalog_client_secret This method supports both secretKeyRef and configMapKeyRef: Use secretKeyRef for sensitive data like access keys or credentials. Use configMapKeyRef for shared, non-sensitive values such as URIs or feature flags. You can apply this approach to any Redpanda configuration key, making your deployments more secure, modular, and easier to manage at scale. For full configuration options, see Properties. Reset configuration values You may want to reset a configuration value back to its default. The method to do this depends on how you’re managing your Redpanda deployment. Operator CLI If you’re using the Redpanda Operator and want to reset a configuration property back to its default: Add the following annotation to your Redpanda custom resource to enable declarative configuration sync: metadata: annotations: operator.redpanda.com/config-sync-mode: Declarative Remove the configuration key you want to reset from spec.clusterSpec.config. With this annotation, the Redpanda Operator ensures that removed keys are also removed from the Redpanda cluster configuration. If this annotation is not set, the Redpanda Operator retains previously applied values even if you remove them from the custom resource. To reset a configuration property using the Redpanda CLI: Run the rpk cluster config set command with an empty string: rpk cluster config set <property> "" Or, use the rpk cluster config edit command and delete the line for the property. If you’re using a file, such as a values.yaml or a Redpanda resource, to manage your configuration, make sure to also remove the property from that file. Otherwise, it may be reapplied the next time you run helm upgrade or the Pods restart. Configure Redpanda Console Redpanda Console is included as a subchart of the Redpanda Helm chart. You can configure Redpanda Console in the console.config object using the Redpanda Console configuration values. For example, to enable the admin API for Redpanda Console: Operator Helm redpanda-cluster.yaml apiVersion: cluster.redpanda.com/v1alpha2 kind: Redpanda metadata: name: redpanda spec: chartRef: {} clusterSpec: console: enabled: true console: config: redpanda: adminApi: enabled: true urls: - http://redpanda-0.redpanda.<namespace>.svc.cluster.local.:9644 kubectl apply -f redpanda-cluster.yaml --namespace <namespace> --values --set console-enable-admin-api.yaml console: enabled: true console: config: redpanda: adminApi: enabled: true urls: - http://redpanda-0.redpanda.<namespace>.svc.cluster.local.:9644 helm upgrade --install redpanda redpanda/redpanda \ --namespace <namespace> --create-namespace \ --values console-enable-admin-api.yaml --reuse-values helm upgrade --install redpanda redpanda/redpanda \ --namespace <namespace> --create-namespace \ --set console.console.config.redpanda.adminApi.enabled=true \ --set console.console.config.redpanda.adminApi.urls={"http://redpanda-0.redpanda.<namespace>.svc.cluster.local.:9644"} If you want to use the separate Redpanda Console Helm chart, disable Redpanda Console in the Redpanda Helm chart with console.enabled=false. To see what options you can override in the Redpanda Console chart, use the helm show values command: helm repo add redpanda https://charts.redpanda.com helm repo update helm show values redpanda/console For default values and documentation for configuration options, see the values.yaml file. Differences between helm install and helm upgrade When managing Redpanda deployments with Helm, it’s important to understand the differences between helm install and helm upgrade, particularly in how they handle cluster configuration overrides. Use helm install to install or reinstall Redpanda. Use helm upgrade to reconfigure an existing deployment. Reinstall Redpanda When reinstalling Redpanda with helm install, cluster configuration overrides specified in the Helm values may not take effect due to PersistentVolumeClaim (PVC) retention. By default, most PVCs are retained when a Helm release is uninstalled. As a result, when Redpanda is reinstalled, the previously created PVCs are adopted, restoring the state of the previous cluster. This adoption results in the new bootstrap.yaml file being ignored and the post_upgrade job not running. The post_upgrade job is a component in the Helm chart that applies configuration overrides during an upgrade. To ensure the new installation does not adopt the old PVCs and restore the previous state: Delete the existing PVCs before reinstalling Redpanda: kubectl delete pvc -l app=redpanda --namespace <namespace> Execute the helm install command to reinstall Redpanda with a clean state. Configure an existing cluster During a helm upgrade, the post_upgrade job is triggered, which applies the latest overrides to the cluster. Suggested reading Customizing the Chart Before Installing. Suggested labs Redpanda Iceberg Docker Compose ExampleEnable Unified Identity with Azure Entra ID for Redpanda and Redpanda ConsoleOwl Shop Example Application in DockerStart a Single Redpanda Broker with Redpanda Console in DockerStart a Cluster of Redpanda Brokers with Redpanda Console in DockerIceberg Streaming on Kubernetes with Redpanda, MinIO, and SparkSee moreSearch all labs Back to top × Simple online edits For simple changes, such as fixing a typo, you can edit the content directly on GitHub. Edit on GitHub Or, open an issue to let us know about something that you want us to change. Open an issue Contribution guide For extensive content updates, or if you prefer to work locally, read our contribution guide . Was this helpful? thumb_up thumb_down group Ask in the community mail Share your feedback group_add Make a contribution 🎉 Thanks for your feedback! Kubernetes Cluster Properties