# HiveMQ Documentation > The HiveMQ Enterprise MQTT Broker powers the HiveMQ data streaming layer, delivering scalable, reliable, event-driven IIoT messaging. This documentation covers the HiveMQ Enterprise MQTT Broker, extensions, cloud service, edge gateway, Kubernetes operator, and the HiveMQ Platform. ## Core Platform - [Getting Started](https://docs.hivemq.com/hivemq/latest/user-guide/getting-started.html): Quick start guide for the HiveMQ Enterprise MQTT broker The HiveMQ broker is part of the HiveMQ Platform, an industrial data platform for agentic AI designed to bring operational data from the edge into the enterprise. This quick start guide shows you how to choose a deployment path, connect MQTT clients, and move data by running the HiveMQ broker on premises, in Docker, or in the cloud. - [System Requirements](https://docs.hivemq.com/hivemq/latest/user-guide/system-requirements.html): Hardware, OS, and JVM requirements The HiveMQ broker is a high-performance MQTT broker designed to run on server hardware, though it can also run on embedded devices. HiveMQ requires 4GB RAM minimum, 4 or more CPUs, and 100GB disk space exclusively allocated, with OpenJDK JRE 21 for production. - [Configuration](https://docs.hivemq.com/hivemq/latest/user-guide/configuration.html): Complete broker configuration reference The default settings of the HiveMQ broker are suitable for most typical use cases. The HiveMQ broker uses XML-based configuration files located in the conf folder and reads the config.xml file one time during startup, requiring a restart to apply changes. - [Installation](https://docs.hivemq.com/hivemq/latest/user-guide/install-hivemq.html): Installation methods for Linux, Windows, and bare metal This guide walks you through basic installation and optimization steps for the HiveMQ Enterprise MQTT Broker. You can download the HiveMQ broker in a convenient ZIP package with all executable files, initialization scripts, and example configurations needed for successful installation. - [Docker Deployment](https://docs.hivemq.com/hivemq/latest/user-guide/docker.html): Running the HiveMQ broker in Docker containers Docker is a popular open-source platform that eases the deployment and delivery of applications in a containerized environment. HiveMQ provides a continuously updated Docker repository on Docker Hub to streamline development, deployment, and management. - [Clustering](https://docs.hivemq.com/hivemq/latest/user-guide/cluster.html): High availability and cluster configuration One of the outstanding features of the HiveMQ broker is the ability to form resilient, highly available, and ultra-scalable MQTT broker clusters. The HiveMQ broker employs a sophisticated masterless cluster design that provides true horizontal scalability where each broker node can handle hundreds of thousands to millions of concurrently connected MQTT clients. - [Listeners](https://docs.hivemq.com/hivemq/latest/user-guide/listeners.html): TCP, WebSocket, and TLS listener configuration MQTT listeners specify the IP address and port on which HiveMQ accepts incoming connections from MQTT clients. By default, the HiveMQ broker binds to the IANA-standard port 1883 and supports multiple listener types, including TCP, TLS, WebSocket, and Secure WebSocket. - [Security](https://docs.hivemq.com/hivemq/latest/user-guide/security.html): TLS, authentication, and authorization The HiveMQ Enterprise MQTT Broker is designed from the ground up with maximum security in mind. For mission-critical IoT scenarios, secure end-to-end encrypted communication and advanced authentication and authorization features are essential. The HiveMQ broker offers the flexibility to enable the specific security features your deployment requires. - [Monitoring](https://docs.hivemq.com/hivemq/latest/user-guide/monitoring.html): Metrics, JMX, and monitoring integration System monitoring is an essential part of every production software deployment, especially in clustered MQTT broker environments. The highly performant metrics subsystem of the HiveMQ broker lets you monitor relevant metrics with no reduction in system performance, even in low-latency, high-throughput environments. - [Health API](https://docs.hivemq.com/hivemq/latest/user-guide/health-api.html): Readiness and liveness endpoints The endpoints of the HiveMQ Health API provide operational information about your HiveMQ broker components and extensions. With the Health API, you can capture snapshots that show the current state of health for each node in your HiveMQ broker cluster to help quickly identify potential issues. - [Logging](https://docs.hivemq.com/hivemq/latest/user-guide/logging.html): Log configuration and dynamic log levels The HiveMQ broker implements a powerful Logback logging system that helps you monitor, diagnose, and troubleshoot your applications. The default HiveMQ broker logging configuration is suitable for most use cases and writes all log data to the log folder of your HiveMQ broker installation. - [Shared Subscriptions](https://docs.hivemq.com/hivemq/latest/user-guide/shared-subscriptions.html): Load balancing across subscribers Shared subscriptions allow the HiveMQ broker to balance the load of a single subscription across multiple MQTT clients. In a regular MQTT subscription, each client receives a copy of every message, while in a shared subscription, clients receive messages in an alternating fashion. - [Troubleshooting](https://docs.hivemq.com/hivemq/latest/user-guide/troubleshooting.html): Common issues and diagnostics This section provides guidance on troubleshooting common HiveMQ broker deployment issues. It covers topics such as running the HiveMQ broker on reserved ports between 1 and 1024 on Linux machines using authbind. - [Restrictions](https://docs.hivemq.com/hivemq/latest/user-guide/restrictions.html): Connection limits, bandwidth throttling, and MQTT message size limits CPU, memory, and bandwidth are limited resources. HiveMQ broker connection limits and connection-rate throttling properties are defined in config.xml to limit TCP connections, restrict bandwidth usage, and protect against malicious client attacks. Includes maximum connection limits, incoming bandwidth throttling, and MQTT Client ID and Topic length limits. - [Overload Protection](https://docs.hivemq.com/hivemq/latest/user-guide/overload-protection.html): Back pressure and cluster overload protection mechanisms The HiveMQ broker provides built-in cluster overload protection that restricts incoming traffic if the rate of MQTT messages becomes too high. Each node determines its own overload protection level every 100 milliseconds and broadcasts changes to the cluster, selectively applying back pressure on specific MQTT clients during periods of exceptionally high load. - [Proxy Protocol](https://docs.hivemq.com/hivemq/latest/user-guide/proxy-protocol.html): PROXY protocol support for load balancer deployments The HiveMQ broker supports the PROXY protocol (v1 and v2) for all listeners, allowing transportation of client details like IP address, port, and SSL information over multiple proxies. This is essential when running the HiveMQ broker behind a load balancer. Without PROXY protocol, the HiveMQ broker only sees the load balancer connection and loses original client information. - [Changelog](https://www.hivemq.com/changelog/): Release notes with features, fixes, and deprecations for HiveMQ products The HiveMQ Changelog provides a chronological history of releases across HiveMQ Platform, HiveMQ CE, HiveMQ Edge, HiveMQ Cloud, and HiveMQ Platform Operator for Kubernetes. Each entry includes the release date, version number, and a summary of new features, improvements, bug fixes, and deprecations. - [Changelog RSS Feed](https://www.hivemq.com/changelogs.xml): Machine-readable RSS 2.0 feed of all HiveMQ product releases Subscribe to the RSS feed to track new HiveMQ releases programmatically. The feed uses standard RSS 2.0 format with title, description, link, and publication date for each release. ## Extensions SDK - [Extension Developer Guide](https://docs.hivemq.com/hivemq/latest/extensions/index.html): Overview of the HiveMQ extension system The HiveMQ ecosystem includes numerous open-source and commercial tools and solutions that enable moving data from device to cloud in a secure, reliable, and scalable manner. Our flexible extension framework provides an open API that allows developers to create custom extensions for their specific infrastructures. - [Quick Start (Gradle)](https://docs.hivemq.com/hivemq/latest/extensions/quick-start-gradle.html): Build your first HiveMQ broker extension with Gradle This quick start guide covers the basics needed to get started with extension development for the HiveMQ broker using Gradle. You can use the HiveMQ Hello World Extension as a template that sets up everything you need, including the HiveMQ Gradle Plugin and integration testing examples. - [Interceptors](https://docs.hivemq.com/hivemq/latest/extensions/interceptors.html): MQTT packet interception and modification HiveMQ Interceptors provide a convenient way for extensions to intercept and modify MQTT messages. Based on the interceptor type, you can register a ClientInitializer or use the GlobalInterceptorRegistry to add the interceptor you want. - [Services](https://docs.hivemq.com/hivemq/latest/extensions/services.html): Extension services API reference HiveMQ services provide a convenient way for extensions to interact with the HiveMQ broker core. You can access HiveMQ Extension SDK services through the Services class to access functionality for client management, subscriptions, retained messages, and more. - [Authentication](https://docs.hivemq.com/hivemq/latest/extensions/authentication.html): Custom authentication providers HiveMQ broker extensions can use different types of authenticators to authenticate MQTT clients registered in the Security Registry. Each extension can register an authenticator, and when multiple security extensions are used, the associated authenticators are called in order, with the highest priority first. - [Authorization](https://docs.hivemq.com/hivemq/latest/extensions/authorization.html): Custom authorization providers The HiveMQ Extension System offers multiple options for authorizing clients to publish and subscribe. The simplest option is the Default Permissions set when a client connects, while Publish Authorizer and Subscription Authorizer provide more flexible per-packet authorization. - [Extension Deployment](https://docs.hivemq.com/hivemq/latest/extensions/deployment.html): Building, packaging, and deploying extensions After creating your extension project with the HiveMQ Extension Archetype, use the Maven package goal to build a distribution ZIP file. Every HiveMQ broker extension requires a hivemq-extension.xml file alongside the extension JAR, and you can extend the packaging phase to bundle everything automatically. - [Registries](https://docs.hivemq.com/hivemq/latest/extensions/registries.html): Initializer, Security, and Event registry API reference HiveMQ registries provide a convenient way for extensions to register callbacks with the HiveMQ broker core. Available registries include the Initializer Registry (client initializers), Security Registry (authentication and authorization), Event Registry (client lifecycle events), and Metric Registry (custom metrics access). - [Quick Start (Maven)](https://docs.hivemq.com/hivemq/latest/extensions/quick-start-maven.html): Build your first extension with Maven This quick start guide covers extension development for the HiveMQ broker using Apache Maven. Use the preconfigured HiveMQ Maven Archetype to create a fully functional HelloWorld extension project as a basis for developing custom extensions, with all HiveMQ broker dependencies available in Maven Central. - [Testing Extensions](https://docs.hivemq.com/hivemq/latest/extensions/testing-extension.html): Integration testing with HiveMQ Testcontainers Write automated tests for your HiveMQ broker extension using the official HiveMQ Testcontainers Module or the HiveMQ Testcontainers library. These libraries automatically create HiveMQ broker Docker containers and deploy your extension inside for integration testing with Gradle or Maven. ## Data Hub - [Data Hub Overview](https://docs.hivemq.com/hivemq/latest/data-hub/index.html): Policy-driven data governance for MQTT HiveMQ Data Hub provides mechanisms to define how MQTT data and MQTT client behavior are handled in the HiveMQ broker. Data Validation allows you to implement declarative policies to check data format, while Behavior Validation gives you the ability to model client behavior throughout the entire lifecycle. - [Schemas](https://docs.hivemq.com/hivemq/latest/data-hub/schemas.html): Data validation with JSON Schema, Protobuf, or Avro Data validation relies on the interaction between predefined schemas and policies. The HiveMQ Data Hub supports schema definitions with JSON Schema (Draft-04, -06, -07, 2019-09, 2020-12) and Protobuf formats (Version 2 and 3). - [Policies](https://docs.hivemq.com/hivemq/latest/data-hub/policies.html): Policy definition and enforcement The integrated policy engines of HiveMQ Data Hub give you the ability to build individual data governance policies that maximize the value of your data pipelines. HiveMQ Data Hub supports two types of policies: data policies and behavior policies. - [Transformations](https://docs.hivemq.com/hivemq/latest/data-hub/transformations.html): Data transformation pipelines IoT devices send a wide range of data sets, and the MQTT data you receive often contains diverse data points, formats, and units. The HiveMQ Data Hub transformation feature gives you the ability to add custom JavaScript-based transformation functions to your Data Hub data policies. - [Behavior Models](https://docs.hivemq.com/hivemq/latest/data-hub/behavior-models.html): Client behavior validation The HiveMQ Data Hub uses state machines to model the behavior of an MQTT client as it moves through your HiveMQ broker. Behavior validation relies on the interaction between predefined state machine models and policies that offer a simple and powerful way to represent client behavior. - [Data Hub Quick Start](https://docs.hivemq.com/hivemq/latest/data-hub/quick-start.html): Get started with data policies and schema validation This quick start guide shows you how to get started with HiveMQ Data Hub using the HiveMQ Control Center interactive UI or the HiveMQ REST API from the command line. Focuses on creating JSON data schemas and data policies, requiring HiveMQ Professional or Enterprise version 4.20.0 or higher. - [Data Validation](https://docs.hivemq.com/hivemq/latest/data-hub/validation.html): Schema-based payload validation for MQTT messages Validators ensure that MQTT messages on your HiveMQ broker fulfill your requirements. Schema validators check the format of the MQTT message payload, including field existence and value limits. Since MQTT is data-agnostic, validation prevents invalid or incorrectly formatted data from causing unpredictable behavior in downstream services. - [Actions](https://docs.hivemq.com/hivemq/latest/data-hub/actions.html): Actions triggered by policy violations and state transitions In HiveMQ Data Hub, an action is a collection of operations the broker performs in response to the outcome of a data validation or a state transition in behavior validation. Actions define what happens when validation succeeds or fails, with configurable onSuccess and onFailure pipelines. - [Use Cases](https://docs.hivemq.com/hivemq/latest/data-hub/use-cases.html): Practical examples for data governance scenarios A collection of user stories for HiveMQ Data Hub highlighting practical ways to use schemas and policies. Topics include: enforcing valid JSON, multiple Protobuf policies on different topics, accepting multiple schemas on a single topic, redirecting legacy schema versions, and updating existing policies. - [Data Hub Metrics](https://docs.hivemq.com/hivemq/latest/data-hub/metrics.html): Monitoring metrics for policies, schemas, and validations When enabled, HiveMQ Data Hub exposes metrics for data validation (payload validation counts, schema validation counts, policy outcomes) and behavior validation (client coverage, state transitions, behavior terminations, schema deserializations) as counters, gauges, and timers. ## REST API - [REST API](https://docs.hivemq.com/hivemq/latest/rest-api/index.html): HiveMQ management REST API documentation The HiveMQ REST API provides an interface for applications to interact programmatically with the HiveMQ Enterprise MQTT broker. HiveMQ administrators can use the REST API to automate Control Center actions they would normally perform manually, such as starting trace recordings or getting lists of connected clients. - [OpenAPI Specification](https://docs.hivemq.com/hivemq/latest/rest-api/openapi.yaml): HiveMQ REST API OpenAPI 3.0 specification (YAML) The machine-readable OpenAPI 3.0 schema definition of the HiveMQ REST API. Import into API tools such as Postman or use to generate client code in any programming language. This is a stable URL that always points to the latest version of the specification. ## Control Center - [Control Center](https://docs.hivemq.com/hivemq-control-center/latest/index.html): Web-based management UI for HiveMQ HiveMQ Control Center v2 is the new operational dashboard for your HiveMQ Broker that automatically ships alongside the existing Control Center v1. Starting with HiveMQ 4.39, HiveMQ Control Center v2 is generally available and can be used in production. - [Configuration](https://docs.hivemq.com/hivemq-control-center/latest/configuration.html): Access control, user setup, session timeouts, and security settings The HiveMQ Control Center works out of the box without any additional installation or configuration. Fine-tune your control center configuration to match your individual use case, including configuring custom users and passwords, access control, user session timeouts, and security settings. The default login is admin/hivemq. - [Clients](https://docs.hivemq.com/hivemq-control-center/latest/clients.html): Client session management, search, and detailed information The HiveMQ Control Center provides tools to list, view, and manage all MQTT clients known to your HiveMQ broker. Access detailed information about each client, including subscriptions, connection status, TLS, and more. The Clients view gives you deep insights into every client connected to your HiveMQ broker. - [Dashboard](https://docs.hivemq.com/hivemq-control-center/latest/dashboard.html): Real-time cluster metrics and monitoring graphs The Overview dashboard offers a concise view of the current state of your HiveMQ broker with immediate insights into key issues. Thumbnail graphs across the top provide a quick snapshot of key metrics such as current usage and cluster throughput. Use the Nodes dropdown to view data for all nodes or a specific cluster node. - [Trace Recordings](https://docs.hivemq.com/hivemq-control-center/latest/trace-recordings.html): Log and analyze MQTT traffic for specific clients or topics The Trace Recording feature allows you to log traffic for selected clients or topics using regular expression filters, providing real-time visibility for efficient troubleshooting and analysis. Each node creates its own .trace file and download bundles combine all node-specific files into a compressed archive for cluster-wide analysis. - [Integrations](https://docs.hivemq.com/hivemq-control-center/latest/integrations.html): View and manage installed HiveMQ extensions and integrations HiveMQ supports a wide range of functional add-ons and integrations. The Available Integrations view provides descriptions and download links for commercial and open-source integrations. Enterprise Extensions come preinstalled and disabled by default — enable them by removing the DISABLED file from the extension folder. ## Enterprise Extensions - [Kafka Extension](https://docs.hivemq.com/hivemq-kafka-extension/latest/index.html): Bidirectional MQTT-Kafka bridge Apache Kafka is a popular open-source streaming platform that makes it easy to share data between enterprise systems and applications. The HiveMQ Enterprise Extension for Kafka implements the native Kafka protocol inside your HiveMQ broker for bi-directional MQTT messaging to and from Kafka clusters. - [Kafka Extension Customization](https://docs.hivemq.com/hivemq-kafka-extension/latest/customization.html): Custom transformers for MQTT-Kafka message mapping The HiveMQ Kafka Extension Customization SDK gives you the ability to customize the management of your Kafka topics and implement custom logic for bidirectional message transfer between HiveMQ and your Kafka clusters. Use the API to programmatically specify sophisticated custom handling of message transformations. - [Bridge Extension](https://docs.hivemq.com/hivemq-bridge-extension/latest/index.html): MQTT broker-to-broker bridging The HiveMQ Enterprise Bridge Extension enables HiveMQ to bridge to one or more MQTT brokers for scalable, reliable, and bi-directional exchange of MQTT messages. It supports customizable topic mapping configuration for bidirectional message exchange with remote MQTT brokers. - [Enterprise Security Extension](https://docs.hivemq.com/hivemq-enterprise-security-extension/latest/index.html): LDAP, OAuth, JWT, and database authentication The HiveMQ Enterprise Security Extension expands the role, user, and permission-management capabilities of HiveMQ Enterprise and Professional editions. ESE allows you to use different sources of external authentication and authorization data to authenticate and authorize MQTT clients. - [ESE Getting Started](https://docs.hivemq.com/hivemq-enterprise-security-extension/latest/getting-started.html): Installation, configuration, and SQL database setup Step-by-step guide to install and configure the HiveMQ Enterprise Security Extension. Covers placing the license file, enabling the extension, configuring the config.xml, and setting up SQL database connections for authentication and authorization. - [ESE Reference](https://docs.hivemq.com/hivemq-enterprise-security-extension/latest/ese.html): Realms, pipelines, authentication, authorization, and access control Comprehensive reference for the HiveMQ Enterprise Security Extension covering realms, pipelines, authentication methods (SQL, LDAP, JWT, OAuth, OIDC), authorization, and access control. Includes configuration for password hashing (MD5, SHA-512, bcrypt, PKCS5S2, Argon2), TLS client certificates, and HTTP-based authentication. - [Google Cloud Pub/Sub Extension](https://docs.hivemq.com/hivemq-google-cloud-pubsub-extension/latest/index.html): MQTT to Google Cloud Pub/Sub integration Pub/Sub is a fully managed messaging service of the Google Cloud platform that allows sending and receiving messages between applications. The HiveMQ Enterprise Extension for Google Cloud Pub/Sub enables you to seamlessly integrate MQTT device data with other Google Cloud services through the Pub/Sub service. - [Google Cloud Pub/Sub Quick Start](https://docs.hivemq.com/hivemq-google-cloud-pubsub-extension/latest/quick-start.html): Google Cloud setup and extension configuration Quick start guide for setting up the HiveMQ Enterprise Extension for Google Cloud Pub/Sub. Covers Google Cloud account setup, project creation, Pub/Sub topic and subscription configuration, service account credentials, and HiveMQ extension installation and configuration. - [Amazon Kinesis Extension](https://docs.hivemq.com/hivemq-amazon-kinesis-extension/latest/index.html): MQTT to AWS Kinesis integration Amazon Kinesis is a suite of fully managed AWS services designed to ingest, process, and analyze large-scale data streams in real-time. The HiveMQ Enterprise Extension for Amazon Kinesis makes it easy to move MQTT messaging data between your HiveMQ broker and the Amazon Kinesis Data Streams service. - [Data Lake Extension](https://docs.hivemq.com/hivemq-data-lake-extension/latest/index.html): Stream MQTT data to data lakes Data lakes are centralized repositories that allow organizations to store vast amounts of raw and processed data in its native format. The HiveMQ Enterprise Data Lake Extension makes it possible to forward MQTT messages directly to your data lake without the need for additional infrastructure. - [MongoDB Extension](https://docs.hivemq.com/hivemq-mongodb-extension/latest/index.html): Persist MQTT data to MongoDB MongoDB is an open-source, document-oriented database system designed for scalability, high availability, and performance. MongoDB uses a JSON-like format called BSON to store documents organized in collections, analogous to tables in a relational database. - [PostgreSQL Extension](https://docs.hivemq.com/hivemq-postgresql-extension/latest/index.html): Persist MQTT data to PostgreSQL PostgreSQL is an open-source relational database management system widely used to safely store and manage large amounts of data. PostgreSQL supports most features of the current SQL standard and is suitable for various types of applications. - [MySQL Extension](https://docs.hivemq.com/hivemq-mysql-extension/latest/index.html): Persist MQTT data to MySQL MySQL is an open-source relational database management system widely used to store and manage structured data. The HiveMQ Enterprise Extension for MySQL enables you to forward MQTT messages from IoT devices to one or more MySQL databases. - [Microsoft SQL Server Extension](https://docs.hivemq.com/hivemq-microsoft-sql-server-extension/latest/index.html): Persist MQTT data to Microsoft SQL Server Microsoft SQL Server is a relational database management system from Microsoft used across on-premise and cloud environments to store, manage, and analyze data. The extension enables you to forward MQTT messages from connected IoT devices to one or more Microsoft SQL Server or Azure SQL databases. - [Snowflake Extension](https://docs.hivemq.com/hivemq-snowflake-extension/latest/index.html): Stream MQTT data to Snowflake Snowflake is a popular cloud-based data management and data warehousing platform designed to store, process, and analyze data. The HiveMQ Enterprise Extension for Snowflake makes it possible to forward MQTT messages directly to Snowflake via the Snowpipe Streaming SDK without additional infrastructure. - [Distributed Tracing Extension](https://docs.hivemq.com/hivemq-distributed-tracing-extension/latest/index.html): OpenTelemetry tracing for MQTT The HiveMQ Enterprise Distributed Tracing Extension is a first-of-its-kind monitoring tool that lets you track the performance of MQTT PUBLISH messages within an MQTT broker. The extension uses an open-standards OpenTelemetry-based approach to add tracing capabilities to the HiveMQ broker and its integrations. - [Distributed Tracing Spans](https://docs.hivemq.com/hivemq-distributed-tracing-extension/latest/distributed-tracing-spans.html): OpenTelemetry span details and semantic conventions HiveMQ distributed tracing spans represent work done within a specific trace, including time intervals and associated metadata. All captured spans are correlated with OpenTelemetry Resources, including Service, Host, Operating System, and Cloud provider attributes. Follows OpenTelemetry semantic conventions for messaging. ## Kubernetes Deployment - [HiveMQ Platform Operator](https://docs.hivemq.com/hivemq-platform-operator/index.html): Deploy HiveMQ on Kubernetes with the platform operator The HiveMQ Platform Operator for Kubernetes is a tool for managing your HiveMQ deployments in a Kubernetes environment. The operator allows you to install, scale, configure, and monitor your HiveMQ Platform deployments in a versatile, adaptable manner that automatically reconciles configuration changes. - [Platform Operator Configuration](https://docs.hivemq.com/hivemq-platform-operator/configuration.html): HiveMQ Platform Helm chart installation and configuration options Helm offers a streamlined and manageable approach to installing HiveMQ on Kubernetes. HiveMQ provides two preconfigured Helm charts, one for the HiveMQ Platform Operator and one for the HiveMQ Platform, with detailed configuration options for operators and platform clusters. - [Advanced Installation](https://docs.hivemq.com/hivemq-platform-operator/configuration-kubectl.html): Install the operator and platform with kubectl using manifest files instead of Helm The HiveMQ Platform Operator and the HiveMQ Platform can also be installed without Helm by applying manifest files with the kubectl command-line tool. HiveMQ provides up-to-date manifest files in the Helm chart repository that you can download and customize for your deployment, or generate from the Helm charts with helm template. - [Custom Resource Definition](https://docs.hivemq.com/hivemq-platform-operator/crd.html): CRD specification for HiveMQ Platform deployments on Kubernetes The HiveMQ Platform Custom Resource Definition (CRD) provides all the necessary definitions and configurations to deploy your HiveMQ platform to a Kubernetes system version 1.24 or higher. A single HiveMQ Platform Operator can manage one or more HiveMQ platforms. - [Kubernetes Distributions](https://docs.hivemq.com/hivemq-platform-operator/k8s-distributions.html): Deployment on EKS, AKS, GKE, and OpenShift Step-by-step procedures for deploying the HiveMQ Platform Operator on popular Kubernetes distributions, including Red Hat OpenShift, Amazon EKS, Azure AKS, and Google GKE, with vendor-specific configuration requirements. - [Examples](https://docs.hivemq.com/hivemq-platform-operator/examples.html): Deployment examples and Helm chart configurations Examples showing how to customize HiveMQ Platform deployment with Helm charts, including installing the Kafka extension, custom JDBC drivers, Google Cloud Pub/Sub extension, MQTT Message Log extension, File RBAC extension, projected volumes, RBAC permissions, and triggering rolling restarts. - [Observability](https://docs.hivemq.com/hivemq-platform-operator/observability.html): Monitoring, metrics, and logging for operator deployments Events provide detailed information to monitor HiveMQ platforms on Kubernetes. The HiveMQ Platform Operator publishes events whenever the state of a managed HiveMQ platform changes, enabling effective alerting and monitoring of operations. - [Upgrade Guide](https://docs.hivemq.com/hivemq-platform-operator/upgrade-guide.html): Operator version migration procedures The HiveMQ Platform Operator Upgrade Guides show you how to upgrade to the latest operator version with detailed information on upgrading Helm charts, the operator, and the HiveMQ Platform. Upgrades always trigger a rolling restart. - [Legacy Operator Migration Guide](https://docs.hivemq.com/hivemq-platform-operator/migration-guide.html): Migrate from the HiveMQ Legacy Operator to the HiveMQ Platform Operator The HiveMQ Platform Operator represents a significant evolution from the HiveMQ Legacy Operator and is not a drop-in replacement. This guide covers the key differences, such as the HiveMQPlatform CRD versus the legacy HiveMQCluster CRD, the two-chart Helm structure, and the use of standard HiveMQ container images, and walks through planning and executing a migration. The Legacy Operator and Platform Operator can run side by side in the same Kubernetes cluster during migration. ## HiveMQ Cloud - [HiveMQ Cloud](https://docs.hivemq.com/hivemq-cloud/index.html): Fully managed MQTT cloud service HiveMQ Cloud is a fully-managed, cloud-native IoT messaging platform that makes trustworthy and scalable IoT device connectivity simple with no installation or server management required. HiveMQ is the industry leader for enterprise-ready, beautifully scalable, large-scale IoT deployments with MQTT. - [Quick Start Guide](https://docs.hivemq.com/hivemq-cloud/quick-start-guide.html): Create a cluster and connect your first MQTT client This guide walks you through signing up, selecting a plan (Serverless or Starter), creating your first cluster, setting up credentials, and testing the connection with MQTT CLI or the Web Client. - [Console](https://docs.hivemq.com/hivemq-cloud/console.html): Web console for cluster, organization, and integration management The HiveMQ Cloud Console is the web-based management interface for managing organizations, clusters, access management, and integrations with Apache Kafka, Confluent, Amazon Kinesis, and Aiven. - [Authentication & Authorization](https://docs.hivemq.com/hivemq-cloud/authn-authz.html): Credentials, client certificates, JWT, and role-based access control HiveMQ Cloud supports multiple authentication methods, including username-password credentials, client certificates, and JWT tokens. Role-based access control (RBAC) with default and custom roles provides fine-grained topic-level permissions. - [Metrics](https://docs.hivemq.com/hivemq-cloud/metrics.html): Cluster monitoring and observability metrics HiveMQ Cloud provides operational metrics for monitoring cluster health, including counters and gauges for keep-alive, message queuing, dropped messages, and other key indicators. Metric availability varies by plan (Starter vs Enterprise). - [Troubleshooting](https://docs.hivemq.com/hivemq-cloud/troubleshooting.html): Log streaming, diagnostics, and issue resolution The troubleshooting logs view provides real-time log streaming with filtering by client ID, timestamp, and event type. Access logs and event logs help diagnose connectivity and operational issues. - [REST API](https://docs.hivemq.com/hivemq-cloud/rest-api.html): Manage credentials, permissions, and roles programmatically The HiveMQ Cloud REST API enables programmatic management of MQTT credentials, permissions, and roles. You can create, view, update, and delete access credentials, attach permissions to roles, and automate cluster administration. - [Cloud REST API OpenAPI Specification](https://docs.hivemq.com/hivemq-cloud/rest-api/openapi.yaml): HiveMQ Cloud REST API OpenAPI specification (YAML) The machine-readable OpenAPI schema for the HiveMQ Cloud SaaS REST API. Use to generate client code or import into API tools. - [Cloud Enterprise REST API OpenAPI Specification](https://docs.hivemq.com/hivemq-cloud/rest-api/enterprise/openapi.yaml): HiveMQ Cloud Enterprise REST API OpenAPI specification (YAML) The machine-readable OpenAPI schema for the HiveMQ Cloud Enterprise REST API, including AsyncAPI event streaming endpoints. - [Cloud Enterprise](https://docs.hivemq.com/hivemq-cloud/cloud-enterprise.html): Managed, enterprise-grade MQTT backbone for production-critical connected systems HiveMQ Cloud Enterprise is the managed, enterprise-grade MQTT backbone for organizations that need the scale, security, and reliability of HiveMQ Enterprise without running the broker themselves. Configuration is handled by HiveMQ support (not self-service). Value pillars: a dedicated MQTT broker with custom scale, enterprise-grade security, advanced observability, and premium support. - [Cloud Enterprise Availability](https://docs.hivemq.com/hivemq-cloud/cloud-enterprise-availability.html): Supported cloud providers and per-cloud access differences HiveMQ Cloud Enterprise is available on AWS, Azure, and Google Cloud. The feature set is the same across clouds. All deployments are reachable over the public Internet by default; private connectivity is available on request through each cloud's native private-link service (AWS PrivateLink, Azure Private Link, Google Cloud Private Service Connect). - [Cloud Enterprise Access](https://docs.hivemq.com/hivemq-cloud/cloud-enterprise-access.html): Listeners, custom domains, private networking, and TLS/authentication How clients reach a HiveMQ Cloud Enterprise deployment. The default public listener uses the FQDN scheme prod..hivemq.cloud (environment as the leftmost label), with MQTTS on port 8883 and WSS on port 443. Custom domains use ACME with Let's Encrypt. Private networking is PrivateLink only (no VPC peering). Supported authentication: username/password, client certificate (mTLS), and JWT/OIDC, with role-based access control; LDAP is not supported. - [Cloud Enterprise Feature Availability](https://docs.hivemq.com/hivemq-cloud/cloud-enterprise-feature-availability.html): What a Cloud Enterprise deployment includes and where it is restricted The reference for what a HiveMQ Cloud Enterprise deployment includes, replacing the contract product exhibit. Each capability is marked Available, On request, Restricted, or Not supported, with links to the broker and extension documentation for mechanics. Covers broker capabilities, security and access control, managed Cloud capabilities, the Enterprise Security Extension, Enterprise Extensions, Data Hub, and observability. - [Cloud Enterprise Platform Notes](https://docs.hivemq.com/hivemq-cloud/cloud-enterprise-platform-notes.html): Console and platform availability, Control Center, and Data Intelligence Operational notes for HiveMQ Cloud Enterprise: clusters are available in the Cloud Console today and in the HiveMQ Platform soon; customers use Control Center v1 today, with CCv2 migration coordinated per-customer through the TAM/CSM; clusters are eligible for Data Intelligence, enabled on request through the account team (latest-version upgrade plus an SRE-provided connection key). ## HiveMQ Edge - [HiveMQ Edge](https://docs.hivemq.com/hivemq-edge/index.html): Lightweight open-source MQTT gateway for edge computing with protocol translation HiveMQ Edge is a lightweight, open-source MQTT gateway optimized for Edge computing. Use HiveMQ Edge to translate diverse industrial device protocols into MQTT for streamlined and reliable communication between your operational technology and information technology systems. - [System Requirements](https://docs.hivemq.com/hivemq-edge/system-requirements.html): OS, JDK, and hardware requirements for Edge HiveMQ Edge runs on Linux, Windows, and macOS with JDK 17+ (JDK 21+ for version 2025.16+). It is designed for lightweight deployment on edge devices and servers. - [Installation](https://docs.hivemq.com/hivemq-edge/installing-hivemq-edge.html): Installation on Linux, Windows, or Kubernetes with Helm This guide covers installation on Linux, Windows, and Kubernetes using Helm charts. It includes directory structure, prerequisites, and reverse proxy configuration. - [Configuration](https://docs.hivemq.com/hivemq-edge/configuration.html): XML-based broker configuration for Edge HiveMQ Edge uses XML-based configuration files located in the conf folder. The default configuration binds a TCP listener on port 1883 and is suitable for most typical use cases. - [Protocol Adapters](https://docs.hivemq.com/hivemq-edge/protocol-adapters.html): OPC UA, Modbus, S7, BACnet, EtherNet/IP, HTTP, and more HiveMQ Edge includes 12+ pre-built protocol adapters for industrial protocols, including OPC UA (northbound and southbound), Modbus TCP, Siemens S7, ADS/TwinCAT, EtherNet/IP, HTTP(S), BACnet, MTConnect, and database adapters. A custom adapter SDK is also available. - [Bulk Device Tag Operations](https://docs.hivemq.com/hivemq-edge/bulk-device-tag-operations.html): Browse adapter address spaces and import tags in bulk via REST API Bulk device tag operations expose two REST API endpoints. These endpoints are available for adapters that implement the BulkTagBrowser interface. The browse endpoint scans the device address space and returns the discovered variable node. Supported output formats are CSV, JSON, and YAML. Results include suggested default values for each node. The import endpoint accepts an edited browse file and creates, updates, or deletes tags and mappings atomically. All tag operations are validated, then processed as a single operation. If any validation fails, no changes are made. Five conflict resolution modes (CREATE, DELETE, OVERWRITE, MERGE_SAFE, MERGE_OVERWRITE) control how imported tags interact with existing tags. Currently supports OPC UA adapters. - [MQTT Bridging](https://docs.hivemq.com/hivemq-edge/mqtt-bridging.html): Bridge MQTT messages to upstream brokers MQTT bridging enables bidirectional message exchange between HiveMQ Edge and upstream MQTT brokers. Configure topic mappings to forward data from edge devices to enterprise HiveMQ clusters or cloud services. - [Security](https://docs.hivemq.com/hivemq-edge/security.html): TLS, authentication, and authorization for Edge HiveMQ Edge supports TLS/SSL encryption for transport security, along with authentication and authorization mechanisms. Security configuration covers both MQTT client connections and the management API. - [Console](https://docs.hivemq.com/hivemq-edge/console.html): Web UI for visual management, workspace, and observability - [How-Tos](https://docs.hivemq.com/hivemq-edge/howtos.html): Step-by-step guides for TLS setup and connecting to an OPC UA server with a self-signed certificate The HiveMQ Edge Console is a web-based UI that provides a visual canvas for managing adapters, bridges, and data flows. It includes a workspace with topology view, configuration toolbar, and real-time observability features. ## HiveMQ Swarm - [HiveMQ Swarm](https://docs.hivemq.com/hivemq-swarm/latest/index.html): Distributed MQTT load testing and simulation tool HiveMQ Swarm is an advanced IoT testing and simulation tool that gives you the load and reliability testing ability needed to determine the resilience and capacity of your complete IoT system. IoT solutions usually involve massive distributed systems, and successfully simulating your end-to-end production environment can be a big challenge. - [Scenarios](https://docs.hivemq.com/hivemq-swarm/latest/scenarios.html): Scenario DSL for defining client groups, subscriptions, and test stages Scenarios are an important concept in HiveMQ Swarm. Each scenario is an abstract representation of a specific real-life MQTT use case defined in an XML-based DSL. You can define scenarios that represent very large numbers of MQTT clients organized in client groups, with behavior delineated in stages, lifecycles, and commands. - [Commands](https://docs.hivemq.com/hivemq-swarm/latest/commands.html): Command reference (Connect, Publish, Subscribe, Receive, For, Delay, Timer) In HiveMQ Swarm, commands represent the actions that each client of a client group completes within a specific lifecycle of your scenario. Available commands include Connect, Publish, Subscribe, Receive, Disconnect, For (loops), Delay, and Timer for controlling client behavior during load tests. - [Deployment](https://docs.hivemq.com/hivemq-swarm/latest/clustering.html): Distributed architecture with commander/agents, Kubernetes deployment HiveMQ Swarm gives you the ability to create a clustered test environment that distributes the workload to the appropriate number of worker nodes. Each cluster has a single commander and one or more agents, with the commander distributing workload chunks to agents that organize groups of MQTT clients. Includes Kubernetes deployment with Helm charts. - [Monitoring](https://docs.hivemq.com/hivemq-swarm/latest/monitoring.html): InfluxDB and Prometheus metrics integration HiveMQ Swarm supports monitoring via InfluxDB and Prometheus. Configure InfluxDB connections through environment variables or file-based configuration to gather and visualize application metrics from your load testing scenarios. - [Example Scenarios](https://docs.hivemq.com/hivemq-swarm/latest/example-scenarios.html): Templates for reconnect storms, fan-out, fan-in, steady load, and more Example scenarios to become familiar with HiveMQ Swarm and as a basis for your own scenarios. Includes templates for reconnect storm testing, fan-out and fan-in patterns, steady load generation, and other common IoT simulation patterns. ## HiveMQ Platform - [HiveMQ Platform Overview](https://docs.hivemq.com/hivemq-platform/index.html): What the platform is — data streaming, data intelligence, and agentic AI in one console, organized into five layers The HiveMQ Platform combines data streaming, data intelligence, and agentic AI in a single management console, covering both HiveMQ Cloud broker deployments and HiveMQ Enterprise MQTT Brokers you deploy from HiveMQ software. Its capabilities are organized into five layers, each building on the data the previous one provides: Explore, the home page, where personalized AI insights and recommended actions start each session; Connect, the data streaming layer that deploys, registers, and manages brokers and Edge instances; Contextualize, the data intelligence layer where you discover data streams and build a Unified Namespace; Analyze, the data intelligence layer for operational health and deviations; and Act, the agentic AI layer, currently a public preview, where AI agents take governed action on trusted data. Bea, a context-aware AI assistant, is built into every page and spans all five layers. - [Getting Started with the HiveMQ Platform](https://docs.hivemq.com/hivemq-platform/get-started-with-hivemq.html): End-to-end first run — create an account, deploy a broker in Docker, stream simulated data, build a namespace, and check data health A five-step walkthrough that goes from nothing to governed, analyzed data. Create a HiveMQ account with an email address or a GitHub, Google, or LinkedIn login; deploy a HiveMQ Enterprise MQTT Broker in Docker using an automatically generated Lab license; publish a stream of simulated sensor readings through it; approve discovered topics into a Unified Namespace in Contextualize; then review the results on the Analyze Data Health dashboard and inspect the deviations the simulated data deliberately generates. Requires Docker and a terminal. The guide also notes that the HiveMQ Platform replaces the HiveMQ Cloud Console as the default management experience: new accounts open in the platform automatically, while existing HiveMQ Cloud customers move over in stages and can switch back during the transition. ## HiveMQ Platform: Connect - [Connect Overview](https://docs.hivemq.com/hivemq-platform/connect/connect-overview.html): The data streaming layer of the HiveMQ Platform — bring brokers and Edge instances in, start the data flow, and manage your network Connect is the data streaming layer of the HiveMQ Platform, where you bring HiveMQ brokers and HiveMQ Edge instances into the platform, start your data flow, and manage your network from one place. It is the foundation the other layers rest on: until data streams through the platform, there is nothing to contextualize, analyze, or act on. From Connect you deploy new infrastructure, register infrastructure you already run, license a broker with a free Lab license or a purchased one, and check the status of your network. One behavior catches people out: deploying a broker is not enough for it to appear, because the platform lists an instance only once it reports in and can be associated with your account. - [Deploy a Broker](https://docs.hivemq.com/hivemq-platform/connect/deploy-a-broker.html): Deploy a HiveMQ broker as a managed Cloud cluster or as self-managed software, via Docker, Kubernetes, local install, AWS, or Azure Compares the two ways to run HiveMQ — HiveMQ Cloud, which HiveMQ operates as a managed service on AWS, and HiveMQ Software, which you self-manage — then walks through deploying either from the platform. The self-managed path covers Docker, Kubernetes (via the HiveMQ Platform Operator and Helm), local installation, AWS EC2, and Azure; each generates a free Lab license key and ends with a broker connected and Data Intelligence enabled. The Cloud path covers the Serverless and Starter plans, including the 15-day Starter trial. Two constraints matter: Data Intelligence requires HiveMQ 4.55 (LTS) or later, and HiveMQ Cloud deployments do not support Data Intelligence, so Contextualize and Analyze are unavailable for Cloud-deployed brokers. - [Connect Your Existing HiveMQ Broker or Edge Instance](https://docs.hivemq.com/hivemq-platform/connect/connect-broker-or-edge.html): Register a broker or Edge instance you already run by generating and applying a connection string To expose the data flowing between a broker and its clients, an existing deployment has to be registered with the platform; only then can the platform contextualize, analyze, and act on that data, and manage licensing and entitlements centrally. For a broker, you generate a connection string in Connect, set the provided environment variable on the broker, add the connection string, and restart. For an Edge instance, you paste the connection string into Connect with HiveMQ Platform in the Edge Web Console. Both paths finish with the instance showing as Connected in the Network view. Data Intelligence requires HiveMQ 4.55 (LTS) or later, and these steps cover a single-node broker — a clustered deployment needs log-based cluster transport. - [Test Client-Broker Communication](https://docs.hivemq.com/hivemq-platform/connect/test-broker-communications.html): Verify that a client connects to your broker, then validate that messages publish and subscribe successfully A two-stage check to run after a deployment. First verify that a client connects, which differs by broker type because the default listeners differ: a HiveMQ broker uses the native MQTT listener on port 1883, while a HiveMQ Cloud broker uses a TLS-only WebClient listener on 8884 or the native listener on 8883. Then validate real message transfer by subscribing to a topic and publishing a test message, using either the MQTT CLI or the platform's built-in WebClient. Connectivity alone is not proof — a successful connection does not confirm that messages actually flow. - [Publish/Subscribe Architecture](https://docs.hivemq.com/hivemq-platform/connect/publish-subscribe-architecture.html): How MQTT pub/sub works — decoupled publishers and subscribers, topic filters and wildcards, and the three QoS levels Background concept page for the MQTT model the platform is built on. Publishers send messages to a broker and subscribers receive them, with neither side knowing the other, which decouples them in three dimensions: space (only the broker's address is needed), time (the broker can store messages for offline clients), and synchronization (publishing and receiving do not block each other). The broker routes by hierarchical topics such as `factory/line1/temperature`, where `+` matches a single level and `#` matches all remaining levels. Delivery offers three Quality of Service levels: at most once (QoS 0), at least once (QoS 1), and exactly once (QoS 2) through a four-step handshake. Every broker in the platform, Cloud and self-managed alike, implements this model. - [Get a License](https://docs.hivemq.com/hivemq-platform/connect/get-a-license.html): Purchase a license for a self-managed broker, apply the key, and connect the broker to the platform Without a valid license, a HiveMQ broker starts in evaluation mode and is limited to 25 client connections. This applies to the HiveMQ Enterprise MQTT Broker 4.55 or later; HiveMQ Cloud plans already include a license, so no action is needed there. The flow has three steps: purchase the license in Connect, deploy a broker and apply the license key, then explicitly connect the broker so it appears in the Network view and unlocks Data Intelligence. Purchasing alone is not enough — a license shows a Deployment value of License until a deployment reports in with that key, at which point it becomes Software, and the connection step is still required after that. - [Connect - The Network View](https://docs.hivemq.com/hivemq-platform/connect/broker-listing-states.html): Reference for the Network view — its columns, the Data Intelligence states, and how an instance moves between them The Network view lists every broker and Edge instance the platform knows about, both those you connected and those it merely detected. Its columns are Name, Type (Broker or Edge), Deployment (Cloud, Software, or License), and Data Intelligence, whose states are Not ready to connect, Ready to connect, Connected, Offline, and Not eligible — the last applying to HiveMQ Cloud Serverless, Starter, and Enterprise subscriptions. The page traces how a self-managed broker and a purchased license each move through those states, lists the action the view suggests for every combination, and closes with the most common confusion: deploying a broker does not by itself put it in the list, because an instance appears only after it reports to the platform and is associated with your account. ## HiveMQ Platform: Contextualize - [Contextualize Overview](https://docs.hivemq.com/hivemq-platform/contextualize/contextualize-overview.html): Console area for building and managing a Unified Namespace across devices, brokers, and applications Contextualize is the area of the HiveMQ Platform console where you build and manage a Unified Namespace, a single, standardized model for how data flows across devices, brokers, and applications. It provides three areas: Namespace, Discovery, and Data Models. - [Define Namespace](https://docs.hivemq.com/hivemq-platform/contextualize/define-namespace.html): Build the ISA-95 namespace with node types, data types, tag history, and search Build a hierarchical, ISA-95 namespace that declaratively defines the structure and context of your data and is automatically synchronized to connected brokers. This section covers the three base node types (Folder, Tag, Field) and their subtypes, creating the root Enterprise node, adding nodes, node details and Traffic Origin, data types and serialization formats, per-tag history (settings, Data Output, Payload View, Charts), and searching the namespace as a data catalog. - [Discovery](https://docs.hivemq.com/hivemq-platform/contextualize/discovery.html): Reveal ungoverned MQTT traffic and approve it into the namespace Discovery is the bottom-up way to build the namespace. It reveals ungoverned MQTT traffic that flows through connected brokers, lets you review each discovered topic (suggested data type, serialization format, sample payload, message counts), and approve it into the namespace or ignore it. Bulk approval handles many topics at once. - [Data Models](https://docs.hivemq.com/hivemq-platform/contextualize/data-models.html): Standardize and reuse versioned data structures across the namespace Data Models let you standardize a data structure once and reuse it across the namespace. A data model is a small, versioned, immutable sub-namespace that you derive from an existing node or build from a blank state, publish as a version, and instantiate anywhere in the namespace. - [Computations](https://docs.hivemq.com/hivemq-platform/contextualize/computations.html): Derive new values in transit on the broker with calculations and expressions Computations derive new values and insights from existing tags while data is in transit. The broker executes them directly, with no extra infrastructure. A computed tag draws its value from a Calculation (predefined functions) or an Expression (free-form formula). A worked example converts Celsius to Fahrenheit and maps variables to tags. - [Functions](https://docs.hivemq.com/hivemq-platform/contextualize/functions.html): Reference of functions available in calculations and expressions A reference of the functions available in calculations and expressions, grouped into arithmetic (ABS, ROUND, SUM, MINUS, DIV, PRODUCT), aggregation and statistical (COUNT, FIRST, LAST, MEDIAN, SMA, STDDEV, EMA, MAX, MIN, and windowed variants), and state and event functions (EVENT_TIME, INGESTION_TIME, TimeAtState, BetweenState, TimeElapsed, CountBetween). - [Expression Language](https://docs.hivemq.com/hivemq-platform/contextualize/expression-language.html): Syntax reference for the expressions used in computations The syntax of the expression language you write in a computation: integer, decimal, and boolean literals (the language has no string literal), variables that map to tags, arithmetic, comparison, and logical operators, and the conditional operator. Also covers variable naming conventions, best practices, and worked manufacturing examples. The functions themselves are documented separately in the Functions reference. ## HiveMQ Platform: Analyze - [Analyze Overview](https://docs.hivemq.com/hivemq-platform/analyze/analyze-overview.html): Monitor the health and governance of your governed streams Analyze is the area of the HiveMQ Platform console where you monitor the health and governance of your governed streams. It provides two areas: Data Health (data-quality metrics and deviations) and Events (activity, alarms, and policy violations across the Unified Namespace). - [Data Health](https://docs.hivemq.com/hivemq-platform/analyze/data-health.html): Data-quality metrics in total and per broker Data Health shows how well the data flowing through the Unified Namespace matches its definition. It summarizes traffic in total (governed vs ungoverned; healthy, deviating, and ignored) for a selected timeframe, and breaks the same picture down per broker so you can pinpoint where deviations originate. - [Events](https://docs.hivemq.com/hivemq-platform/analyze/events.html): Per-broker deviations from the namespace definition Events surface deviations — traffic that does not match the namespace definition — listed per broker with a detail view showing the last valid and incorrect payloads. Deviations are one of three types: Missing Field, Unexpected Field, and Unexpected Format. ## HiveMQ Platform: Explore - [Explore Overview](https://docs.hivemq.com/hivemq-platform/explore/explore-overview.html): The platform home page — AI Insights and recommended next steps based on your network's current state Explore is the HiveMQ Platform home page. Start each session here to see real-time AI Insights about your network's current status, which point to setup tasks (Add Infrastructure, Invite, Ask Bea) when no brokers or edges are connected yet, or next steps (View Clusters, Deploy Agent, Add Namespace) once your network is running. Explore also surfaces options to grow your network, including downloading HiveMQ Software, getting a HiveMQ Cloud broker, adding a namespace, and deploying an AI agent. ## HiveMQ Platform: Act - [Act Overview](https://docs.hivemq.com/hivemq-platform/act/act-overview.html): The agentic AI layer of the HiveMQ Platform — agents, the Sense-Reason-Actuate-Reflect loop, networks, and orchestrators Act is the agentic AI layer of the HiveMQ Platform, where you build and deploy AI agents that act on real-time IoT data without writing application code. Every agent runs the same four-stage loop on each cycle: Sense collects data from MQTT topics, databases, and APIs; Reason analyzes it with an LLM or deterministic rules; Actuate executes the planned actions; and Reflect saves memory and metrics for the next cycle. An agent is configuration rather than code, called a data-defined agent (DDA). Networks group the agents, shared tools, and orchestrators for one site or environment, and orchestrators run agents as Docker containers on your own infrastructure, pulling their work from the Control Plane so every connection flows outbound. Act is currently available as a public preview. - [Get Started](https://docs.hivemq.com/hivemq-platform/act/quick-start.html): Build and deploy your first agent by describing your goal to Bea, the platform's AI assistant The fastest path to a working agent is to describe your goal in plain language to Bea, the AI assistant of the HiveMQ Platform, which turns the description into a complete, ready-to-deploy agent definition. This tutorial goes from an empty screen to a running agent: describe the goal or pick a quick-prompt chip, review the prefilled stages, start the deploy wizard, select or create a network and orchestrator, run the supplied `docker run` command to enroll the orchestrator, then name the agent, supply its template parameters, and deploy. Docker must be installed on the machine where the agent runs. - [Create an Agent](https://docs.hivemq.com/hivemq-platform/act/create-an-agent.html): Start from a Marketplace template or a Bea draft, then refine the seven stages of the Agent Builder Every agent starts from a template, a data-defined agent (DDA) configuration that describes everything the agent senses, reasons about, acts on, and reflects on. You get a starting template either by cloning a Marketplace template or by describing your goal to Bea, and both paths open the Agent Builder. The builder has seven stages: Agent Configuration, Connections, Sense, Reason, Actuate, Reflect, and Termination, where the middle four form the agent's repeating loop. You can save the template at any time, download it as YAML, and deploy once all required fields are valid. - [Start from a Marketplace Template](https://docs.hivemq.com/hivemq-platform/act/marketplace-template.html): Browse, review, clone, and deploy ready-made agent templates, or import your own The Marketplace is a catalog of ready-made agent templates that HiveMQ built for industrial IoT and smart manufacturing. Each card shows the template name, a short description, a version badge, a category badge such as `Monitor`, and tag chips that describe the reasoning mode, task, technologies, and oversight model of the agent. Cloning a template opens the Agent Builder prefilled with its configuration, and you can also download the template YAML to review it or store it in your own repository. The Agent Templates tab lists the templates your organization owns, where you can import a DDA file, open a template for editing, or deploy it directly. - [Configure an Agent](https://docs.hivemq.com/hivemq-platform/act/configure-an-agent.html): Agent identity, deploy-time parameters, LLM model, audit trail, and termination conditions, with the YAML field reference The Agent Configuration stage sets the identity of the agent and the settings that apply across its whole lifecycle. Identity names the agent and adds an optional version, description, role, and job title. Parameters declare the values that the deploy wizard prompts for, so one template can be deployed many times with different values. LLM Configuration selects the provider (OpenRouter, Anthropic, OpenAI, or Ollama), model, temperature, and token limit, and can be skipped entirely for a fully deterministic agent that incurs no model cost or latency. The Audit Trail section hash-chains a record of each cycle to support traceability and compliance needs such as the EU AI Act, FDA 21 CFR Part 11, and ISO 9001, and Termination sets the conditions that stop an otherwise continuous agent. The page closes with the YAML field reference for each section. - [Set Up Connections](https://docs.hivemq.com/hivemq-platform/act/connections.html): Connection reference for MQTT, PostgreSQL, MySQL, REST API, SendGrid, SMTP, Slack, and MCP servers A connection defines how an agent reaches an external service, and you reference it by name from the Sense and Actuate substages. This reference documents each connection type with its fields and YAML: MQTT including TLS and mutual TLS, PostgreSQL, MySQL, REST API, SendGrid and SMTP email, Slack in either webhook or bot mode, and MCP servers. Every connection field accepts `${ENV_VAR}` references, so secrets are supplied at deploy time rather than stored in the template. The platform also injects connections whose names begin with a double underscore, such as `__agent_bus` and `__long_term_storage`, when the network provides the corresponding tool. - [Sense Data](https://docs.hivemq.com/hivemq-platform/act/sense-stage.html): Collect data from MQTT, APIs, databases, CSV files, and agent messages, with windowing, aggregation, and payload interpretation The Sense stage collects data from external sources and passes it to Reason, running every configured substage in order each cycle. The substage types are `mqtt`, `api`, `database`, `csv`, and `agent-messages`. A window buffers observations across cycles and produces aggregations such as avg, max, slope, stddev, median, and percentiles, so an agent can detect a trend instead of reacting to a single spike. An optional `interpret` block uses the LLM to normalize unpredictable payload structures into a consistent shape, caching the result per structure. The page documents exactly where each source lands in `environmentalData.payload`, and how those property names change once a window is configured. - [Reason on Data](https://docs.hivemq.com/hivemq-platform/act/reason-stage.html): Analyze, plan, govern, and authorize substages in deterministic rule mode or LLM mode The Reason stage evaluates what Sense collected and determines the appropriate action through four substages that run in order: `analyze` produces a structured assessment, `plan` selects the actions to execute, `govern` applies safety rules that can reject a plan outright, and `authorize` declares an allowlist of permitted resources. Both `analyze` and `plan` support two modes: deterministic JavaScript rule conditions that cost no LLM tokens, and LLM prompts with an `outputSchema` that the platform validates. Each substage writes its result into `derivedData`, which the platform resets at the start of every cycle, so any result that must influence the next cycle has to be routed through memory in the Reflect stage. - [Act on Data](https://docs.hivemq.com/hivemq-platform/act/actuate-stage.html): Execute planned actions through the action handler catalog and verify results against success criteria The Actuate stage executes the actions that Reason planned. The `execute` substage runs one or more executors, each bound to an action handler such as `mqtt_publish`, `api_call`, `database_write`, `email_send`, `slack_message`, `agent_message`, `mcp_tool_call`, or the industrial handlers that proxy through a gateway service you run alongside the orchestrator. The `evaluate` substage then checks whether the actions succeeded, using a minimum success rate and verifications such as waiting for an MQTT acknowledgment. Every handler carries a risk tier from `low` to `critical`, which suggests the autonomy lane the action belongs in. - [Reflect on Agent Execution](https://docs.hivemq.com/hivemq-platform/act/reflect-stage.html): Learn from cycle outcomes, save memory with retention policies, and capture per-cycle metrics The optional Reflect stage runs after Actuate and before the next Sense cycle. Its `learn` substage uses the LLM to extract patterns and insights from the outcome of the cycle, `update-state` saves memory and applies retention policies (`max_items` or `ttl`) so that arrays do not grow without bound, and `capture-metrics` records the per-cycle statistics that appear in the Control Plane. Unlike `derivedData`, memory persists from one cycle to the next; the standard properties are `memory.recentActions`, `memory.patterns`, `memory.constraints`, and `memory.feedbackHistory`, and you can define your own. Registering a Long-Term Storage network tool additionally writes memory to PostgreSQL so it survives restarts and redeployments. - [Set a Trigger to Start an Agent Cycle](https://docs.hivemq.com/hivemq-platform/act/triggers.html): Start agent cycles on a fixed interval, a cron schedule, or an incoming MQTT message A trigger determines when an agent runs a cycle, and each data-defined agent has exactly one. The `interval` trigger starts a cycle every `intervalMs` milliseconds and can optionally run once immediately at startup. The `cron` trigger takes a standard five-field expression, which makes one minute the shortest possible spacing between cycles. The `mqtt` trigger starts a cycle for each message that arrives on a subscribed topic filter, and the triggering message is available in the Sense stage without configuring a separate MQTT sense substage. - [Set Human Oversight](https://docs.hivemq.com/hivemq-platform/act/set-human-oversight.html): Autonomy lanes, routing, and timeout resolution that decide which actions need human approval Human oversight controls how much approval an agent needs before it acts, and is available for orchestrated agents only. Three autonomy lanes exist: Autonomous acts without approval, Supervised submits the action and applies a timeout action if no one replies, and Controlled executes only after a person explicitly approves. The agent resolves the lane for each action from most specific to least: per-action override, then stage override, then the agent-wide default lane. Timeout resolution decides what happens when nobody responds in time, with `continue`, `skip`, or `reject`, falling back to a built-in default of continue after 300000 milliseconds. The page also weighs the factors that should shape a lane assignment beyond the handler's risk tier, including agent confidence, reversibility, scope of impact, responder availability, request volume, and audit or regulatory requirements. - [Deploy an Agent](https://docs.hivemq.com/hivemq-platform/act/deploying-agents.html): Run a saved template on an orchestrator with the deploy wizard, and manage the deployed agent lifecycle Deploying runs a saved agent template as a live agent inside an orchestrator on one of your networks. The wizard adapts to your setup: choose whether to deploy on the network or download the agent, select the network and orchestrator, enroll the orchestrator with a Docker command if it has not connected yet, then name the agent, optionally enable Sandbox Mode, and supply the template parameters. After deployment, the agent detail view offers Overview metrics, a read-only Configuration tab, and a live Logs stream, along with stop, start, and delete actions. The page includes the full agent status reference, covering Pending, Deploying, Starting, Running, Idle, Paused, Stopping, Stopped, Stale, Removing, Failed, and Error. - [Create a Network](https://docs.hivemq.com/hivemq-platform/act/networks.html): Group the orchestrators, shared tools, and agents that belong to one site or environment A network groups everything that belongs to one site, line, or environment: its orchestrators, the tools and resources its agents share, and the agents themselves. Every orchestrator belongs to exactly one network, and agents on the same network share tools and communicate over a shared bus. The network detail page has four sections: Orchestrators, Network Tools & Resources, Feedback Notifications, and the CA certificate that orchestrators use when they register. A network cannot be deleted while it still has orchestrators attached, which prevents orphaning running agents. - [Share Resources Between Agents](https://docs.hivemq.com/hivemq-platform/act/share-resources.html): How agents on the same network share network-level tools and a common bus Agents that run on the same network do not work in isolation. They draw on the same network-level tools and resources, registered once instead of repeated in every agent, and they exchange messages over a shared bus that needs no per-agent configuration. This short orientation page points to the two mechanisms that make that possible: network tools and resources, and agent-to-agent communication. - [Provide Tools for Agents in a Network](https://docs.hivemq.com/hivemq-platform/act/network-tools.html): Register environment variables, databases, APIs, MCP servers, brokers, and long-term storage once per network Network tools and resources are registered once at the network level and become available to every agent on that network. The available types are Environment Variable, MCP Server, Database, API, MQTT Broker, and Long-Term Storage, and any value can be marked as a secret so the platform never displays it in plain text. When an Environment Variable tool matches a reference in a template, the deploy wizard offers its value as the default for that reference. A Long-Term Storage tool gives every agent on the network memory that survives restarts, and an MQTT Broker tool can serve as the network's agent bus in place of the built-in one. - [Agent-to-Agent Communication](https://docs.hivemq.com/hivemq-platform/act/a2a-communications.html): The built-in agent bus, and how to route agent traffic through your own MQTT broker Agents on the same network can communicate over a shared agent bus that the orchestrator provides automatically, with no configuration required. To keep agent-to-agent traffic on infrastructure you manage, register your own broker as a network tool of type MQTT Broker; it then overrides the built-in agent bus for that network. - [Deploy an Orchestrator](https://docs.hivemq.com/hivemq-platform/act/orchestrators-overview.html): Enroll the outbound-only Docker engine that runs your agents on your own infrastructure An orchestrator is the engine that runs your agents as Docker containers on your own infrastructure, close to the data they act on. It is outbound-only: the orchestrator connects out to the HiveMQ Platform to receive its agents and report health, and the platform never calls into your infrastructure. Enrollment runs a `docker run` command carrying a short-lived registration token, after which the orchestrator generates and persists its own certificates, so later restarts require no re-enrollment. The orchestrator needs access to the Docker socket to create and remove agent containers, and secrets prefixed with `AGENT_` on the orchestrator are forwarded into each agent container with the prefix stripped. Its Health & Performance metrics report status, uptime, average CPU, and average memory for the orchestrator itself rather than per agent. - [Monitor Agent Health](https://docs.hivemq.com/hivemq-platform/act/monitor-agent-health.html): Fleet view, agent metrics, and how to diagnose an agent that runs but does no useful work An agent can be running and still fail silently, so this page separates lifecycle status from health. The Deployed Agents tab opens on a fleet view with summary cards for Awaiting Your Decision, Agent Health, Running, and Total Agents, plus filters for network, orchestrator, status, and role. An agent's detail page reports Uptime, Total Cycles, Success Rate, and Avg Cycle, alongside a read-only Configuration tab and a live Logs stream. The recommended diagnostic order is status and header banner, then success rate, then logs, then configuration. A reference section explains how the platform assesses health from connection health, cycle success rate, LLM availability, and sense data quality, and why a stale orchestrator does not necessarily mean its agents have failed. - [Respond to a Feedback Request](https://docs.hivemq.com/hivemq-platform/act/respond-to-feedback.html): Approve or reject actions an agent holds for review, and set per-network notification channels When an agent reaches an action that needs a human decision, it raises a feedback request and waits. Requests appear on the agent that raised them rather than in a separate inbox: the Awaiting Your Decision card counts them on the Deployed Agents tab, and the request itself appears in a banner at the top of the agent's page with the question, the action context, the agent's confidence, and the time remaining. A controlled action blocks until you answer, while a supervised action has already run and collects your answer only so the agent can learn from it. If no one answers before the timeout, the agent applies its default action of `reject`, `skip`, or `continue`. Notifications are configured per network through webhook or email channels, and every response feeds into the Reflect stage so the agent can calibrate future decisions. - [Test an Agent Locally](https://docs.hivemq.com/hivemq-platform/act/test-agent-locally.html): Run a downloaded agent definition in a single docker run command for quick testing Sometimes you want to watch an agent definition cycle on your own machine before committing to a deployment. Download the agent YAML from the Act tab and run it with a single `docker run` command against the public `hivemq-agentic-agent` image, passing the provider keys the agent needs. The command sets `HIVEMQ_SANDBOX_MODE=true` so the agent cycles end-to-end without real data sources; remove that line to run against your real brokers, databases, and APIs. A locally run agent is invisible to the HiveMQ Platform: it does not appear in your fleet, health monitoring, or feedback views, and it cannot use human-in-the-loop feedback, agent-to-agent messaging, or persistent memory. - [Train Your Agent (Sandbox)](https://docs.hivemq.com/hivemq-platform/act/sandbox-mode.html): Run an agent against synthetic sense data while actuations still fire with a disclosure Sandbox Mode is a per-agent toggle that runs the full Sense, Reason, Actuate, and Reflect loop against synthetic data instead of real sources, for demos, training, and pipeline validation. The runtime replaces the external sense substages with a generator that produces plausible values from variable-name heuristics, and skips initializing sense-only connections so no unreachable-broker errors appear. Everything after Sense runs identically, which means actuations are real: emails send, Slack messages post, and MQTT publishes happen, each carrying a sandbox disclosure appropriate to its handler. You can toggle Sandbox Mode on an already-deployed agent and it takes effect on the next cycle, but it is not a substitute for testing against real data, which brings noise, latency, ordering, and schema variation the sandbox cannot reproduce. - [Troubleshoot Agent Behavior](https://docs.hivemq.com/hivemq-platform/act/troubleshoot.html): Fix failed agents, stuck deployments, stale orchestrators, and networks that will not delete Most problems with a deployed agent surface in one of three places: the agent's status on the Deployed Agents tab, a banner on its detail header, or its Logs tab. This page covers the failures you are most likely to hit: an agent that fails because its template references environment variables it was never given, an agent stuck in Pending because its orchestrator is not running, an orchestrator that goes stale or never sends a first heartbeat, an agent that runs but does no useful work, and a network that cannot be deleted while orchestrators are still attached. Each entry gives the symptom, the most common cause, and the fix. ## HiveMQ Platform: Account & Administration - [Account & Administration Overview](https://docs.hivemq.com/hivemq-platform/account-administration/account-administration-overview.html): Where to manage your personal account, your organization's profile and members, API keys, and billing Account & Administration covers personal and organization settings, all reached from the user menu in the top-right corner of the console. The menu splits into two groups. Account settings apply only to you: profile details such as name, email, and company, privacy preferences, account deletion, and console preferences including date format, number format, and whether timestamps display in UTC. Workspace settings apply to the whole organization: the organization profile, which holds the organization ID and name, team members and their roles, and Enterprise SSO configuration; organization-scoped API keys for automation and agent workflows; and billing, covering payment methods, invoices, licenses, plan cancellation, and add-ons such as the Analyze data-intelligence add-on. If you belong to more than one organization, Switch workspace moves between them. - [Log In to the HiveMQ Platform](https://docs.hivemq.com/hivemq-platform/account-administration/log-in-to-hivemq.html): Log in to the HiveMQ Platform with existing credentials Log in to the HiveMQ Platform using the credentials you created when you set up your account, from hivemq.com's Welcome screen. - [Invite Team Members](https://docs.hivemq.com/hivemq-platform/account-administration/invite-team-members.html): Add team members to your organization by email with an Owner, Admin, or Viewer role Invite people to join your organization by email, assigning them one of three roles at invitation time: Owner (unrestricted access, including billing and member management), Admin (manages brokers, access control, and API tokens), or Viewer (read-only access to brokers and organization details). Requires Owner or Admin access. Invited members appear as pending in the Team list until they accept. - [Assign User Roles and Permissions](https://docs.hivemq.com/hivemq-platform/account-administration/assign-user-roles-and-permissions.html): Change a team member's organization role after they've joined Change an existing team member's organization role (Owner, Admin, or Viewer) to update what they can see and do in the platform. Requires Owner role access; the change applies immediately. - [Organization](https://docs.hivemq.com/hivemq-platform/account-administration/organization.html): The top-level account container that owns your licenses, team membership, and billing, and the three team roles An organization is the top-level account container in the HiveMQ Platform, owning your HiveMQ licenses, team membership, and billing information. From the Organization menu you manage team members and their roles, licenses and subscription plans, and billing details; your own profile, privacy settings, and platform preferences live under Account instead. Access is role-based, with three roles: Owner has unrestricted access to the organization and all its settings, including members, billing, and every broker configuration; Admin manages brokers, access control, and API tokens, and can reach organization settings and billing; Viewer has read-only access to brokers and organization details and can manage only their own profile. - [Enterprise Single Sign-On](https://docs.hivemq.com/hivemq-platform/account-administration/enterprise-sso.html): How SAML and OIDC single sign-on works, the self-service ticket URL and Home Realm Discovery, and its effect on member management Enterprise SSO lets your team authenticate through your organization's existing identity provider, so members sign in with corporate credentials rather than a separate HiveMQ password, and your IdP's policies — multi-factor requirements, session expiration — apply centrally. It is available to HiveMQ Cloud Enterprise plan customers, activated on request through your account team or Technical Account Manager. Two mechanisms drive it: a one-time Self-Service SSO ticket URL, issued to the organization owner, which opens a setup assistant so your IT administrator configures the IdP connection without sharing credentials with HiveMQ; and Home Realm Discovery, which detects your corporate email domain at login and redirects the user to your identity provider. SAML and OpenID Connect are supported, with Okta, Azure Active Directory, and Google Workspace as common examples. Once SSO is active, the Members list on the Organization page shows only the organization Owner and direct invitations are disabled — new members are provisioned in your identity provider instead. - [Data Intelligence Metering and Billing](https://docs.hivemq.com/hivemq-platform/account-administration/data-intelligence-metering-and-billing.html): What Data Intelligence bills, how node activation determines the billed quantity, and how to read your invoice Data Intelligence bills on usage, not on feature tiers. Usage falls into two independent categories. Active billable nodes are tags, including assets and other tag subtypes. The premium charge applies to tags and fields sourced from a computation, expression, or link. Folders, fields, metadata, and data model instances are not billed. Only active nodes count. Every node starts inactive. When you activate a node, HiveMQ also activates its inputs. Deactivation does not cascade. A field follows the activation state of its tag. The monthly quantity is the sum of daily active counts divided by the days in the calendar month, minus a free allowance per category. Active billable nodes are priced at a graduated rate and a flat rate for the premium charge. The activation limit caps how many nodes can be active at the same time. It is a product limit, separate from the free allowance on your bill. - [Set Up Enterprise SSO](https://docs.hivemq.com/hivemq-platform/account-administration/set-up-enterprise-sso.html): Configure single sign-on through your organization's identity provider Set up Enterprise SSO so your team authenticates through your organization's identity provider instead of separate HiveMQ credentials. Requires HiveMQ to activate SSO for your organization first (only the organization Owner can request this). The five-step flow covers requesting activation, verifying it's enabled, creating an Enterprise Connection and generating a Self-Service SSO ticket URL, having your IT administrator configure the IdP with that URL, and verifying the login experience redirects correctly. ## Optional - [Upgrade Guides](https://docs.hivemq.com/hivemq/latest/upgrade/index.html): Version migration guides from HiveMQ 3.x to 4.x HiveMQ Upgrade Guides show you how to upgrade from one HiveMQ Enterprise MQTT Broker version to another. The HiveMQ broker uses semantic versioning for its version numbers with a major.minor.patch scheme where each monthly release is compatible with the next 18 monthly releases. - [HiveMQ 4.54 to 4.55 Migration Guide](https://docs.hivemq.com/hivemq/latest/upgrade/4-54-to-4-55.html): Migration guide for upgrading from HiveMQ 4.54.x to 4.55.x (LTS) HiveMQ 4.55 is the new HiveMQ LTS (Long Term Support) release. This guide covers breaking changes in the HiveMQ Enterprise Extension SDK, the JAX-RS 2.x to Jakarta EE 10 migration, and Netty 4.2 hostname verification changes in the HiveMQ Enterprise Bridge Extension. - [HiveMQ 4.28 LTS to 4.55 LTS Migration Guide](https://docs.hivemq.com/hivemq/latest/upgrade/4-28-to-4-55.html): Migration guide for upgrading from HiveMQ 4.28.x LTS to 4.55.x LTS This guide covers the full scope of changes between the HiveMQ 4.28.x and 4.55.x LTS releases, including Java version requirements, glibc requirements, Control Center v2, Data Hub, extension SDK changes, and the Kafka configuration validation enforcement. - [Load Balancer Setup](https://docs.hivemq.com/hivemq/latest/user-guide/load-balancer.html): Load balancer configuration for HiveMQ broker clusters A load balancer is a specialized technology used to evenly distribute incoming traffic across a cluster of servers. For production use cases, HiveMQ clusters are usually placed behind a load balancer to enhance scalability and improve overall system performance. - [Backup & Restore](https://docs.hivemq.com/hivemq/latest/user-guide/backup-restore.html): Data backup and recovery procedures Backups are an important part of every mission-critical MQTT deployment, as all software with persistent data carries the risk of data loss. HiveMQ provides two convenient ways to back up and restore your data: from the HiveMQ Control Center or with the HiveMQ REST API. - [MQTT Add-ons](https://docs.hivemq.com/hivemq/latest/user-guide/mqtt-add-ons.html): MQTT protocol add-on features HiveMQ MQTT Add-ons extend the standard functionality of MQTT to satisfy the needs of several key IoT use cases. HiveMQ MQTT Topic Add-ons are special analytical MQTT topics that you can use to automatically collect detailed information for all expired, dropped, or dead MQTT messages. - [Cloud Installation](https://docs.hivemq.com/hivemq/latest/user-guide/install-in-cloud.html): Deploy HiveMQ on AWS, Azure, GCP The HiveMQ broker is a cloud-native MQTT messaging broker that is enterprise-ready and well-designed for organizations that want to build and run scalable applications in modern, dynamic environments. You can install the HiveMQ broker on the cloud service provider of your choice, with basic installation information provided for frequently-used public cloud providers.