RabbitMQ vs Eclipse Mosquitto for MQTT: which to choose

Which broker fits your MQTT traffic: RabbitMQ or Mosquitto

RabbitMQ fits when MQTT traffic must share a broker with AMQP or STOMP consumers, or when device messages need replicated, quorum-based durability. Mosquitto fits when the workload is MQTT only, the broker must run on small hardware at an edge or site, and no other protocol needs to reach the same messages. Both brokers speak MQTT 3.1.1 and 5.0, so the protocol alone rarely decides the choice. The decision turns on three questions: whether non-MQTT consumers such as back-end services, analytics jobs or AMQP applications will read the same telemetry, which high availability model your fleet and operations team can support, and who will run the broker day to day, including upgrades, certificate rotation and on-call response.

If non-MQTT consumers exist, RabbitMQ's shared exchange model is the main reason to choose it. Devices publish over MQTT and a back-end service consumes from a queue over AMQP 1.0 without a bridge between two systems. Each additional protocol, plugin and queue type adds configuration and failure modes to test, so confirm that your team can monitor them. For high availability, RabbitMQ's quorum queues are Raft-replicated, while Mosquitto's open-source broker documents bridges for connecting brokers rather than a replicated cluster. Confirm with Cedalo which high availability features the Pro Edition provides and its licensing terms before you rely on them.

Mosquitto is the simpler choice when a single MQTT broker per site is enough and the operating team is small. Its footprint suits low-power hardware, and the mosquitto.conf bridge settings with certificate or pre-shared-key TLS handle site-to-cloud links. Ask the vendor or your own tests to confirm how many devices a given host sustains. In either case, pilot your real message rates, retained-message behavior and reconnect storms before committing, because those results matter more than general claims.

Which scenario favors RabbitMQ and which favors Mosquitto

This table maps common MQTT and messaging scenarios to the platform that usually fits better, with the condition that makes each choice hold. Read each row against your device constraints, back-end protocols and team skills, since several scenarios point to running both. The main takeaway is that a dedicated MQTT broker suits device-only fleets, while RabbitMQ earns its footprint when MQTT must meet AMQP services and replicated queues.

Scenario	Better fit	Reason and condition
MQTT-only fleet on constrained hardware	Mosquitto	Mosquitto is described as lightweight and suited to devices from low-power single board computers to full servers. This matters when the broker itself must fit on modest hardware and no AMQP consumers need the same data.
MQTT plus AMQP back-end services	RabbitMQ	RabbitMQ supports MQTT through a plugin alongside AMQP 1.0 and AMQP 0-9-1 in one broker. This matters when telemetry must reach AMQP consumers without a second messaging system to operate.
Multi-site bridging	Mosquitto	Mosquitto documents bridges to connect multiple brokers, with certificate and pre-shared-key TLS options for bridge links. This matters when sites need MQTT-to-MQTT forwarding, and you should confirm bridge behavior against your own network failure cases.
Kubernetes-hosted broker	RabbitMQ	The RabbitMQ Cluster Kubernetes Operator is published under MPL-2.0, which fits teams that manage brokers as cluster resources. Confirm operator support for your MQTT plugin settings and cluster sizing with your platform team before committing.
Air-gapped plant network	Mosquitto	A single Mosquitto broker running on-premises with local clients keeps the design small and easy to audit. Pick RabbitMQ instead if the plant also needs replicated queues for local plant applications.
Team already running RabbitMQ	RabbitMQ	Reusing the existing RabbitMQ cluster, monitoring and upgrade routine avoids a second broker to patch and back up. This matters only if the MQTT protocol versions and client features you need are supported by the enabled plugin, which you should verify.

How RabbitMQ and Mosquitto are built and what that means for operations

RabbitMQ and Mosquitto solve overlapping MQTT problems with different designs. The cards below cover what each design includes, what it asks of your team to run, and where the licensing and high availability boundaries sit, so you can match the broker to your device fleet and your operating capacity.

Multi-protocol core with MQTT as a plugin

RabbitMQ was built around AMQP 0-9-1 and treats MQTT as one protocol among several, enabled through plugins. Its supported MQTT versions are 3.1, 3.1.1 and 5.0, alongside AMQP 1.0, STOMP and Streams. Operating consequence: one cluster can serve device telemetry and back-office AMQP consumers, but your team owns the plugin configuration, the protocol mix and the upgrade path for every protocol in use. Confirm which MQTT features your device firmware needs before you commit.

