VPS for Node-RED: Run Your Automation Engine in the Cloud

What Node-RED does in an IoT stack

Node-RED is a flow-based programming tool built on Node.js. In an IoT context it typically sits between the data sources (MQTT topics, REST APIs, databases) and the outputs (dashboards, alerts, databases, external services).

Common uses on a VPS:

• Subscribe to MQTT topics and route messages to InfluxDB for time-series storage
• Apply logic to sensor data: “if temperature drops below 2C, send an SMS alert”
• Call external REST APIs based on device events
• Receive webhooks from cloud services and trigger actions on local devices
• Aggregate data from multiple sites into a normalised format
• Bridge protocols: MQTT to HTTP, Modbus poll results to MQTT

Why run Node-RED on a VPS rather than locally

Running Node-RED locally on a laptop or Raspberry Pi means it is offline when the machine sleeps, reboots or loses power. Webhooks from external services cannot reach it if the home IP changes or the machine is unavailable.

A VPS provides continuous operation, a stable public IP for webhook endpoints, and the ability to handle incoming connections from any device on any network.

VPS sizing for Node-RED

Use case	Flow complexity	Minimum VPS
Small IoT project	10-50 simple flows	1 vCPU, 512MB RAM
Multi-site aggregation	100-500 flows, heavy MQTT	2 vCPU, 2GB RAM
Industrial automation	Complex flows, API calls	2-4 vCPU, 4GB RAM

Node-RED is single-threaded by default. CPU-intensive flows benefit more from clock speed than core count. If you expect heavy parallel processing, consider Node-RED with Queue Mode or multiple instances behind a message broker.

Installing Node-RED on a VPS

# Install Node.js (LTS)
curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo bash -
sudo apt install -y nodejs

# Install Node-RED globally
sudo npm install -g --unsafe-perm node-red

# Install as a systemd service
sudo npm install -g --unsafe-perm node-red-admin
node-red-start  # test run

# Create systemd service
sudo nano /etc/systemd/system/nodered.service

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

[Service]
Type=simple
User=pi
WorkingDirectory=/home/pi
ExecStart=/usr/bin/node-red --max-old-space-size=256
Restart=on-failure
KillSignal=SIGINT

[Install]
WantedBy=multi-user.target

sudo systemctl enable nodered --now

Securing the Node-RED editor

Edit ~/.node-red/settings.js:

adminAuth: {
    type: "credentials",
    users: [{
        username: "admin",
        password: "$2b$08",
        permissions: "*"
    }]
},
httpNodeAuth: {user:"user", pass:"password"}

Generate a bcrypt hash: node-red admin hash-pw. Then put Nginx in front of Node-RED to handle HTTPS and restrict the /red/ path to authenticated users only.

Node-RED integrations commonly used with a VPS

• node-red-contrib-mqtt – built-in MQTT nodes for subscribing and publishing
• node-red-contrib-influxdb – write directly to InfluxDB
• node-red-dashboard – lightweight dashboards (for small projects; Grafana is better at scale)
• node-red-node-email – send email alerts
• node-red-contrib-telegrambot – Telegram notifications
• node-red-contrib-modbus – poll Modbus TCP devices over a WireGuard tunnel

Node-RED flow patterns for IoT

Three flow patterns cover the majority of IoT automation use cases on a VPS:

Pattern 1 – Sensor to database: MQTT in node (subscribes to sensor topic) → Function node (parse JSON, extract value) → InfluxDB out node (write time-series data). This runs continuously, processing every sensor reading as it arrives.

Pattern 2 – Threshold alerting: MQTT in → Function node (check if value exceeds threshold) → Switch node (route on condition) → Twilio/email node (send alert). The Switch node ensures alerts only fire when conditions are actually breached, not on every message.

Pattern 3 – Scheduled polling: Inject node (timer trigger) → HTTP request node (call REST API or poll Modbus) → Function node (transform data) → InfluxDB out. Used for devices that respond to queries rather than publishing autonomously.

Node-RED with MQTT over TLS

When Mosquitto is configured with TLS (port 8883), update Node-RED’s MQTT broker configuration: enable TLS, upload the CA certificate (the Let’s Encrypt chain file), and verify the server certificate. Node-RED handles this in the broker node’s Security tab.

Node-RED vs n8n for IoT automation

Node-RED was built for IoT and hardware. It handles MQTT, Modbus, serial ports and low-level protocols natively. It runs on 256MB RAM and works well on a Raspberry Pi. n8n is better suited to SaaS automation (Slack, Salesforce, Stripe integrations) with more resource overhead. For IoT data pipelines, Node-RED is the right choice; for business process automation on top of your IoT data, n8n complements it. See the full Node-RED VPS guide for the complete setup walkthrough.

Node-RED for industrial Modbus and OPC-UA

Node-RED’s industrial protocol support makes it the natural data collection layer for legacy equipment. The node-red-contrib-modbus package polls Modbus TCP devices (PLCs, drives, meters) on a schedule and publishes results to MQTT or writes them directly to InfluxDB. The node-red-contrib-opcua package connects to OPC-UA servers on modern PLCs (Siemens S7-1200, Allen-Bradley CompactLogix, Beckhoff TwinCAT). Both protocol packages work transparently through a WireGuard tunnel, accessing devices on remote site LANs from the VPS.

This pattern turns a VPS running Node-RED into a centralised data acquisition system for multiple industrial sites, with no on-site data collection software beyond the site router with a WireGuard tunnel.

Exporting and backing up Node-RED flows

Node-RED flows are stored as a JSON file in ~/.node-red/flows.json. Export flows regularly via the Node-RED editor menu (Export > All flows > JSON) or back up the flows.json file directly. Store backups in version control (Git) alongside the VPS configuration to maintain a complete infrastructure-as-code record. When restoring or migrating to a new VPS, import the flows JSON and reinstall the required node modules listed in package.json.

Frequently asked questions

How do I access the Node-RED editor from outside the VPS?

Set up Nginx on the VPS as a reverse proxy: Nginx listens on port 443 (HTTPS with Let’s Encrypt), forwards traffic to Node-RED on port 1880. Restrict access to the editor with adminAuth in settings.js and optionally with IP allowlisting on the Nginx level.

Can Node-RED handle multiple MQTT brokers?

Yes. Each MQTT node in Node-RED can be configured with its own broker connection. You can subscribe to topics on multiple brokers simultaneously and route messages between them.

What is the Node-RED credential store?

Node-RED encrypts credentials (MQTT passwords, API keys, database passwords) stored in flows using a secret key. Keep a backup of the .node-red/flows_cred.json file and the credentialSecret value from settings.js.

Can I run multiple Node-RED instances on one VPS?

Yes. Run multiple instances on different ports, each with its own data directory. This is useful for separating development and production environments on the same server.

Does Node-RED support MQTT over TLS (port 8883)?

Yes. In the MQTT broker node configuration, enable TLS and provide the CA certificate path. This works with Mosquitto configured as described in the VPS for MQTT guide.