10 Ways to Use a £2.23/Month VPS for IoT and M2M

Why a Dedicated VPS Changes the IoT Equation

Most IoT deployments reach the same friction point: devices need a stable, publicly addressable endpoint to connect to, report through, or receive commands from. Cloud IoT platforms can fill this role, but they introduce per-message costs, vendor lock-in, data residency uncertainty, and limits on protocol flexibility. A self-managed VPS sidesteps all of that.

The Lumadock 1 GB VPS – AMD EPYC processor, 30 GB NVMe, unmetered bandwidth at 1 Gbps, and a dedicated IPv4 address – starts at £2.23 per month. It runs on full KVM virtualisation with no overselling, which matters when you need predictable latency for telemetry pipelines. The firewall management panel and built-in DDoS protection mean you are not starting from zero on the security side either.

What follows is a practical breakdown of ten deployable use cases. Each one lists the specific Linux services involved, the likely resource footprint, and the key security controls you should put in place before exposing anything to the internet.

WireGuard VPN Hub for Remote Router Access

This is the most widely applicable use case of the ten. WireGuard, now built into the Linux kernel from version 5.6 onwards, is a modern VPN protocol that is significantly faster and simpler to configure than OpenVPN. It uses public/private key pairs, has a minimal attack surface, and works well with cellular connections where the WAN IP changes regularly – which is exactly the situation with roaming SIMs and unlimited data SIMs on dynamic IP allocations.

The setup pattern is straightforward. The Lumadock VPS becomes the WireGuard server, holding a static public IPv4 address. Each Teltonika router at a remote site – a RUTX11, RUT956, or similar – runs a WireGuard peer and maintains a persistent tunnel back to the server. Once the tunnel is established, you can reach the router’s LAN-side devices (cameras, PLCs, meters) without those devices needing any public IP at all, and without opening any ports on the SIM connection itself.

This directly solves two common cellular deployment problems. First, roaming SIMs and most unlimited data SIMs assign dynamic IPs that change on reconnect – making direct inbound connections unreliable. Second, some operators place SIM connections behind carrier-grade NAT, making inbound connections impossible without a VPN relay. WireGuard on a VPS eliminates both constraints.

For teams managing more than five or six WireGuard peers, wg-easy provides a self-hosted web UI that runs in Docker and makes peer management significantly less error-prone. It runs comfortably within the 1 GB RAM allocation on this VPS spec.

MQTT Broker for Sensor Telemetry

MQTT is the dominant messaging protocol for IoT telemetry. It is lightweight, designed for unreliable networks, and supported by virtually every cellular router, IoT gateway, and sensor module on the market. Running your own Mosquitto broker on a VPS gives you full control over topics, client authentication, message retention, and routing – none of which are available on the free tiers of public broker services.

Eclipse Mosquitto installs via apt in a single command and uses around 5-10 MB of RAM at idle with moderate client counts. With a dedicated IPv4 from Lumadock and a domain pointed at the VPS, you can generate a free TLS certificate from Let’s Encrypt via certbot and configure Mosquitto to require TLS on port 8883 (the standard MQTT-over-TLS port). This encrypts all telemetry in transit from device to broker.

Authentication is handled via Mosquitto’s built-in password file and ACL configuration. Each device gets its own client ID, username, and password. ACL rules then restrict what each client can publish or subscribe to – a temperature sensor has no business subscribing to a control topic, and enforcing this at the broker level prevents a compromised device from reading data it should not.

The VPS also allows you to bridge Mosquitto to a cloud broker (AWS IoT Core, HiveMQ Cloud) if you need downstream cloud processing – the local broker acts as a concentrator and the bridge republishes selected topics upstream. This keeps cloud data transfer costs low while maintaining local broker redundancy.

Remote CCTV Access via WireGuard and RTSP Relay

Remote CCTV over cellular is a common requirement – construction sites, remote infrastructure, mobile assets, and event deployments all need video monitoring without fixed-line connectivity. The naive approach is to port-forward the camera’s RTSP or HTTP stream directly through the router to a public IP. This is a significant security risk: camera firmware is frequently unpatched, default credentials are common, and public-facing RTSP ports are routinely scanned and exploited.

The correct approach uses WireGuard to keep the cameras entirely off the public internet. The Teltonika router at the camera site establishes a WireGuard tunnel to the Lumadock VPS. The monitoring station – a control room PC, an NVR, or a mobile viewer – also connects to the same WireGuard network. RTSP streams from the cameras travel through the encrypted tunnel to the viewer, with no camera ports publicly exposed at any point.