Raft-based quorum queues for replication

Quorum queues are durable, replicated queues built on the Raft consensus algorithm, and they are the replication model RabbitMQ recommends for data that must survive node loss. Classic queue mirroring was removed starting with RabbitMQ 4.0. Operating consequence: replicated queues need an odd number of members to keep a majority, and each replica adds disk and network load. Ask your broker team how MQTT subscriptions map onto queues before you size the cluster.

Kubernetes operator under MPL-2.0

The RabbitMQ Cluster Kubernetes Operator is published under MPL-2.0 in its own GitHub repository, which lets teams that run RabbitMQ on Kubernetes automate deployment and cluster lifecycle without a commercial license for the operator itself. Operating consequence: the operator manages the cluster, but your platform team still owns storage classes, network policy, backups and version pinning. Check the operator release against the RabbitMQ server version you plan to run.

Single lightweight broker with small footprint

Eclipse Mosquitto is a single broker focused on MQTT. It implements MQTT 5.0, 3.1.1 and 3.1 and is described by its project as suitable for devices from low-power single board computers to full servers. Operating consequence: there are fewer moving parts to patch and monitor, which suits edge sites and small fleets. The trade-off is that replication, large-scale clustering and many non-MQTT integrations are not part of the core product, so confirm your needs against the edition you plan to run.

Bridges between brokers with TLS and keys

Mosquitto connects multiple brokers through bridges configured in mosquitto.conf, with certificate-based or pre-shared-key TLS options for bridge connections. This lets a site broker forward selected topics to a central broker. Operating consequence: bridges are a topology you design and monitor by hand, including certificate rotation and topic filters, and they are not a replication mechanism. Ask whether your forwarding rules need failover behavior that bridges alone will not provide.

Open-source core versus Pro high availability

The open-source Mosquitto edition covers core MQTT features, on-premises deployment and community forum support. Cedalo's commercially licensed Pro Edition adds high availability, integrations, REST APIs, persistent queuing, cloud deployment and professional support. Operating consequence: if your uptime target requires failover for the MQTT broker, the high availability decision is a licensing decision, and you should price it with the vendor. Without it, plan redundancy with your own infrastructure and test failover before go-live.

Protocol versions, clustering, replication and licensing side by side

This table compares how RabbitMQ and Eclipse Mosquitto handle MQTT versions, other protocols, replication, TLS, WebSocket access, licensing and management. Read each row against your device fleet, your integration targets and your support model, since the right broker often depends on which of these you need beyond MQTT itself. The main takeaway is that Mosquitto is the narrower, lighter MQTT broker, while RabbitMQ earns its footprint when MQTT must sit alongside queue semantics and replicated data.

Capability	RabbitMQ	Eclipse Mosquitto
MQTT versions	MQTT 3.1, 3.1.1 and 5.0 through the MQTT plugin	MQTT 5.0, 3.1.1 and 3.1 in the core broker
Other protocols	AMQP 1.0 (core since 4.0), STOMP, RabbitMQ Streams, AMQP 1.0, MQTT and STOMP over WebSocket	Client libraries and tools only, no AMQP or STOMP broker role in the supplied facts
Replication and high availability	Quorum queues replicated with Raft; classic queue mirroring removed in 4.0	Bridges connect brokers; high availability is a Pro Edition feature from Cedalo, so confirm the edition you need
TLS and client certificates	Confirm the exact TLS and certificate settings for your MQTT listener in the RabbitMQ documentation	TLS, client certificates and pre-shared-key options for bridges documented in the mosquitto.conf manual
WebSocket support	MQTT over WebSocket supported through plugins	WebSockets supported on the public test server; confirm listener setup in your own build
License	MPL 2.0 for server and tier 1 core plugins	EPL-2.0 or BSD-3-Clause (dual licensed); the Pro Edition is commercially licensed
Management tooling	Management UI and CLI tooling; confirm plugin set for your MQTT deployment	mosquitto_ctrl and mosquitto_passwd admin tools, plus mosquitto_pub, mosquitto_sub and mosquitto_rr clients

What is free, what is paid and who supports each broker

