HostCart
All articles
Technology

Step-by-Step Guide: Installing Node‑RED and MQTT on Unmanaged Ubuntu for Seamless IoT Data Ingestion

Learn how to build a reliable, self-hosted IoT data pipeline by combining Node-RED and a Mosquitto MQTT broker on an unmanaged Ubuntu server. This step-by-step guide covers everything from initial server hardening and credential security to constructing visual flows for parsing sensor data. Gain complete control over your telemetry, reduce network latency, and eliminate cloud licensing overhead with a fully custom on-premises deployment.

7 min read
Step-by-Step Guide: Installing Node‑RED and MQTT on Unmanaged Ubuntu for Seamless IoT Data Ingestion

In the rapidly expanding world of the Internet of Things (IoT), reliable data ingestion is the backbone of every successful deployment. While cloud‑based services make it easy to get started, many organizations prefer to keep their data pipelines on‑premises for reasons ranging from latency and bandwidth constraints to strict security policies. This guide walks you through the complete, step‑by‑step process of setting up a robust Node‑RED flow engine and an MQTT broker on an unmanaged Ubuntu server—perfect for anyone who wants full control over their IoT data stack without the overhead of managed services.

Why Combine Node‑RED and MQTT on Ubuntu?

Before diving into the technical steps, it helps to understand why this pairing works so well:

  • MQTT – A lightweight, publish/subscribe protocol designed for low‑bandwidth, high‑latency networks. It’s ideal for connecting sensors, actuators, and edge devices.
  • Node‑RED – A flow‑based development tool that lets you visually wire together devices, APIs, and services. It can act as a bridge between MQTT topics and downstream systems (databases, cloud services, dashboards, etc.).
  • Ubuntu Server – A stable, widely supported Linux distribution with a massive package ecosystem, making it a solid foundation for long‑running IoT services.

When you host both on the same unmanaged machine, you gain:

  1. Complete control over security hardening and network configuration.
  2. Zero‑cost licensing and the ability to tailor resources exactly to your workload.
  3. Full visibility into logs, performance metrics, and the ability to automate updates.

Prerequisites and Initial Server Setup

1. A Fresh Ubuntu Installation

These instructions assume you are working with Ubuntu 22.04 LTS (or newer) on a dedicated server or a virtual machine. Ensure you have root or sudo access.

2. Basic Security Hardening

Even though the focus of this article is on Node‑RED and MQTT, a secure foundation is essential.

  1. Update the system:
    sudo apt update && sudo apt upgrade -y
  2. Create a non‑root user (replace iotadmin with your preferred name):
    sudo adduser iotadmin
    sudo usermod -aG sudo iotadmin
  3. Configure a firewall (UFW):
    sudo ufw allow OpenSSH
    sudo ufw allow 1883/tcp   # MQTT
    sudo ufw allow 8883/tcp   # MQTT TLS (optional)
    sudo ufw allow 1880/tcp   # Node‑RED UI
    sudo ufw enable
  4. Disable password authentication for SSH and use key‑based login only (edit /etc/ssh/sshd_config).

3. Install Essential Tools

These packages make later steps smoother:

sudo apt install -y curl git build-essential python3-pip

Installing and Configuring the MQTT Broker (Mosquitto)

1. Install Mosquitto

Mosquitto is the most popular open‑source MQTT broker and is available directly from Ubuntu’s repositories.

sudo apt install -y mosquitto mosquitto-clients
sudo systemctl enable mosquitto
sudo systemctl start mosquitto

2. Secure the Broker

By default Mosquitto runs without authentication, which is fine for testing but not for production. Follow these steps to enable password‑based access and TLS encryption.

  1. Create a password file:
    sudo mosquitto_passwd -c /etc/mosquitto/passwd iotuser
    You’ll be prompted for a password. Add additional users with -b if needed.
  2. Configure Mosquitto (edit /etc/mosquitto/conf.d/default.conf):
    listener 1883
    allow_anonymous false
    password_file /etc/mosquitto/passwd
    
    # Optional TLS listener
    listener 8883
    certfile /etc/mosquitto/certs/server.crt
    keyfile /etc/mosquitto/certs/server.key
    require_certificate false
    allow_anonymous false
    password_file /etc/mosquitto/passwd
  3. Generate self‑signed certificates (or use certificates from a trusted CA):
    sudo mkdir -p /etc/mosquitto/certs
    sudo openssl req -new -x509 -days 365 -nodes -out /etc/mosquitto/certs/server.crt -keyout /etc/mosquitto/certs/server.key
    chmod 600 /etc/mosquitto/certs/server.*
  4. Restart Mosquitto to apply changes:
    sudo systemctl restart mosquitto

