Skip to content
Book a Demo
software
Data Management
use cases
Network & Device Management
Licensing
3rd party

EMQX Edge Broker

Lightweight MQTT Broker for IoT Edge

Deploy a robust, high-performance MQTT broker at the edge, process data locally, and reliably bridge data to the cloud.

Blazing-Fast: Optimized for edge with low latency and high throughput—up to 10x faster than Mosquitto when running on multi-core CPUs.

Ultra-Lightweight: Minimal footprint with efficient resource utilization, perfect for edge devices. Boot memory footprint is as low as 200KB.

Cross-Platform: Runs seamlessly on multiple operating systems and hardware architectures, including Linux, Windows, ARM, x86, and RISC-V.

Learn more: https://www.emqx.com/en/products/emqx-edge

Contact us to add to Neeve
Benefits of EMQX Edge on Neeve
Integrating EMQX Edge with the Neeve Secure Edge platform provides a military-grade messaging backbone for building automation. While standard brokers can be heavy, EMQX Edge is optimized for the Neeve compute profile, ensuring maximum performance for OT data streams.
Ultra-Low Latency: Optimized for multi-core edge CPUs, providing sub-5ms message latency for real-time control loops.
Network Resilience: Native “Store and Forward” buffering ensures data integrity during intermittent cloud connectivity.
Unified Namespace (UNS): Easily aggregate data from Niagara, Node-RED, and Netpulse into a single, standardized MQTT topic tree.
Edge Intelligence: Utilize the SQL-based rule engine to filter, transform, and aggregate data locally before it leaves the building.
Zero-Trust Bridging: Securely bridge local MQTT traffic to central EMQX Enterprise or AWS IoT Core instances via encrypted TLS/QUIC tunnels.
Architecture
Deployment Architecture on Neeve
Deployment model: Singleton (one per site/namespace). Typically serves as the central hub for all other local services.
Workload: High-concurrency, low-memory. Capable of handling 100k+ connections with <10MB memory footprint.
Components: NanoMQ Core, SQL-like Rule Engine, and MQTT Bridge plugin.
Data flows: * TCP 1883/8883: Standard/Secure MQTT for local devices.
TCP 8083/8084: MQTT over WebSockets for web-based UIs.
TCP 8081: REST API for management and monitoring.
Failure domains: Stateless for routing; stateful for bridged message buffering. If the pod fails, local volatile messages are lost, but queued bridge data is recovered from the persistent volume.