RabbitMQ server and its tier 1 core plugins are licensed under MPL 2.0, so the broker itself carries no license fee. The cost of running it sits in your own staff, infrastructure and the time spent on upgrades. Community support follows the release lifecycle published by the project. RabbitMQ 4.3.6 was released on September 16, 2026, with community support until January 31, 2027, and the 4.2 line reached the end of community support on July 31, 2026.

License: MPL 2.0 for the server and core plugins, with some OCF files under Apache 2.0.
Current community line: 4.3, supported by the community until January 31, 2027.
Ended line: 4.2 left community support on July 31, 2026, so new deployments should start on a supported line.
Who supports it: community channels and your own engineers, unless you buy a commercial agreement.
Cost drivers: staff time for upgrades, monitoring and capacity planning, plus the hosting you provision.

Confirm with your team whether your upgrade cadence can keep pace with community support windows, since that is the date that drives your planning.

When IoT traffic needs both brokers in one architecture

The hybrid pattern puts Mosquitto at the edge for device connectivity and a small footprint, then bridges it to RabbitMQ in the core for replicated back-end processing. The reverse layout also works: RabbitMQ runs in the core as the system of record, with lightweight Mosquitto brokers near devices in plants, sites or vehicles. Two systems are justified when devices need a broker that runs on constrained hardware and survives intermittent links, while the back end needs quorum queues, AMQP 1.0 consumers or stream access that a device-side broker should not carry. If every device and every consumer speaks MQTT and one site is enough, a single broker is simpler to run.

Running both adds a second product to patch, monitor, certify and back up, plus a bridge that must be tested under failure. Your cost comes from your own engineers and infrastructure, since both projects are open source and the commercial route for Mosquitto is Cedalo's Pro Edition, which adds high availability and integrations. Ask whether the team has operators who can own two broker lifecycles, how each site is monitored when its link to the core drops, and who owns the bridge configuration over time. Mosquitto's bridges are configured in mosquitto.conf, so confirm in the mosquitto.conf manual which bridge options, certificate and pre-shared-key TLS settings, and reconnection behavior apply to your version before you design the topic mapping.

Before you commit, run a proof of concept that breaks the link on purpose. Test what happens to messages published at the edge during an outage, whether QoS and retained messages behave as your devices expect after reconnection, and how duplicate delivery is handled at the core. Verify that TLS is enforced on both hops, including client certificates for devices, and that the bridge does not fall back to unencrypted listeners. Record who is paid for each step in the quote: the initial architecture, the bridge testing, the hardening and the ongoing upgrades of both systems, since the costs recur for as long as both brokers run.

What drives the running cost of each broker

This table sets out who gets paid for what when you run RabbitMQ or Mosquitto, and which costs recur. Read each row as a question to put to your team and to any vendor quote, since the drivers differ sharply between a lightweight broker and a clustered, replicated one. The main takeaway is that Mosquitto's low running cost holds only while high availability is not required, and that RabbitMQ's commercial support and lifecycle costs depend on which release you run.

Cost component	RabbitMQ (MPL-2.0, with optional commercial support)	Eclipse Mosquitto (EPL-2.0 or BSD-3-Clause, with optional Pro Edition)
Infrastructure footprint	Clustered nodes with replicated quorum queues need several nodes, disk and memory sized for replicas, and load balancing; this footprint recurs every month.	A single small broker runs on modest hardware, from low-power single board computers to full servers; the footprint grows only if you add bridged brokers or a second instance.
Skills and staffing	Operators need working knowledge of Erlang-based clustering, quorum queue behavior and the AMQP and MQTT plugins, which is ongoing staff time or retainer hours.	Operators mainly need MQTT topic design, TLS and client certificate handling and bridge configuration; ongoing time is usually lower, though it still recurs.
Support contract	Commercial support is bought from Broadcom or a partner, is recurring, and is only needed if your organization requires vendor response commitments.	Community support comes through the community forum at no license fee; a commercial contract is available only through Cedalo's Pro Edition or professional support.
Upgrade cadence against community support windows	Community support windows are short, so you plan regular upgrades to stay supported, and extended support to later dates requires a valid commercial support license.	Upgrades are generally smaller in scope, but you still schedule and test them; confirm current support terms for the release line you intend to run with Cedalo or the project.
Pro Edition or commercial license fees	No license fee for the open-source server under MPL-2.0; any commercial support or lifecycle extension is a separate paid item to request in writing.	Pro Edition is a commercially licensed product from Cedalo that adds high availability, integrations, REST APIs, persistent queuing and professional support; request its price and terms from the vendor.
High availability design effort	Replicated quorum queues are built in, but designing node placement, failure testing, network partition handling and client reconnection is a one-time effort plus ongoing testing.	Open-source Mosquitto offers bridges and no built-in high availability, so an HA design is custom work; Pro Edition's high availability is the vendor-supported alternative to evaluate.
Client and integration work	Clients using AMQP 0-9-1, AMQP 1.0, MQTT and STOMP may need separate configuration and testing, which adds one-time effort per protocol.	Client libraries and command line tools are lightweight, so integration effort is usually lower for MQTT-only fleets, though broker-side integrations may need custom work.
What to request in a quote	Named support tier, response commitments, which release lines and end dates are covered, and the cost of any disaster recovery or long-term support option.	Pro Edition scope and license model, high availability architecture included, support hours, supported Mosquitto versions and whether bridge and integration work is included in the price.

