FastBee

English

简体中文

English

简体中文

Appearance

FastBee2026-10-31
1595
9.9m

Built-in MQTT Broker for IoT Platforms ​

Decision guide for a built-in MQTT broker in an IoT platform

The short answer: for small to mid-sized FastBee projects centered on device connectivity, start with the built-in MQTT broker and skip deploying a separate messaging middleware. When connection scale, protocol features, or operational ownership outgrow the built-in broker's boundaries, switch to an external EMQX — or plan directly for the Cluster Edition's FMQ. This is not a "which replaces which" question; it is about which component count and capability boundary fits your current stage.

1. Scope and Evidence Boundaries ​

This article was written on October 31, 2026, based on public pages of the official FastBee documentation site, listed in the sources section. It includes no benchmarks of our own: every capacity statement cites its source and is not a capacity commitment for any project. Validate connection counts, throughput, and latency targets in your own POC with real devices and a realistic message model.

2. When the Built-in Broker Removes a Component ​

Per the official built-in MQTT Broker documentation, FastBee's open-source edition embeds a Netty-based MQTT broker inside the access service, starting in the same process as the backend:

  • MQTT 3.1.1, with TCP on 1883 and WebSocket on 8083;
  • QoS 0/1, retained messages, last-will messages, and both persistent and clean sessions;
  • Authentication reuses the platform's product ID + device key model, so device credentials stay consistent with platform device management.

For projects with modest device counts and a device-telemetry-plus-command-downlink workload, this means one fewer EMQX process in the deployment list — and none of the accompanying HTTP authentication, webhook, and rule configuration. Authentication, online/offline events, and message routing close the loop inside a single application, so troubleshooting no longer bounces between device, broker, and platform. Quick trials, secondary-development environments, and small self-hosted deliveries typically fall into this category.

3. Where the Built-in Broker's Limits Are ​

The built-in broker is the platform's own access component — not a general-purpose message broker, and not a drop-in EMQX replacement. Confirm these boundaries before you build on it:

  • Protocol features: the official documentation lists MQTT 3.1.1 with QoS 0/1. Projects that need MQTT 5.0 extensions or QoS 2 exactly-once semantics are outside its capability list.
  • Topic model: platform topics follow /{productId}/{deviceNum}/... and serve device-access semantics; the broker is not a general pub/sub bus between business systems, and custom payload formats go through rule scripts.
  • Deployment shape: the built-in broker targets single-node deployment and shares node resources with the application; clustered access, load balancing, and large-scale connections belong to the Cluster Edition.
  • Operations model: there is no standalone broker console, plugin system, or authentication extension ecosystem; projects that need the EMQX Dashboard, rule plugins, or custom auth chains will not find equivalents here.

If any of these is a hard requirement, evaluate an external broker directly instead of designing workarounds around the built-in one.

4. Verifying the MQTT Path: "It Connects" Is Not Enough ​

The acceptance bar is the same whether you use the built-in broker or external EMQX. Following the MQTT access guide, walk a minimal loop with MQTTX:

  1. Connect to port 1883 with a clientId in the S&deviceNumber&productId&userId format and confirm the device shows online in its detail page;
  2. Publish to /{productId}/{deviceNum}/info/post and /{productId}/{deviceNum}/property/post, and confirm device info and runtime state refresh;
  3. Subscribe to /{productId}/{deviceNum}/function/get, send a command from the platform, and have the device report the result back;
  4. Trigger a rule or scene linkage once, confirming data flows into the business loop.

The deployment FAQ calls this out explicitly: after switching broker implementations, verifying that a client can connect is not enough — device online status, property reporting, command downlink, and status callbacks all need re-verification. This applies equally to the built-in and external forms.

5. When to Move to External EMQX ​