For more complex setups where multiple viewers need access, nginx with the stream module can proxy RTSP over the tunnel, allowing multiple simultaneous viewer connections without each viewer needing a full WireGuard client. This works particularly well for temporary installations using roaming SIMs with dynamic IP addresses.

Node-RED and Grafana IoT Dashboard Stack

The Node-RED, InfluxDB, and Grafana combination – sometimes called the NIG stack – is one of the most practical self-hosted IoT data pipelines available. Node-RED handles data ingestion and flow logic: it can receive MQTT messages, HTTP POST payloads from routers and gateways, or Modbus TCP data, process and transform it, and write it into InfluxDB as time-series records. Grafana then queries InfluxDB and renders dashboards with configurable time ranges, thresholds, and alerting.

The entire stack runs on 1 GB RAM if deployed carefully. InfluxDB 1.x is significantly lighter than v2 – for a small to medium deployment it is the right choice on this VPS tier. Node-RED and Grafana together use under 200 MB of RAM at moderate load. The remaining headroom handles nginx and the OS overhead.

nginx sits in front of both Node-RED and Grafana, terminating HTTPS and enforcing authentication before requests reach either service. This is important – Node-RED in particular should never be exposed directly to the internet without authentication, as its flow editor allows arbitrary code execution. TLS certificates from Let’s Encrypt are free and auto-renew via certbot.

This stack is well-suited to energy monitoring, environmental sensing, and asset tracking use cases – anywhere you need a long-running historical view of data from remote cellular-connected devices.

Static IP Relay for Dynamic and Roaming SIMs

Many IoT SIM use cases require a fixed, known IP address so that a back-end system can accept inbound connections from field devices or allowlist traffic at a firewall. Private APN arrangements with a mobile operator solve this natively, but they carry higher cost and minimum commitment thresholds that are impractical for small deployments.

A VPS provides a practical alternative. Each device establishes a VPN tunnel (WireGuard is the lightest option) to the Lumadock VPS and is assigned a fixed IP on the tunnel’s private subnet. The back-end system, which may be in a data centre or a cloud environment, connects to the same VPS network or whitelists the VPS’s public IPv4 as the known source. The SIM’s WAN IP is irrelevant – from the back-end’s perspective, all traffic originates from a single, stable address.

This approach works with multi-network roaming SIMs and unlimited data SIMs on dynamic allocations. It is particularly useful for vending machines, payment terminals, and remote monitoring systems that feed into a central platform with IP-based authentication.

OpenVPN Server for Legacy Device Tunnels

WireGuard is the right choice for new deployments, but legacy equipment – older Teltonika firmware versions, Moxa devices, Robustel gateways with pre-2022 firmware, or client-specified PLC systems – may only support OpenVPN. Running OpenVPN on the Lumadock VPS covers this requirement without needing a second server.

OpenVPN uses a PKI (public key infrastructure) model managed via EasyRSA. Each device receives a signed certificate from the server’s certificate authority. This means per-device identity is cryptographically verifiable, and individual certificates can be revoked without rotating keys across the entire deployment. For fleet-scale IoT where devices might be lost, stolen, or decommissioned, this is an important property.

OpenVPN runs on TCP port 443 or UDP 1194 by default. Running it on TCP 443 allows it to pass through restrictive networks that block non-standard ports, though TCP-over-TCP performance is poor on lossy cellular links – UDP mode is preferable where network conditions allow. TLS authentication (–tls-auth) should always be enabled to prevent unauthorised clients from even completing the TLS handshake.

Secure Remote Modbus and SCADA Proxy

Industrial protocols – Modbus TCP, DNP3, IEC 60870-5-104, OPC UA – were designed for isolated, trusted networks. Exposing them directly on the public internet is one of the most common and serious IoT security failures. The Lumadock VPS provides a way to access remote industrial devices securely without putting the protocols themselves on the internet.

The pattern is: Teltonika industrial router (RUTX12, RUT955, or similar) at the site connects to the VPS via WireGuard. Modbus TCP polling traffic from the SCADA head-end or HMI travels through the encrypted tunnel to the router, which then communicates with the PLC or meter on the local serial or Ethernet bus. From the PLC’s perspective, the poll looks like it comes from the local network. From the internet’s perspective, there is no Modbus service running at all.

Node-RED with its Modbus nodes can also run on the VPS itself as an intermediary – polling devices over the tunnel and republishing readings via MQTT or HTTP to upstream systems. This decouples the SCADA system from direct knowledge of the field device topology, which simplifies architecture and improves resilience.