Moving device traffic from Mosquitto to RabbitMQ or back

This sequence moves MQTT device traffic between Mosquitto and RabbitMQ without a single-day cutover, so each site or fleet changes broker only after topics, credentials and certificates have been checked on both sides. It produces a documented mapping, a bridged period where both brokers carry the same traffic, and a decommissioned source broker.

Inventory client MQTT versions and topics
The client owner and the platform team list every device class, the MQTT version each client speaks (3.1, 3.1.1 or 5.0), the topics it publishes and subscribes to, and any retained message or session behavior the application depends on. Mosquitto supports MQTT 5.0, 3.1.1 and 3.1, and the RabbitMQ MQTT plugin supports 3.1, 3.1.1 and 5.0, so version support is usually not the blocker, but features such as shared subscriptions or specific session settings should be confirmed against each broker's current documentation. The step is done when every device class appears in a spreadsheet or inventory file with its version, topics and dependencies, and the owners have signed off on it.
Decide the topic and QoS mapping
The architecture owner writes a mapping from each source topic to its destination on the target broker, including any namespace or prefix changes, and records the quality of service level each subscriber expects. RabbitMQ maps MQTT topics onto its own exchange and queue model, so the team should test how topic wildcards, retained messages and QoS 1 or 2 delivery behave on RabbitMQ before committing to a layout. Ask the RabbitMQ and Mosquitto documentation to confirm each behavior for your chosen versions. The step closes with a reviewed mapping document that every consuming service team has accepted.
Run both brokers in parallel with bridging
The platform team deploys the target broker alongside the existing one and connects them with a bridge so messages published on one side reach subscribers on the other during the transition. Mosquitto's configuration manual documents bridges as the way to connect brokers, including certificate and pre-shared-key TLS options for bridge connections. For a Mosquitto-to-RabbitMQ move, the bridge is configured on the Mosquitto side, and the team should confirm how the bridge handles loops, duplicate delivery and topic remapping with the RabbitMQ side. The step is done when test devices publish on one broker and a subscriber on the other receives every message in a controlled test, with no duplicates or loops observed.
Migrate device credentials and TLS certificates
The security team moves device identities into the target broker's authentication store and checks which certificates can be reused. Client certificates issued by an existing certificate authority usually transfer if the target broker trusts the same authority, while usernames, passwords and pre-shared keys have to be recreated, because the password and ACL files are broker-specific. Mosquitto's mosquitto_passwd tool and RabbitMQ's user and permission model are not interchangeable, so each credential is re-provisioned and rotated where the device supports it. The step is complete when a sample of devices from each class authenticates to the new broker and unauthorized topic access is refused in a negative test.
Rebuild access rules, queue policies and monitoring
The platform team recreates what does not transfer: topic access control lists, RabbitMQ queue types and policies for MQTT traffic, retained message handling, and dashboards and alerts for connection counts, message rates and broker health. Mosquitto ACLs are file-based, and RabbitMQ uses its own permission and policy model, so each rule is written again and reviewed against the mapping from step two. For high availability, the team should confirm which replication settings apply to the queues created for device traffic, because RabbitMQ replicates queues through quorum queues and classic queue mirroring is no longer available from RabbitMQ 4.0. The step is done when a documented access matrix matches the inventory and alerts fire in a staged test.
Cut over by site or fleet
The operations team moves one site or device fleet at a time by updating broker addresses, certificates and credentials on the devices or gateways, then confirming that telemetry arrives on the new broker and that commands reach the devices. Starting with a small, low-risk group lets the team find problems in a controlled scope, and each group has a documented rollback that points devices back to the original broker. The bridge stays active for traffic from devices not yet moved so consumers see one continuous data stream. The step is complete when every device in the group reports to the new broker and no bridged messages remain pending for that group.
Decommission the source broker
Once every device class has moved and the bridge carries no traffic, the team removes the bridge, revokes the old broker's credentials and certificates, archives configuration and logs according to the organization's retention policy, and shuts down the source broker. Teams that keep Mosquitto for another site or use case should record which topics and clients remain on it so the bridge is not restored by accident. The step closes with a signed decommissioning record, updated network diagrams and an inventory that shows the single broker now carrying device traffic.