The official technology stack documentation states the enabling condition plainly: EMQX is enabled "when an independent MQTT Broker or higher connection scale is required." In project terms, the signals are usually:

  • Connection counts or message throughput clearly exceed a single node's comfort zone, and the broker needs to scale independently;
  • You need MQTT 5.0, QoS 2, or EMQX's plugin, dashboard, and authentication ecosystem;
  • Organizationally, the broker is operated by a separate team, or you already run an EMQX cluster with an established monitoring practice.

FastBee's EMQX integration is an officially supported shape: EMQX validates device credentials through HTTP authentication (/iot/tool/mqtt/authv5) and reports device online/offline and subscription events back to the platform through a webhook (/iot/tool/mqtt/webhookv5). Full configuration samples are in EMQX installation and configuration. The switch is a backend setting:

yaml
server:
  broker:
    enabled: true   # true = built-in Netty broker; false = external EMQX (requires spring.mqtt.host-url)

Keep in mind the costs come back too: EMQX deployment, auth callbacks, webhook rules, console accounts, and upgrades all become your operational responsibility, and the deployment list goes back from "one application" to "application + messaging middleware."

6. When Connections Keep Growing: the Cluster Edition FMQ Path ​

When you need to scale access horizontally beyond a single node, FastBee's commercial route is the Cluster Edition: its in-house FMQ service cluster carries MQTT access, scaling out together with web clusters and load balancing — see the Cluster Edition documentation and FMQ cluster deployment. This is a different expansion path from "built-in broker → external EMQX": it keeps the platform's integrated authentication and device management model while turning the access layer itself into an independently deployable multi-node service.

Do not place an order based on architecture diagrams. A Commercial Edition benchmark is available; the Cluster Edition benchmark is still being written. Any capacity conclusion should rest on your own like-for-like stress tests, and edition and license boundaries follow the commercial license terms.

7. One-Page Decision Checklist ​

Project profileRecommended path
Quick trial, demo, secondary-development environmentBuilt-in broker
Small-to-mid self-hosted delivery, devices on MQTT 3.1.1 + QoS 0/1Built-in broker, accepted per Section 4
Needs MQTT 5.0 / QoS 2 / independently scalable broker / existing EMQX operationsExternal EMQX
Large-scale access with explicit HA and horizontal scaling requirementsEvaluate Cluster Edition FMQ, decided by POC benchmarks

8. Sources and Further Reading ​

The following sources were used to verify the facts in this article, checked on October 31, 2026:

9. FAQ ​

9.1. Can the built-in broker replace EMQX? ​

Not in the "replacement" sense. The built-in broker covers what FastBee device access needs — MQTT 3.1.1, QoS 0/1, retained and last-will messages — with authentication integrated into the platform. It does not offer MQTT 5.0, QoS 2, a standalone console, or a plugin ecosystem, and it is not a general message bus between business systems. Use external EMQX when you need those capabilities.

9.2. What changes when switching from the built-in broker to EMQX? ​

Set server.broker.enabled to false and configure spring.mqtt.host-url on the backend; on the EMQX side, configure HTTP authentication and a webhook pointing at the platform's /iot/tool/mqtt/authv5 and /iot/tool/mqtt/webhookv5 endpoints, and adjust the frontend WebSocket address and ports accordingly. After switching, re-verify online status, reporting, downlink, and callbacks end to end per Section 4.

9.3. How many devices can the built-in broker support? ​

The official documentation gives an order-of-magnitude reference of several thousand concurrent connections per node; that is a documentation statement, not a capacity commitment. The real ceiling depends on server specs, reporting frequency, message size, and business load. Reach formal capacity conclusions with stress tests using your own message model, and reference the hardware and measurement methodology of the Commercial Edition benchmark.

9.4. When should I evaluate the Cluster Edition directly? ​

When a project explicitly requires high availability and horizontal scaling at the access layer, or when single-node stress tests already miss connection and throughput targets, you do not have to pass through an "external EMQX" stage first — evaluate the Cluster Edition's FMQ service cluster, web cluster, and load balancing directly, and make the final call with your own POC benchmark data.

Recent Update