3. Verify the Setup

Open two terminal windows (or use screen/tmux) and run:

# Publisher
mosquitto_pub -h localhost -t test/topic -m "Hello from MQTT" -u iotuser -P yourpassword

# Subscriber
mosquitto_sub -h localhost -t test/topic -u iotuser -P yourpassword

If the subscriber prints “Hello from MQTT,” your broker is ready.

Deploying Node‑RED on Ubuntu

1. Install Node.js (LTS)

Node‑RED requires a recent LTS version of Node.js. Use the NodeSource repository for the latest stable release.

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs

Verify the installation:

node -v   # should show v20.x
npm -v

2. Install Node‑RED Globally

sudo npm install -g --unsafe-perm node-red

3. Create a Dedicated Service Account

Running Node‑RED as its own user improves isolation.

sudo adduser --system --home /opt/nodered --gecos "Node-RED service" --group nodered
sudo chown -R nodered:nodered /opt/nodered
sudo -u nodered -H bash -c "npm install -g --unsafe-perm node-red"

4. Set Up a Systemd Service

Create /etc/systemd/system/nodered.service with the following content:

[Unit]
Description=Node-RED flow engine
After=network.target

[Service]
Type=simple
User=nodered
WorkingDirectory=/opt/nodered
ExecStart=/usr/bin/env node-red -v
Restart=on-failure
KillSignal=SIGINT
SyslogIdentifier=nodered

[Install]
WantedBy=multi-user.target

Enable and start the service:

sudo systemctl daemon-reload
sudo systemctl enable nodered
sudo systemctl start nodered

5. Access the Node‑RED Editor

By default Node‑RED listens on port 1880. Open a browser and navigate to http://<your‑server‑ip>:1880. The first login will prompt you to set an admin password. Use the built‑in node-red-admin tool for stronger hashing:

node-red-admin hash-pw

Copy the generated hash into ~/.node-red/settings.js under adminAuth (see the official docs for the exact JSON structure).

Connecting Node‑RED to MQTT: Building Your First Ingestion Flow

1. Install the MQTT Nodes

In the Node‑RED sidebar, go to Manage palette → Install and search for “node‑red‑contrib‑mqtt‑broker”. Install it; the core mqtt in and mqtt out nodes are already included.

2. Create a Simple Ingestion Flow

  1. Drag an “mqtt in” node onto the canvas. Double‑click it and configure:
    • Server: Add new mqtt‑broker → tcp://localhost:1883
    • Username / Password: iotuser / yourpassword
    • Topic: sensor/+/data (wildcard for any sensor ID)
  2. Add a “function” node to parse JSON payloads and add a timestamp:
    msg.payload = JSON.parse(msg.payload);
    msg.payload.receivedAt = new Date().toISOString();
    return msg;
  3. Connect a “file” node (or a database node) to persist the data. For a quick test, use the file node with a filename like /opt/nodered/data/{{{topic}}}.log.
  4. Deploy the flow and publish a test message from a device:
    mosquitto_pub -h <server-ip> -t sensor/room1/data -m '{"temp":22.5,"hum":45}' -u iotuser -P yourpassword
  5. Check the log file or the Node‑RED debug pane to confirm the message was received and stored.

3. Scaling the Flow for Production

When moving beyond a proof‑of‑concept, consider the following enhancements:

  • Use a proper time‑series database (InfluxDB, TimescaleDB, or VictoriaMetrics) instead of flat files.
  • Introduce a “catch” node to handle JSON parsing errors and route malformed payloads to a dead‑letter queue.
  • Apply rate limiting with the “throttle” node to protect downstream services.
  • Implement TLS on the MQTT client side by switching the broker URL to mqtts://localhost:8883 and providing the CA certificate.