Where MQTT broker projects usually run long

MQTT projects rarely overrun on the broker install. They overrun on the device side and on the trust model around it. Firmware teams must confirm which MQTT version each device speaks (Mosquitto implements 5.0, 3.1.1 and 3.1, and RabbitMQ's MQTT plugin supports 3.1, 3.1.1 and 5.0), then pin client libraries and plan over-the-air updates. Mosquitto ships a C and C++ client library, so a C-based device stack has a short path there. Confirm the client library for your firmware language before you estimate, because a library change means a firmware release and a fleet rollout.

Certificate lifecycle is the most common source of late surprises. Both brokers can run MQTT over TLS with client certificates, but issuing, rotating and revoking device certificates is a process you own. Mosquitto's bridge options also accept certificate and pre-shared-key TLS, so any broker-to-broker links need their own rotation plan. Authorization design takes equal care. Decide early whether access is per topic, per device identity or per tenant, and test that the chosen model holds under real client behavior. Ask each vendor, in writing, which authorization features the open-source edition provides and which sit in a paid tier.

HA testing and back-end integration are where scopes are most often underspecified. Mosquitto's high availability sits in the commercial Pro Edition, so an open-source design must document how it handles broker failure. RabbitMQ's quorum queues offer Raft-based replication, but MQTT sessions and their queue behavior need failover tests that match your device reconnect logic. Before work starts, the written scope from DeployOpen should name the failover scenarios, the consumers that receive telemetry, and the acceptance tests for each. Confirm with the vendor what the community edition guarantees, and treat anything not in that list as a change order.

Questions buyers ask before choosing or hiring help

Can Mosquitto do high availability for free?

Not in the open-source edition, as far as the supplied project information shows. Mosquitto is dual licensed under EPL-2.0 or BSD-3-Clause and documents bridges for connecting multiple brokers, with certificate and pre-shared-key TLS options for those bridges. The mosquitto.org comparison places high availability, persistent queuing and REST APIs in Cedalo's commercially licensed Pro Edition. A bridge link is not the same as failover, so if your design needs automatic takeover, price the Pro Edition or design the failover yourself and test it. Confirm the exact behavior of your chosen topology with Cedalo and in your own lab before you commit.

Does RabbitMQ support MQTT 5.0?

Yes. RabbitMQ supports MQTT 3.1, 3.1.1 and 5.0 through its MQTT plugin, alongside AMQP 1.0, STOMP and MQTT and AMQP over WebSocket. Mosquitto also implements MQTT 5.0, 3.1.1 and 3.1, so protocol version alone rarely separates the two. Check the features your devices depend on, such as shared subscriptions, retained message behavior and session handling, against each broker's documentation and your own test clients before you decide.

How much effort is a switch between RabbitMQ and Mosquitto?

The effort depends on how tightly your devices and back-end consumers are coupled to broker-specific behavior. Device firmware that speaks MQTT over standard topics may move with configuration changes, while consumers that rely on RabbitMQ exchanges, queues or streams need rework. Expect work in four places: topic and ACL design, authentication and TLS certificates, retained and persistent message handling, and the monitoring and alerting you built around the old broker. Ask for a written inventory of these dependencies before estimating effort, and run a pilot with a representative device subset.

Can our team run this without outside help?

Often yes, if you already operate a message broker and have an internal owner for TLS, identity and monitoring. Mosquitto is small and documented, with admin tools such as mosquitto_passwd and mosquitto_ctrl included, so a single-broker deployment is a modest operating task. A clustered RabbitMQ deployment, or a Mosquitto high-availability design, adds components that need upgrades, backups and failure drills. Be honest about who is on call. Check RabbitMQ's community support window against your upgrade plan, because community support for 4.2 ended on July 31, 2026.

What does a fixed-scope implementation need from us?

DeployOpen plans, implements, hardens, documents and supports self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. To scope an MQTT project, prepare the device count and types, the protocol versions in use, the topic tree, your TLS and certificate authority arrangements, the back-end consumers, your availability target, and your target environment, whether cloud, data center or air-gapped. DeployOpen does not publish a price list, so a quote follows from that written scope. Ongoing support and upgrades are available as retainers.

When should we run both RabbitMQ and Mosquitto?

Run both when devices publish telemetry through a lightweight MQTT edge and the enterprise needs replicated, durable queues for downstream processing. Mosquitto can sit at the edge, with a bridge forwarding selected topics to a RabbitMQ cluster that uses quorum queues for durability. This split is a design choice, not a default. It adds a second broker to operate and secure, so justify it with a clear requirement for each layer, and confirm bridge behavior under network loss in your own test environment.

Which costs recur after the first deployment?

Recurring costs include the licence or support subscription for any commercial edition, infrastructure for each broker and its replicas, certificate renewal, patching and upgrades, and the staff time spent on monitoring. One-time costs include design, integration with identity and logging, migration and testing. Mosquitto's free core lowers licence spend, but if you need the Pro Edition for high availability, that subscription recurs. For RabbitMQ, commercial long-term support is available only with a valid commercial support license, so ask Broadcom about lifecycle dates for the version you plan to run.

Primary sources for MQTT protocol, licensing and release facts

Start verification with the RabbitMQ release information page before you commit to a version. It separates community support from commercial support, and the two end on different dates. Confirm which branch you would run, such as the 4.3 line that received 4.3.6 on September 16, 2026, and whether your organization holds a commercial support license that changes the lifecycle you can plan around. Record the dates in your change calendar, because a broker that falls out of support becomes an audit finding even when it runs without incident.

Next, read the RabbitMQ protocols page against your device list. Check which MQTT versions the plugin supports (3.1, 3.1.1 and 5.0) and confirm that your clients use one of them, since MQTT 5.0 features such as shared subscriptions and reason codes depend on both ends agreeing. The same page covers WebSocket access, which matters if browser dashboards connect to the broker. Ask your RabbitMQ and device vendors to confirm any feature you rely on, because plugin behavior can differ from the protocol specification.

For the replication and durability side of the decision, read the RabbitMQ quorum queues documentation and note that classic queue mirroring was removed starting with RabbitMQ 4.0. Then open the Eclipse Mosquitto home page and the mosquitto.conf manual to see how bridges and TLS options are configured. Confirm which high availability features apply to the open-source broker and which are described only for the commercially licensed Pro Edition, and check the Mosquitto GitHub repository for the license file and current tags before you write licensing terms into a procurement record.

How DeployOpen helps choose, implement or migrate your MQTT broker

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the broker decision can follow your device fleet, network and operating model. We start from written scope and deliver the broker in your cloud accounts, data center or air-gapped network.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We map which device clients, MQTT versions and co-existing AMQP or STOMP workloads the broker must serve.
We record the high availability, TLS and client certificate requirements that decide between clustering and bridged brokers.

How we build

We deploy the chosen broker in your environment, with TLS, client authentication and access control configured to your written requirements.
We test connection behavior with representative device traffic, including reconnects, retained messages and failover where the design relies on them.
We document topology, bridge settings and configuration keys so your team can reproduce the environment after handover.

How we hand over

Handover includes configuration files, runbooks, network diagrams and the test results agreed in the written scope.
We walk your operations team through upgrade steps, certificate rotation and backup and restore procedures for the broker.
We state which licensing, edition and support decisions remain with you, including whether a commercial high availability edition is needed.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
We can plan upgrades against the vendor's published release and support windows, which you confirm with the project or vendor.
Quotes follow from the written scope, so ask for the components, environments and test cases each cost line covers.

RabbitMQ vs Eclipse Mosquitto for MQTT