HiveMQ Platform Operator for Kubernetes 2.2.0 is now available!

The HiveMQ Team is excited to announce the release of the HiveMQ Platform Operator for Kubernetes 2.2.0.

The centerpiece of this release is a significantly more resilient init app update path. Operator upgrades now roll out smoothly across even the largest fleets, and individual pods stay healthy when an update is interrupted. Version 2.2.0 also adds many customer-requested Helm chart configuration options. These new options include per-platform rolling restart pacing, Pod Disruption Budgets, CSI volume support, and image digest pinning.

Highlights

• More resilient init app updates, especially at scale. Operator upgrades now update every managed HiveMQ pod with built-in rate limiting, integrity-checked downloads, and protection against half-applied updates or overlapping update attempts.

More Resilient Init App Updates

Every HiveMQ pod managed by the operator runs a small companion process called the init app. The init app starts and supervises the HiveMQ broker and applies updates in place. When you upgrade the HiveMQ Platform Operator, it rolls a matching update out to the init app in every managed pod, without a full redeploy.

Version 2.2.0 strengthens this update path at every stage. Large deployments upgrade smoothly, and a failed or interrupted update can no longer leave a pod in a broken state.

How it works

• Rate-limited rollouts. Operator upgrades now propagate to managed pods in controlled batches rather than to every pod at once, with the limit enabled by default.
• Integrity-checked, atomic updates. The operator verifies each update against a checksum and swaps it into place atomically. An interrupted or partial download can never replace a working init app with a corrupted one, even if the pod's container restarts partway through. An update must still complete successfully to resume normal operations, but a failed update no longer disrupts the running pod.
• Clean, predictable startup. When a pod starts, the init app applies any pending update before the broker comes up. A pod never starts the broker and updates itself at the same time, and it always comes up on the expected version.
• No overlapping update attempts. Previously, the init app could start multiple update attempts for the same pod at once. These attempts raced with one another and produced errors mid-update. Updates are now serialized so only one runs at a time. This fixes the race conditions and removes the misleading stack traces they created.

How it helps

• Large installations stay healthy during upgrades. Rolling updates out in batches keeps the Kubernetes API server from being overwhelmed when many pods would otherwise update at the same time.
• No more pods stuck after a failed update. A failed or interrupted update can no longer overwrite a working init app with a broken or partial one. A pod that previously could become blocked and require a manual fix now keeps running on its current version.
• Predictable upgrades. Restarted pods come up on the expected version right away, without an extra follow-up upgrade cycle. The broker is always properly supervised.
• Cleaner operations. The overlapping-update errors are fixed, and benign stack traces no longer appear in the logs. Update runs produce less log noise, so genuine problems are easier to spot.

Additional Features and Improvements

HiveMQ Platform Operator for Kubernetes

• Per-platform rolling restart pacing. You can now configure a minimum wait time between pod restarts for each HiveMQ platform individually through the new rollingRestart.lastPodMinAgeSeconds value. Previously, this was tunable only globally for the entire operator. Per-cluster spacing gives MQTT clients time to reconnect and rebalance between pods, which prevents reconnect storms during a rolling restart. This change introduces an updated custom resource definition (CRD).
• Updated operator metrics and Grafana dashboard. The operator's reconciliation metrics have been reworked, and the bundled Grafana dashboard now uses them. The new metrics are controller-scoped rather than per-resource, so the number of exported time series no longer grows with the number of managed HiveMQ platforms. Breaking change: several operator metric names have changed. If you maintain custom dashboards or alerts on the operator's metrics, update them to the new names. The documentation lists the new metrics.
• Now running on Java 25. The HiveMQ Platform Operator now runs on Java 25, the current Long-Term Support release of the Java platform.
• Quieter operator logs. Repetitive reconciliation messages now log on INFO instead of DEBUG. This keeps the operator logs focused on meaningful events rather than routine reconciliation noise.

HiveMQ Platform Operator Helm Charts

• Pod scheduling and disruption controls. The HiveMQ Platform chart now supports priorityClassName, nodeSelector, and a Pod Disruption Budget. These configuration options give you finer control over scheduling and availability. For example, to prevent pods from being evicted together during node maintenance.

• Generic CSI volume support. The HiveMQ Platform chart now supports the generic csi volume type as part of the existing additionalVolumes value. This enables integrations such as the CSI Secrets Store driver for Azure Key Vault, AWS Secrets Manager, GCP Secret Manager, and HashiCorp Vault.

      additionalVolumes:
      - type: csi
        mountName: secrets-store
        path: /mnt/secrets
        csiDriver: secrets-store.csi.k8s.io
        readOnly: true
        volumeAttributes:
          secretProviderClass: my-secret-provider
    

• Persistent Volume retention controls. The HiveMQ Platform chart now exposes Kubernetes' native persistentVolumeClaimRetentionPolicy for the platform StatefulSet. Kubernetes can now automatically clean up the Persistent Volume left behind by a removed surge pod. This avoids manual cleanup and unnecessary storage costs.

• Map-based extension configuration. A new map-based extensionMap option complements the existing array-based extensions in HiveMQ Platform chart. If you use hierarchical Helm value files, you can now override individual extension properties without duplicating the entire extension list at every override level.

      extensionMap:
      hivemq-enterprise-security-extension:
        enabled: true
        configMapName: hivemq-platform-ese-config
        supportsHotReload: true
    

• Configurable operator health probes. The platform operator readiness and liveness probe settings (initialDelaySeconds, periodSeconds, timeoutSeconds, successThreshold, and failureThreshold) are now configurable through HiveMQ Platform Operator chart values. The previous hardcoded values remain as defaults. This makes it possible to tune probe timing and silence noisy probe-failure warnings without patching the Deployment.

• Image digest pinning. The HiveMQ Platform Operator and HiveMQ Platform charts now allow the operator, operator init, and HiveMQ Platform images to be pinned by immutable digest via optional image.digest and image.initImageDigest values, rendered as repository/name:tag@digest. The previous tag-only behavior is preserved when no digest is configured.

• HiveMQ Platform License support. The HiveMQ Platform chart can now generate the license.xml configuration file through config.platformLicense. This makes it straightforward to configure a HiveMQ Platform License for your deployment.

• Per-namespace Grafana dashboards. The bundled HiveMQ Platform Grafana dashboards in the HiveMQ Platform chart now include a namespace template variable. You can filter metrics per namespace when multiple HiveMQ clusters run on the same Kubernetes cluster.

Bug Fixes

HiveMQ Platform Operator for Kubernetes

• Fixed an issue where extension restarts, log level changes, and init app updates could become permanently blocked after an external tool such as ArgoCD, Lens, or kubectl modified the StatefulSet pod template.
• Fixed a concurrency issue where parallel reconciliations could bypass the rolling-restart rate limit.
• Fixed duplicate Restarting Pod Kubernetes events and operator log messages during slow rolling restarts, and added a Kubernetes event and log message when pods are restarted while the custom resource is in an error state.

Get Started Today

To get started with the new HiveMQ Platform Operator, see our HiveMQ Platform Operator Quick Start Guide.

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.

To learn more about our operator, see HiveMQ Platform Operator for Kubernetes.