This use case is directly relevant to energy metering, utility automation, and building management systems – any sector where cellular provides the backhaul to a remote industrial site.

Site Monitoring, Uptime Alerting, and Failover Detection

Uptime Kuma is a self-hosted monitoring tool with a clean web UI that supports HTTP, TCP, ping, DNS, and MQTT monitors. It runs in Docker and uses minimal resources – well under 100 MB of RAM on a quiet instance. Deployed on the Lumadock VPS, it can monitor the connectivity status of every WireGuard peer, every MQTT broker connection, and any HTTP endpoint exposed through the VPN.

For IoT fleet monitoring, the most useful check is whether each remote site’s WireGuard peer is still reachable via its tunnel IP. A dropped ping to a tunnel IP means the router at that site has lost connectivity or rebooted – Uptime Kuma can send an email, Telegram message, or webhook to alert on this within seconds of detection.

Teltonika routers support outbound webhooks that fire on link state changes. Configured to POST to an endpoint on the VPS, these give you router-side context for connectivity events – link up/down, SIM switch events, and signal quality changes can all be logged centrally without polling.

Secure File and Data Relay via SFTP and rsync

Many IoT applications generate periodic data files rather than continuous telemetry streams. Vending machines upload transaction logs. Smart meters batch energy readings. Environmental sensors write daily CSV reports. CCTV systems push motion-triggered clips. All of these need a reliable, secure destination to upload to.

OpenSSH’s SFTP subsystem provides exactly this, and it runs on every Linux server by default. Chrooted SFTP users – where each device’s account is locked into its own directory and cannot traverse the server filesystem – allow you to give many devices individual upload paths without any risk of one device accessing another’s data. SSH key authentication eliminates the password-guessing attack surface entirely.

rsync over SSH is an alternative for structured directory synchronisation – useful when a router needs to sync a local log directory to the VPS on a schedule. Teltonika routers support rsync natively, and the synchronisation can be triggered by a cron job on the router or the server.

syslog-ng can receive centralised syslog from all routers and gateways in the fleet, writing structured logs to the VPS disk. Combined with logrotate, this provides a searchable audit trail for connectivity events, authentication attempts, and configuration changes across the entire fleet.

Lightweight Device Management and Configuration API

For deployments with a custom device firmware or configurable edge logic, a lightweight REST API on the VPS allows devices to poll for configuration updates, report health status, or trigger firmware update downloads. This is a simpler and more controllable alternative to commercial device management platforms for small to mid-scale fleets.

Python with FastAPI or Flask produces a functional REST API in under 100 lines of code. Devices authenticate using either a per-device API key or a JWT token issued at provisioning time. The API writes device state to SQLite (adequate for small fleets) or PostgreSQL for anything larger, and serves configuration payloads as JSON. nginx sits in front, terminates HTTPS, and applies rate limiting to prevent a misconfigured device from hammering the API.

This pattern works well for NB-IoT and LTE-M devices that wake periodically, check for configuration changes, upload a reading, and sleep again. The server-side API is stateless and lightweight – 20 MB of RAM under load – leaving plenty of headroom for other services running on the same instance.

Getting Started: Baseline Setup for Any of These Use Cases

Before deploying any service listed above, the following baseline configuration applies to any Ubuntu 22.04 LTS instance. These steps take approximately 20 minutes and dramatically reduce the attack surface of a publicly reachable server.

Step 1 – User and SSH hardening

Create a non-root sudo user. Disable root SSH login (PermitRootLogin no in /etc/ssh/sshd_config). Disable password authentication (PasswordAuthentication no). Copy your SSH public key to the new user’s ~/.ssh/authorized_keys. Change the SSH listen port to a non-standard value.

Step 2 – Firewall baseline

Install UFW, set default deny-incoming and allow-outgoing. Allow only your SSH port and the specific ports your services require (e.g. UDP 51820 for WireGuard, TCP 8883 for MQTT-TLS). Enable UFW. Use Lumadock’s control panel firewall as a second layer.

Step 3 – fail2ban

Install fail2ban and enable the SSH jail. This automatically blocks IP addresses that exceed a threshold of failed SSH login attempts, which is important even on a non-standard SSH port.

Step 4 – Automatic security updates

Enable unattended-upgrades for security packages. An unpatched VPS with a public IP is a liability regardless of how well the application layer is secured.

From this baseline, each use case above is a clean, bounded deployment on top of a hardened host. The Lumadock control panel provides a hardware-level firewall and DDoS protection as a further defence-in-depth layer, independent of the software configuration inside the VPS.

Related Reading