Monitoring, Backups, and Maintenance

1. Logging and Metrics

Both Mosquitto and Node‑RED write logs to /var/log. Set up logrotate to keep files manageable:

sudo cat > /etc/logrotate.d/mosquitto <<'EOF'
/var/log/mosquitto/*.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
}
EOF

Node‑RED can emit metrics to Prometheus via the node-red-contrib-prometheus node. Combine this with systemd service status checks for a complete health view.

2. Regular Backups

Automate daily backups of the following directories:

  • /etc/mosquitto/ – broker configuration and password file.
  • /opt/nodered/.node-red/ – flows, credentials, and settings.
  • Any persistent data stores (e.g., InfluxDB data directory).

Example rsync script (run via cron):

#!/bin/bash
BACKUP_DIR=/var/backups/iot-$(date +%F)
mkdir -p "$BACKUP_DIR"
rsync -a /etc/mosquitto/ "$BACKUP_DIR/mosquitto"
rsync -a /opt/nodered/.node-red/ "$BACKUP_DIR/nodered"
# Add DB backup commands here

3. Updating Packages Securely

Because the server is unmanaged, you control when updates happen. Adopt a “staging then production” approach:

  1. Clone the production server to a test VM.
  2. Run sudo apt update && sudo apt upgrade -y on the test instance.
  3. Validate that Mosquitto and Node‑RED still start and that flows operate as expected.
  4. Apply the same updates to the live server during a maintenance window.

Conclusion

Setting up a self‑hosted Node‑RED and MQTT stack on an unmanaged Ubuntu server may seem daunting at first, but the process is straightforward when broken into logical steps: secure the host, install and harden Mosquitto, deploy Node‑RED as a systemd service, and wire the two together with a clean ingestion flow. By following the guidelines above, you gain a flexible, low‑latency pipeline that can scale from a handful of sensors to thousands of devices—all while retaining full control over security, data ownership, and operational costs.

With a solid foundation in place, you can now focus on building richer analytics, dashboards, and automated actions that turn raw IoT telemetry into actionable insights. Happy wiring!

node-redmqttubuntuiotmosquittosystemdsensor-datalinux

More in Technology

Boost WooCommerce Performance: Step‑by‑Step Guide to Setting Up Read‑Replicas on Separate DB VPS Nodes

Boost WooCommerce Performance: Step‑by‑Step Guide to Setting Up Read‑Replicas on Separate DB VPS Nodes

High-traffic WooCommerce stores often face severe database bottlenecks during traffic spikes and flash sales. Offloading read-heavy queries to dedicated database read replicas on separate VPS nodes dramatically improves performance, reduces latency, and enhances site reliability. This comprehensive guide walks you through the step-by-step architecture, setup, and best practices for integrating database replicas into your WordPress stack.

Mastering Point-In-Time Recovery in PostgreSQL: A Step‑by‑Step Guide with WAL Archives and pgBackRest

Mastering Point-In-Time Recovery in PostgreSQL: A Step‑by‑Step Guide with WAL Archives and pgBackRest

Recovering a PostgreSQL database to an exact moment—Point‑In‑Time Recovery (PITR)—is vital for preventing data loss from accidental deletions, rogue updates, or hardware failures. By combining continuous WAL archiving with the powerful pgBackRest tool, you can create a reliable, automated backup strategy that enables fast, production‑ready restores to any chosen timestamp.

Building a Multi‑Region High‑Availability Docker Swarm Cluster on Cloud VPS

Building a Multi‑Region High‑Availability Docker Swarm Cluster on Cloud VPS

In today’s hyper‑connected environment, downtime isn’t an option, so a deployment platform must survive hardware failures, network hiccups, and even whole‑region outages. By combining Docker Swarm’s lightweight orchestration with multi‑region VPS instances and secure VPN mesh networking, you can build a cost‑effective, high‑availability architecture that keeps services online and latency low across diverse data centers.