Introduction: The Stakes of IoT in Cold Chain Logistics

In modern logistics and supply chain management, data precision is not just an operational metric—it is the backbone of risk mitigation. This is especially true in cold chain logistics, where the continuous monitoring of temperature-sensitive goods such as pharmaceuticals, biologics, and perishable foods is mandatory. A temporary loss of connectivity or server downtime does not merely mean delayed data; it can result in catastrophic product spoilage, regulatory non-compliance, and severe financial liabilities.

To guarantee uninterrupted data ingestion from thousands of moving IoT sensors (telematics, ambient sensors, and smart containers), engineering teams must deploy a robust, resilient communication layer. Message Queuing Telemetry Transport (MQTT) has established itself as the de facto standard protocol for this purpose due to its lightweight nature. However, a single MQTT broker instance represents a single point of failure (SPOF). This technical guide explores how to build a High-Availability (HA) MQTT Cluster utilizing NanoMQ—an ultra-lightweight, high-performance MQTT broker tailored for edge and distributed environments—deployed across scalable Virtual Private Servers (VPS).

Why NanoMQ for Supply Chain Infrastructure?

While traditional MQTT brokers like Mosquitto or EMQX are widely utilized, NanoMQ brings distinct advantages to distributed logistics networks. Built on top of the NNG (Nanomsg Next Gen) scalability protocol and written in C, NanoMQ features an actor-model threading architecture that delivers exceptionally low latency and minimal resource consumption. This makes it uniquely suited for cost-effective VPS deployments where RAM and CPU allocations must be optimized without compromising throughput.

Key Architectural Benefits:

Ultra-low Footprint: Consumes a fraction of the memory required by Java or Erlang-based brokers, allowing more compute resources to be allocated to data processing and storage on the VPS.
Built-in Edge Capabilities: Seamlessly bridges edge data to the cloud, bridging the gap between moving transport trucks and central monitoring dashboards.
Advanced Bridging and Clustering: Supports sophisticated data routing mechanisms essential for multi-region supply chain architectures.

---

Architectural Overview of a High-Availability MQTT Cluster

A resilient HA architecture requires redundancy at every layer. For our logistics system, the architecture comprises three main components:

The Load Balancing Layer: A high-performance load balancer (such as HAProxy or NGINX) placed in front of the brokers to distribute incoming MQTT/TCP connections evenly and handle failover.
The Broker Cluster Layer: Multiple NanoMQ instances running on separate VPS nodes, synchronized to ensure that client subscriptions and messages are correctly routed across the entire cluster.
The Health Check/Data Layer: Continuous monitoring mechanisms to detect node failure and instantly reroute traffic.

Note: For true high availability, it is recommended to deploy VPS nodes across different availability zones or geographic regions to safeguard against localized data center outages.

---

Step-by-Step Implementation Guide

Step 1: Preparing the VPS Environment

For this deployment, we utilize three Ubuntu 24.04 LTS VPS instances. Ensure that internal networking is configured between the nodes to facilitate secure, low-latency inter-broker communication.

First, update the package repository and install the necessary dependencies on all nodes:

sudo apt-get update && sudo apt-get upgrade -y
sudo apt-get install -y curl gnupg2 software-properties-common

Step 2: Installing NanoMQ

Download and install the latest stable version of NanoMQ on each VPS node using the official repository or direct binary installation:

curl -s [https://assets.emqx.com/scripts/install-nanomq-deb.sh](https://assets.emqx.com/scripts/install-nanomq-deb.sh) | sudo bash
sudo apt-get install nanomq -y

Verify the installation by checking the service status:

nanomq --version

Step 3: Configuring the NanoMQ Cluster and Bridging

Edit the configuration file located at /etc/nanomq.conf on each node. To create an interconnected system suitable for supply chain data aggregation, we configure node-to-node bridging and high-performance listeners. Below is an optimized configuration blueprint for Node 1:

# NanoMQ Configuration Template

url="nmq-tcp://0.0.0.0:1883"
num_task_mq=10000
max_packet_size=1024KB

# Logging Configuration
log {
    to=[file, console]
    level=info
    dir="/var/log/nanomq"
    file="nanomq.log"
}

# Bridging setup to Node 2 for data redundancy
bridge.mqtt.node2 {
    server="mqtt-tcp://10.0.0.2:1883"
    proto_ver=4
    keepalive=60
    clean_start=true
    forwards=[
        {topic="coldchain/telemetry/#", qos=1}
    ]
}

Repeat this process on Node 2 and Node 3, adjusting the bridge target IPs to point to their respective peer nodes. This creates a redundant mesh topology where messages published to one broker are reliably accessible across the cluster.

Step 4: Setting Up HAProxy as the Load Balancer

Deploy a dedicated VPS or utilize a managed load balancer to act as the single entry point for all IoT devices. Install HAProxy:

sudo apt-get install haproxy -y

Modify /etc/haproxy/haproxy.cfg to balance the MQTT traffic across your NanoMQ nodes using a least-connections algorithm, which is ideal for long-lived MQTT sessions:

listen mqtt_cluster
    bind *:1883
    mode tcp
    option clitcpka
    timeout client 3h
    timeout server 3h
    balance leastconn
    server nanomq_node1 10.0.0.1:1883 check inter 2000 rise 2 fall 3
    server nanomq_node2 10.0.0.2:1883 check inter 2000 rise 2 fall 3
    server nanomq_node3 10.0.0.3:1883 check inter 2000 rise 2 fall 3

Restart HAProxy to apply the changes: sudo systemctl restart haproxy.

---

Optimizing for Cold Chain Logistics and Supply Chain Operations

Deploying the infrastructure is only half the battle; it must be tuned specifically for the realities of supply chain operations, where hardware gateways face unpredictable cellular connectivity on the road.

1. Handling Intermittent Connectivity with QoS 1

Cold chain sensors tracking refrigerated trucks often pass through cellular dead zones. To prevent data loss during these periods, enforce QoS 1 (At least once delivery). When a truck loses connection, NanoMQ holds the messages in its internal queue or edge cache and delivers them immediately upon reconnection.

2. Clean Session Configurations

Configure transport telematics gateways with clean_session=false. This ensures that the cluster maintains the client’s subscription state and queues missed messages while the vehicle is offline, preventing critical gaps in the temperature log history.

3. Data Serialization with Protocol Buffers

To reduce payload sizes and save bandwidth over cellular networks, serialize telemetry data (latitude, longitude, temperature, humidity, battery levels) using Protocol Buffers (Protobuf) or compressed JSON before transmitting it via MQTT.

---

Conclusion and Best Practices

Building a High-Availability MQTT Cluster using NanoMQ on VPS provides a cost-effective, enterprise-grade foundation for cold chain logistics. By decoupling the ingestion layer from the processing backend and introducing multi-node redundancy, supply chain operators can guarantee 24/7 visibility over sensitive cargo.

As you move to production, consider the following final recommendations: always enable TLS/SSL encryption (port 8883) to protect commercial data integrity, implement robust token-based authentication for edge devices, and couple your cluster with a monitoring solution like Prometheus and Grafana to track connection rates and broker health in real-time.

Building a High-Availability MQTT Cluster with NanoMQ for Cold Chain Logistics