--- title: "HiveMQ Platform Operator for Kubernetes 2.3.0 is now available!" description: HiveMQ Platform Operator for Kubernetes 2.3.0 scales your HiveMQ Platform one Pod at a time to protect your data and your clients. The HiveMQ Platform Helm chart 0.3.0 adds a simple way to store the HiveMQ runtime folders on persistent storage. date: 2026-10-21 author: HiveMQ Team tags: - HiveMQ K8s Operator source: https://www.hivemq.com/changelog/hivemq-platform-operator-2-3-0-release --- # HiveMQ Platform Operator for Kubernetes 2.3.0 is now available! The HiveMQ Team is excited to announce the release of the HiveMQ Platform Operator for Kubernetes 2.3.0. With this release, the operator scales your HiveMQ Platform one Pod at a time to protect your data and your clients. The HiveMQ Platform Helm chart 0.3.0 adds a simple way to store the HiveMQ runtime folders on persistent storage. ### Highlights - **Safer scaling.** The operator changes the replica count of a HiveMQ Platform one Pod at a time and waits for the cluster to settle between steps. - **Persistent storage for the HiveMQ runtime folders.** The `persistence` value of the HiveMQ Platform Helm chart stores the HiveMQ data, log, and audit folders, and by default also the backup folder, on a `PersistentVolumeClaim` per Pod. ## Safer Scaling, One Pod at a Time When you change the number of replicas of a HiveMQ Platform, the HiveMQ Platform Operator for Kubernetes now applies the change one Pod at a time instead of all at once. ### How it works In previous versions, a scale-down from 10 to 5 replicas removed five HiveMQ nodes in direct succession. Each step was bounded only by the termination of the Pod, never by the state of the HiveMQ cluster. With version 2.3.0, the operator changes the replica count by exactly one Pod per step, in both directions: - **Scale down.** Before the operator removes a Pod, three conditions must hold. All Pods are ready and report the current cluster size. The cluster topology is stable. The cluster has remained stable for at least 30 seconds since the previous removal. - **Scale up.** The operator adds one Pod, waits until it has joined the cluster and stayed ready for at least 30 seconds, and then adds the next one. You can configure both wait times globally for the operator or for each HiveMQ Platform. The scaling progress is persisted in the HiveMQ Platform status, so an operator restart resumes the scaling where it stopped. If you change the target replica count while scaling is in progress, the operator scales to the latest value. A scale-down that is requested together with a rolling restart runs first, so the rolling restart does not restart Pods that the operator removes right after. ### How it helps - **Prevents data loss.** The remaining HiveMQ nodes get time to restore the configured number of replicas of the cluster data after every removed node, before the next node leaves. - **Avoids reconnect storms.** Each step disconnects only the clients of one node, which spreads the reconnects of your MQTT clients over time and protects your load balancers and the remaining nodes. - **Makes scaling predictable.** The operator adds one node at a time, independent of the `podManagementPolicy` of the StatefulSet, so new Pods no longer remain unready while another node joins the cluster. ## Persistent Storage for the HiveMQ Runtime Folders Since version 0.3.0, the HiveMQ Platform Helm chart offers a top-level `persistence` value to store the HiveMQ runtime folders on persistent storage. ### How it works Configure a storage class and a storage size: ```yaml persistence: storageClass: standard storageSize: 10Gi ``` The chart creates a `PersistentVolumeClaim` for each HiveMQ Platform Pod and stores the HiveMQ data, log, and audit folders on the claim. By default, the chart also stores the backup folder there. Both values are required when `persistence` is configured. Configure `persistence` when you install the HiveMQ Platform, because you cannot add, remove, or change it on an existing installation. The configuration, extensions, and license folders stay managed by the chart as before. For a custom storage layout, use the `additionalVolumes` and `volumeClaimTemplates` values instead. ### How it helps - **Keeps runtime data across restarts.** The HiveMQ logs, audit logs, and backups remain available even after all Pods restart at the same time. The same applies to the log-based clustering state of HiveMQ Data Intelligence. - **Simplifies the configuration.** One short block replaces the matching pair of `additionalVolumes` and `volumeClaimTemplates` entries that you previously needed to write manually. ## Additional Features and Improvements ### HiveMQ Platform Operator for Kubernetes - **Lower init app memory usage.** The init app that runs in every HiveMQ Platform Pod now uses up to 50% less memory. The full reduction applies after the next rolling restart of the HiveMQ Platform. - **Download timeouts and retries.** Extension and customization downloads now time out after 10 minutes. The init app retries a timed-out or refused download twice. A stalled download no longer blocks the start of a HiveMQ Platform Pod indefinitely. - **Crash loop detection.** The operator now detects a crash-looping HiveMQ Platform Pod and moves the platform to the `ERROR` state instead of waiting for the Pod indefinitely. - **Surge Pod health check.** During a rolling restart, the operator now also waits until the surge Pod reports that it is healthy before the operator restarts the first Pod. - **Rolling restart pacing based on Pod readiness.** In a rolling restart, the minimum time between two Pod restarts now counts from when the last restarted Pod became ready, instead of from when it started. The `spec.rollingRestart.lastPodMinAgeSeconds` field is deprecated in favor of `spec.rollingRestart.lastPodReadyMinAgeSeconds`, and still applies when the new field is not set. - **Quieter init app logs.** The init app logs an unavailable HiveMQ Health API during the HiveMQ startup at `INFO` level instead of `ERROR`. Log monitoring no longer reports these expected startup messages. - **Cosign bundle signatures.** The container images of the operator, the init app, and the monitoring image on Docker Hub are now signed in the Cosign bundle format, which keeps the signatures out of the Docker Hub tag list. Verify them with Cosign v2.6.3 or later as described in [Verify the HiveMQ Platform Operator container images](https://docs.hivemq.com/hivemq-platform-operator/configuration.html#verify-container-images). ### HiveMQ Platform Helm Chart - **Client Lifecycle Topic add-on.** The `hivemqMqttAddons` values now support the Client Lifecycle Topic MQTT add-on of HiveMQ 4.56, including the identifier and trigger options. - **HiveMQ Data Intelligence configuration.** You can now configure HiveMQ Data Intelligence log-based clustering and the Data Intelligence server connection. The chart reads the connection string from a Kubernetes Secret. The HiveMQ Data Intelligence values replace the HiveMQ Pulse values. If you still set a HiveMQ Pulse value, the chart shows a message that explains the migration. ### HiveMQ Platform Operator Helm Chart - **Read-only access to Secrets.** The HiveMQ Platform Operator now has read-only permissions on Secrets, because the operator never creates, modifies, or deletes a Secret. - **Extended Grafana dashboard.** The Grafana dashboard now shows several operator instances at once. The dashboard also adds panels for the controller events, the current JVM heap usage, and the API server requests on ConfigMaps and Secrets. ## Bug Fixes ### HiveMQ Platform Operator for Kubernetes - Fixed an issue where the migration from HiveMQ Platform Operator 1.7.x stopped during the init app update. Operator 2.2.1 introduced the issue. - Fixed an issue where the HiveMQ Platform custom resource kept its last successful status while reconciliation failed repeatedly. The status now changes to `ERROR` with the phase `UNCAUGHT_RECONCILIATION_ERROR` and the reason of the failure, and the operator sends a `ReconciliationFailure` warning event. - Fixed an issue where the HiveMQ container did not restart when HiveMQ exited with code 1, for example after a JVM crash. The container now restarts, and the captured warnings and errors of HiveMQ are written to the container termination message. - Fixed an issue where the operator removed the surge Pod of a rolling restart without waiting for the configured minimum age of the last restarted Pod. Its client disconnects are now spaced like those of every other Pod of the restart. - Fixed an issue where the operator no longer enforced `concurrentRollingRestartLimit` and `concurrentInitAppUpdateLimit` after a HiveMQ Platform entered the `ERROR` state during a rolling restart or an init app update. - Fixed an issue where the StatefulSet update of a HiveMQ Platform failed because the StatefulSet referenced an extension configuration volume that the operator did not create. ### HiveMQ Platform Helm Chart - Fixed an issue where `extensionMap` entries set to `null` in a values file caused chart rendering to fail. A `null` entry now removes the extension as documented. ## Get Started Today To get started with the new HiveMQ Platform Operator, see our [HiveMQ Platform Operator Quick Start Guide](https://docs.hivemq.com/hivemq-platform-operator/index.html#platform-operator-quick-start). To update from a previous version of the HiveMQ Platform Operator for Kubernetes, you need to update your HiveMQ Platform custom resource definition (CRD). For step-by-step instructions, see our [Upgrade Guide](https://docs.hivemq.com/hivemq-platform-operator/upgrade-guide.html). To learn more about our operator, see [HiveMQ Platform Operator for Kubernetes](/solutions/technology/kubernetes/).