The Problem: What Do You Do With Your SIM Card Data?

You have ordered IoT SIM cards or M2M SIM cards. They are provisioned, they have a fixed IP or APN, and your devices – sensors, routers, remote PLCs, EV chargers, vending machines – are reporting data on a schedule. Now what?

This is the moment most deployments hit a fork in the road. The data needs to land somewhere. It needs to be stored, processed, and ideally visualised or forwarded to a business system. The two most common routes are:

• Use a managed IoT platform – something like ThingsBoard, HiveMQ Cloud, or AWS IoT Core. You point your devices at their broker endpoint, and the platform handles everything above the network layer.
• Run your own MQTT broker on a VPS – you deploy Mosquitto, EMQX, or VerneMQ on a cloud server, and your SIM-connected devices report directly to that IP. You own the stack.

Both are legitimate. But for teams with more than a handful of devices, a preference for data sovereignty, or a need to integrate with unusual backends, the self-hosted VPS route offers something managed platforms cannot: total control at a fixed cost.

Why MQTT Is the Natural Protocol for IoT SIM Card Deployments

MQTT was designed by IBM in the late 1990s for SCADA telemetry over satellite links – low bandwidth, unreliable connections, battery-constrained endpoints. It maps almost perfectly onto modern cellular IoT deployments.

Minimal overhead on metered data

A typical MQTT CONNECT packet is around 14 bytes. A PUBLISH with a JSON payload might be 80-300 bytes. Compare that to HTTP REST, where headers alone often run to 500+ bytes per request. On a metered M2M SIM with a 1 MB or 5 MB monthly allowance, this difference is meaningful – especially across hundreds of devices publishing every 30 seconds.

Persistent sessions over intermittent cellular

Cellular connections drop. Devices move in and out of coverage. MQTT’s clean session flag, QoS levels, and Last Will and Testament (LWT) feature are built for exactly this reality. A device can reconnect and pick up any messages it missed while offline, without the application layer needing to manage retry logic.

QoS levels matched to use case

• QoS 0 – fire and forget. Good for non-critical telemetry like ambient temperature readings.
• QoS 1 – at least once delivery. Suitable for alarm states where missing a message is unacceptable.
• QoS 2 – exactly once. Used where duplicate processing would cause a real problem, such as billing or command execution.

Fixed IP SIMs and direct broker access

If your IoT SIM cards come with a fixed IP address or are on a private APN, your devices can publish directly to your VPS broker IP without any NAT traversal or port-forwarding issues. This is one of the cleanest possible architectures for a cellular IoT deployment.

Managed Platform vs Self-Hosted VPS

MQTT Broker Options: Deploy in Minutes with Docker

If you have a VPS with Docker installed, any of the following brokers can be running in under ten minutes. Each serves a different point on the spectrum from simple to enterprise-grade.

For a full breakdown – Docker Compose files, TLS certificate setup, Mosquitto ACL syntax, and Node-RED wiring – see the in-depth guide at iotvps.co.uk: VPS for MQTT.

Security: The Part People Skip

Running your own MQTT broker means full control – and full responsibility. The internet is actively scanned for open MQTT ports. An unprotected broker on port 1883 with no authentication will receive connection attempts within hours of going live.

Production security checklist

• Disable anonymous access. Set allow_anonymous false in Mosquitto config. Every client must authenticate.
• Enable TLS on port 8883. Use Let’s Encrypt for a public hostname, or a self-signed CA for private APN deployments. Never run plain MQTT on port 1883 in production.
• Use per-device client certificates. Each M2M SIM or device gets its own certificate. Revoke individually without affecting the fleet.
• Implement ACLs per device. A temperature sensor should only publish to its own topic – never subscribe to others or send commands.
• Lock down UFW. Allow port 8883 inbound, port 22 from your IP only, port 443 if running a dashboard. Close everything else.
• Keep software patched. Set up unattended-upgrades on Ubuntu. Schedule regular manual updates for the broker itself.
• Configure Last Will and Testament (LWT). The broker publishes an offline status if a device disconnects unexpectedly – useful for alerting.
• Monitor failed authentication attempts. A spike often indicates a scanning bot or misconfigured device.
• Rate-limit connections. EMQX and HiveMQ support this. Protects the broker if a device enters a reconnect loop.

Remote Access to Field Equipment Over a SIM Connection

MQTT is not the only thing your VPS can do once your IoT SIM cards are on the network. A VPS with a fixed public IP creates an accessible endpoint that field devices can connect back to – enabling secure remote access to equipment that would otherwise be unreachable behind carrier-grade NAT.

Pattern 1: SSH reverse tunnel

Your remote device opens an outbound SSH connection to your VPS and creates a reverse tunnel. You can then SSH into the device from the VPS without knowing the device’s IP or punching through the cellular NAT. Works over any IoT SIM with outbound TCP access.

Pattern 2: WireGuard VPN over cellular

Your VPS runs a WireGuard server. Each field device runs a WireGuard peer. The SIM card provides outbound connectivity; WireGuard provides an encrypted tunnel and a stable virtual IP for each device. Once established, you can reach any port on the remote device – web UI, serial-over-IP, Modbus TCP. Recommended for production deployments requiring reliable access to multiple devices.

Pattern 3: MQTT as a command channel

Your devices subscribe to a control topic alongside their publish topics. From a dashboard or API call on your VPS, you publish a command message. The device receives it, acts, and publishes a confirmation. No inbound ports on the device needed – it only ever makes outbound connections to the broker. The safest pattern for remote command execution over cellular.

What VPS Spec Do You Need?

MQTT is extremely lightweight at the broker level. A four-core VPS with 4 GB RAM will comfortably handle thousands of concurrent connections. The bottleneck in most deployments is the time-series database and dashboard query load, not the broker itself.

A practical starting point for a self-hosted IoT stack with up to 500 devices publishing every minute:

• CPU: 2-4 vCPU
• RAM: 4-8 GB (InfluxDB is the memory consumer)
• Storage: 40-80 GB SSD (depends on retention period and payload size)
• Network: 1 Gbps port, unmetered or at least 1 TB/month
• Location: UK or EU data centre for UK GDPR compliance

LumaDock offers UK and EU VPS options that fit this profile at a price point that makes sense for IoT projects where the SIM contract is already the primary ongoing cost. View LumaDock VPS options.

Which IoT SIM Features Matter for MQTT?

• Fixed IP addressing. A static IP on your SIM means devices always appear at the same source address. Simplifies firewall rules, ACLs, and logging significantly.
• Private APN. Isolates your device traffic from the public internet at the network layer. Devices connect directly to your VPS through the MNO’s private network.
• Multi-network SIMs. For devices in locations with variable coverage, a multi-network or roaming IoT SIM ensures the device stays connected by switching to the strongest available network.
• LTE-M or NB-IoT. For devices transmitting small telemetry payloads over long periods, LTE-M and NB-IoT SIMs reduce power consumption. Both protocols support MQTT over TCP.
• Data pooling. Across a fleet, usage is uneven. Pool plans allow high-publishing devices to draw from the same allowance as low-volume sensors.

Frequently Asked Questions