What's New in HiveMQ 4.36?
The HiveMQ team is excited to announce the release of HiveMQ Enterprise MQTT Platform 4.36. This release introduces our new HiveMQ Enterprise Security Extension Customization SDK, 72-hour metrics visibility in Control Center v2, new Data Hub custom registry and REST API support for custom module creation, and numerous performance and usability enhancements.
Highlights
- New HiveMQ Enterprise Security Extension Customization SDK
- Extended metrics availability in the new Control Center V2
- Modules for Data Hub via Custom Registry
- REST API for Custom Modules for Data Hub
New Enterprise Security Extension Customization SDK
The HiveMQ Enterprise Security Extension allows you to integrate HiveMQ Enterprise and Professional editions with external sources of authentication and authorization. The extension expands the role, user, and permission-management capabilities of your HiveMQ MQTT security architecture. Supported external sources of authentication and authorization include SQL databases, LDAP directories, and local files. Additionally, the extension supports advanced authentication flows such as OIDC, X.509 certificate-based authentication, and JWT tokens. To learn more, see HiveMQ Enterprise Security Extension.
Our HiveMQ 4.36 platform release adds a powerful new Customization SDK for the HiveMQ Enterprise Security Extension that offers enhanced flexibility to tailor your authentication and authorization workflows. The Customization SDK gives you the ability to programmatically create custom preprocessors for your authentication and authorization processing pipelines, enabling highly specific and adaptable security solutions.
How it works
The following steps are required to add a custom preprocessor to an authentication/authorization pipeline.
First, write a custom preprocessor in Java, build a jar from it, and place it in the new customization folder of ESE. A good place to start is the ESE hello world customization.
Next, reference the fully qualified class name of your custom preprocessor in your pipeline configuration. You can place the preprocessor before either the authentication or authorization step, depending on your workflow requirements.
The custom preprocessor runs as part of the pipeline, similar to the predefined preprocessors ESE offers. For more details, see the ESE Customization SDK documentation.
How it helps
The new customization SDK enhances the flexibility of the HiveMQ Enterprise Security Extension to cover your security requirements. Modifying ESE variables during the preprocessing phases, retrieving additional authentication and authorization data from custom external sources, or implementing a tailored solution such as client whitelisting are just a few of the possibilities.
72 hours of metrics available in the new Control Center V2
In HiveMQ 4.32, we introduced an open beta of our new HiveMQ Control Center v2 interface. Today, we’re excited to announce that Control Center v2 can now display up to 72 hours of analytics data on the Analytics dashboard. This enhancement gives HiveMQ users extended visibility into daily trends, enables more detailed investigation of issues, and can provide deeper insights for effective MQTT client management.
How it works
The Control Center v2 Analytics dashboard now lets you select a custom time frame for viewing data. By default, the dashboard displays the most recent data, but you can extend the view to analyze trends across your HiveMQ cluster for up to 72 hours.
Please note that analytics data is collected only from live nodes. Once a node stops, the node data is no longer visible. The Control Center v2 provides insights into current trends and is not a replacement for a full monitoring stack such as Prometheus and Grafana.
While we continue refining Control Center v2 for production environments, the existing Control Center v1 remains the default interface for managing your HiveMQ broker. Since the new interface is not yet recommended for production use, access to Control Center v2 is currently limited to users with the superadmin
role.
Modules for Data Hub via Custom Registry
Recent platform releases have introduced several new Data Hub features regarding modules. Notably, we added the possibility of creating custom modules for Data Hub to package custom configurations. These modules can be loaded into the Control Center manually. Now, we are happy to announce the release of Custom Registries that allow organizations to centrally manage their custom modules across multiple environments.
How it works
Customers can build and host a module registry for Data Hub using an HTTP server within the local network. Once configured, a custom module can be instantiated the same way as one of the pre-configured HiveMQ modules. All available modules from your configured registry appear in the Control Center. One custom registry can serve multiple HiveMQ deployments.
The registry must include an index file and relevant information to instantiate a module. The custom registry must also contain the modules themselves. For detailed information, see Creating a Custom Module.
.Example HiveMQ broker configuration to access a custom registry:
Each custom registry configuration must contain a name to be shown in the Control Center, a unique identifier within your HiveMQ deployment, and the URL where the registry is located. You can configure multiple registries with different names to fulfill your business needs, for example, to support multiple environments.
All registries appear in the Control Center:
The example displays the registry named ACME Prod Registry. The view is specifically filtered to show only the ACME Prod Registry along with all its available modules.
How it helps
Custom registries streamline the use of custom modules within your organization. When a new module is created or a new version is released, it can be easily shared within your organization by publishing it in the registry. Every HiveMQ deployment can easily use the registry. The centrally managed modules also enable centralized governance of the modules themselves. Certain policies that must be held across multiple vendors or organizations can be centrally organized.
REST API for Custom Modules in Data Hub
Data Hub offers a comprehensive REST API for managing policies, schemas, and scripts. Based on customer feedback, HiveMQ 4.36 adds the capability to manage modules via the REST API. For example, enabling full support of automated CI pipelines. Once a new module version is compiled into a single module file within a CI pipeline, you can use the REST API to roll out a module fully automatically. The HiveMQ broker seamlessly handles the configuration updates behind the scenes.
How it works
Our documentation provides an overview of the REST API based on the OpenAPI specification. The following example shows how to create an instance of our hello-world module, version 1.0.0:
The example command converts the module into a base64 representation, creates the body for the POST request, and pipes the result via curl to the REST API of the broker. Note that in the example, port 8888 is configured for the REST API, the port can differ in your deployment. Eventually, an instance of the module is created with the provided module configuration. Detailed information about the instance is returned as follows:
How it helps
Custom modules on Data Hub can be organized in a version control system such as GitHub. For example, our hello-world custom module contains all the relevant files to build a simplistic module for Data Hub. It also contains a GitHub Action to compile a new version with all necessary steps. You can customize it to fit into your workflow. Additionally, with the REST API, you can seamlessly automate the deployment of the latest module version to your HiveMQ deployment.
More Noteworthy Features and Improvements
HiveMQ Enterprise MQTT Broker
- Improved the performance of brokers with many concurrent connections during topology changes.
- Fixed an issue in overload protection level calculations that could unnecessarily delay the transition between levels.
- Fixed an issue that could cause some message queue metrics to erroneously include no longer queued messages.
- Fixed an issue that could negatively impact client connect performance when a connect takeover occurs during the client's CONNECT packet handling.
- Fixed an issue that could cause incorrect reporting of free disk space when running HiveMQ in a Kubernetes environment.
HiveMQ Data Hub
- Added metrics to track all enabled and disabled module instances.
- Fixed an issue to ensure Data Hub scripting is correctly disabled when minimum system requirements are not present.
HiveMQ Enterprise Security Extension
- Added JWT authentication manager for MQTT pipelines support to the chain authentication manager.
- Removed invalid tokens from the debug logging of the JWT authentication manager to increase confidentiality.
HiveMQ Control Center v2
- Added a notification to alert users when the default Control Center login credentials are used to log in.
IMPORTANT: Java 21 will soon be required to run the HiveMQ Platform.
Since the HiveMQ 4.28 release in April 2024, Java 21 is recommended to run the HiveMQ Platform. For all HiveMQ versions released after April 2025, Java 21 will be required.
If you use the official HiveMQ container images, no action is required because these images have shipped with Java 21 since HiveMQ 4.28. If you do not run HiveMQ as a container, or you build your own container image, we recommend updating to Java 21 before the April 2025 deadline.
Get Started Today
To upgrade to HiveMQ 4.36 from a previous HiveMQ version, follow our HiveMQ Upgrade Guide. To learn more about all the features the HiveMQ Platform offers, explore the HiveMQ User Guide.
HiveMQ Team
The HiveMQ team loves writing about MQTT, Sparkplug, Industrial IoT, protocols, how to deploy our platform, and more. We focus on industries ranging from energy, to transportation and logistics, to automotive manufacturing. Our experts are here to help, contact us with any questions.