Why trust this guide
By Victus Cloud · Reviewed by Victus Cloud · No individual author claimed. Verify paths, versions, and backups before changing a live service.
Evidence-led, product-agnostic
High-frequency telemetry from microcontrollers changes the shape of your backend. A fleet of ESP32 devices emitting sensor readings several times per second generates a firehose of small messages, not a trickle of large requests. Choosing the right IoT backend hosting model matters: a dedicated virtual server running a lightweight MQTT broker is often the cheapest, most predictable way to ingest that stream before it lands in storage or a dashboard.
Why MQTT fits IoT and robotics
MQTT is a publish/subscribe protocol built for constrained devices and unreliable networks. Instead of each device opening a request/response session, devices publish to topics and subscribers receive only what they care about. Its small header, retained messages, and last-will notifications make it ideal for robotics telemetry, where a dropped connection should be detectable rather than silent.
- Publish/subscribe keeps devices decoupled from consumers
- Small wire overhead suits bandwidth-limited microcontrollers
- Quality of Service levels trade delivery guarantees for cost
- Last-Will-and-Testament detects dead devices automatically
- Retained messages give new subscribers the latest state instantly
Victus plan details are the source of truth
CPU, memory, network throughput, NVMe or storage class, and location availability vary by product and plan. Do not assume a specific message rate or connection ceiling; verify current panel and plan details before sizing your IoT backend.
Running Mosquitto on a VPS
Eclipse Mosquitto is a popular open-source MQTT broker that runs comfortably on a small virtual server. The configuration below enables anonymous-local testing and listens on the standard TLS port. For production you should require authentication and terminate TLS, but the skeleton shows how little is needed to start.
sudo apt-get update
sudo apt-get install -y mosquitto mosquitto-clients
sudo systemctl enable --now mosquitto
# Quick smoke test in two shells
subscriber: mosquitto_sub -h 127.0.0.1 -t sensors/+/temperature
publisher: mosquitto_pub -h 127.0.0.1 -t sensors/esp32/temperature -m "21.4"A minimal ESP32 publisher
On the device side, the PubSubClient library turns an ESP32 into a tiny publisher. The sketch connects to your broker, then publishes a temperature reading on a loop. Keep payloads small and batch where you can; a 32-byte JSON document is plenty for most telemetry.
#include <WiFi.h>
#include <PubSubClient.h>
const char* WIFI_SSID = "your-ssid";
const char* WIFI_PASS = "your-pass";
const char* BROKER = "10.0.0.5"; // your VPS private IP
WiFiClient net;
PubSubClient client(net);
void setup() {
WiFi.begin(WIFI_SSID, WIFI_PASS);
while (WiFi.status() != WL_CONNECTED) delay(500);
client.setServer(BROKER, 1883);
}
void loop() {
if (!client.connected()) client.connect("esp32-01");
client.loop();
float t = 21.0 + random(0, 50) / 10.0;
client.publish("sensors/esp32/temperature", String(t).c_str());
delay(1000);
}A Python consumer for processing
On the server, a Python process subscribes and forwards readings to a time-series store. The paho-mqtt library mirrors the broker's topic model cleanly, and you can run many consumers behind the same subscription for horizontal scaling.
import paho.mqtt.client as mqtt
def on_connect(c, u, f, rc):
c.subscribe("sensors/+/temperature")
def on_message(c, u, msg):
device = msg.topic.split("/")[1]
print(f"{device}: {msg.payload.decode()} C")
# TODO: write to InfluxDB / TimescaleDB here
client = mqtt.Client()
client.on_connect = on_connect
client.on_message = on_message
client.connect("127.0.0.1", 1883, 60)
client.loop_forever()Throughput, retention, and backpressure
A single Mosquitto instance can handle tens of thousands of messages per second on modest hardware, but your VPS network and CPU ceilings set the real limit. Plan for the sum of publish and subscribe traffic, not just ingress, because bridges and consumers multiply load. When the store cannot keep up, apply backpressure by dropping low-value topics rather than blocking the broker.
| QoS | Delivery guarantee | Cost |
|---|---|---|
| 0 | At most once (fire and forget) | Lowest overhead |
| 1 | At least once (may duplicate) | Moderate |
| 2 | Exactly once (handshake) | Highest, rarely needed for telemetry |
Scaling the broker horizontally
When one node is not enough, scale with a bridge to a second broker or adopt a clustered broker. Keep device authentication centralized, partition topics by site or product, and put the broker on a private network with a reverse proxy or VPN for management traffic. Containerizing Mosquitto (see the Docker article) makes rolling updates painless.
- Put the broker on a private interface, not the public internet
- Require username/password or client certificates per device
- Partition topics by fleet, then by device, for clean routing
- Add a bridge or cluster before you hit single-node limits
- Monitor message rate, socket count, and retained message size
Retained messages accumulate
Every retained message is held in memory by the broker. A fleet that retains one message per device is fine; a fleet that retains per-reading will exhaust memory. Use retention deliberately and expire stale topics.
Securing the IoT stack
Robotics fleets are attractive targets, so never expose an unauthenticated broker. Enforce TLS, issue per-device credentials, and isolate the broker from your app tier using private networking. Combine that host isolation with the OS hardening you would apply to any internet-facing server.
Summary
A dedicated VPS running Mosquitto is a pragmatic foundation for IoT backend hosting: lightweight, predictable, and easy to scale with bridges or containers. Keep payloads small, choose QoS deliberately, and confirm your plan's throughput and location limits before committing a fleet to production.