VPS for IoT: The Complete Guide

The problem this solves

Most IoT projects start the same way: a device, a vendor app, and a cloud account you didn’t really choose, you just accepted the default. That works fine for one device. It stops working once you have a doorbell from one vendor, a thermostat from another, a couple of sensors from a third, and you want them to actually talk to each other, or you want to see them all on one dashboard, or you want access that doesn’t disappear the day a startup gets acquired and shuts down its API.

The home-router alternative has its own ceiling. Port forwarding works until your ISP changes your IP, or you want HTTPS without fighting certificates on a device that’s only on when your laptop is, or you realise you’ve opened a port to a database with no real authentication on it (a genuinely common, genuinely bad outcome). A VPS sidesteps both problems: it’s always on, it has a real public IP, and everything that needs a home runs on infrastructure built to be reachable.

What you’d actually run on it

This is the part most “what is a VPS” explainers skip. In practice, a single small VPS for an IoT project tends to run a combination of:

• An MQTT broker (Mosquitto) – the message bus everything else talks through. See Self-Hosted MQTT Broker on a VPS.
• Automation logic (Node-RED or Home Assistant) – the rules that turn raw sensor data into actions. See Node-RED on a VPS.
• A dashboard (Grafana + InfluxDB, or a full platform like ThingsBoard) – somewhere to actually see what’s happening. See Grafana + InfluxDB on a VPS or ThingsBoard Self-Hosted.
• A VPN endpoint (WireGuard) – so you can reach all of the above securely without opening ports to the open internet.

You don’t need all four from day one. Most people start with one piece (often the doorbell-replacement or the MQTT broker) and add the rest as the project grows, which is exactly why a VPS suits this better than a managed platform: you’re not paying for capability you’re not using yet.

Sizing: what you actually need

This is the single most over-specified decision in IoT hosting. Unless you’re running heavy AI video detection, you need far less than people assume.

Use case	vCPU	RAM	Storage	Notes
MQTT broker only, handful of devices	1	1 GB	20 GB	Mosquitto is extremely light on resources
MQTT + Node-RED + small dashboard	1-2	2 GB	30-40 GB	Covers most home/small business setups
Full stack: MQTT + Grafana/InfluxDB + VPN	2	4 GB	50-80 GB	Comfortable headroom for growth
Self-hosted ThingsBoard (single instance)	2-4	4-8 GB	80 GB+	ThingsBoard’s own docs recommend 4GB minimum, 8GB for production
Industrial: SCADA VPN concentrator + data aggregation	2-4	4-8 GB	100 GB+	Sized for reliability headroom, not just average load

Storage matters more than it looks like it should, mainly for time-series data and camera footage if you’re doing anything video-related. NVMe storage, which most modern VPS providers default to now, makes database-heavy workloads (InfluxDB, ThingsBoard’s PostgreSQL backend) noticeably faster than older spinning-disk or even SATA SSD options.

Choosing a provider

The criteria that actually matter, in rough order of importance for an IoT workload:

• KVM virtualisation, not OpenVZ/containers. KVM gives you a real isolated kernel, which matters once you’re running Docker or need specific kernel modules (WireGuard support is one example).
• Predictable, unmetered or generous bandwidth. Telemetry traffic is usually small per-message but constant, so check the bandwidth allowance rather than just the headline price.
• A datacentre location close to your devices. Latency matters less for most IoT telemetry than people assume, but it matters a lot for anything interactive (live dashboards, remote desktop into a PLC).
• NVMe storage for the database-heavy workloads above.
• Straightforward billing, ideally with a monthly option even if you plan to commit annually, so you’re not locked in before you’ve tested anything.

LumaDock is the provider used throughout the examples on this site: KVM-based, NVMe storage, AMD EPYC hardware, with plans starting under £4 a month. It’s not the only option, but everything in this guide and the pages it links to has been tested against it specifically, so the screenshots and commands match what you’ll actually see.

Getting the first server live

The actual process, regardless of provider, looks roughly like this:

1. Choose Ubuntu 22.04 or 24.04 LTS as the operating system – it’s what almost every IoT self-hosting guide (including the ones on this site) assumes, and has the longest support window.
2. Set up SSH key authentication and disable password login before doing anything else. See VPS Security Hardening Checklist for the full process.
3. Enable a firewall (ufw is the simplest option on Ubuntu) and only open the ports you actually need.
4. Install the specific software for your use case – MQTT broker, Node-RED, ThingsBoard, whatever you’re starting with – following the dedicated guide for that piece.
5. Set up WireGuard if you need to reach any of this remotely without exposing it to the open internet.

Where this is heading

Two trends are changing what a “small” VPS for IoT can do. First, AI inference is getting cheap enough to run locally rather than calling a cloud API for every frame of camera footage, which is shifting some workloads (like Frigate’s object detection) from “needs a GPU” to “runs acceptably on a decent CPU”, with GPU still the better answer for heavier detection loads. Second, edge-to-cloud platforms like ThingsBoard are increasingly designed to sync with lightweight “Edge” instances running closer to the devices, with the VPS acting as the aggregation and management layer rather than doing all the processing itself. Neither of these changes the core advice in this guide, but they’re worth knowing about if you’re planning a setup that needs to scale.

Common mistakes when planning an IoT VPS project

A few patterns show up repeatedly enough to be worth naming directly, since avoiding them costs nothing and saves real frustration later.

Oversizing from day one. It’s tempting to buy the biggest plan available “to be safe”, but a VPS upgrade is usually a five-minute operation with most providers, including LumaDock, while overpaying for unused capacity for months is a quiet, ongoing cost. Start at the size that matches what you’re actually running today, per the table above, and upgrade when you have a real reason to.

Undersizing the database-heavy pieces specifically. The opposite mistake is just as common: sizing the whole server based on MQTT’s tiny footprint, then being surprised when InfluxDB or ThingsBoard’s PostgreSQL backend struggles. MQTT brokers are genuinely light. Time-series databases and dashboard platforms are not, and they’re usually the actual reason a “my VPS feels slow” complaint shows up.

Treating security as a later step. “I’ll secure it properly once it’s working” is how servers end up compromised during the gap between “working” and “secured properly”. The hardening checklist linked above takes perhaps twenty minutes and should happen before any service is reachable from outside the server, not after.

No backup or snapshot plan. Months of sensor history, carefully tuned Node-RED flows, or a working ThingsBoard rule chain configuration represent real effort. A snapshot before any risky change (an OS upgrade, a major version bump) is cheap insurance against losing that effort to a single bad update.

Assuming the cheapest provider plan and the cheapest reputable provider plan are the same thing. They frequently aren’t. The criteria in How to Choose a VPS for an IoT Project (CPU allocation model specifically) matter more than the headline price for anything beyond MQTT alone.

Signs you’ve outgrown your current VPS

Worth knowing what to actually watch for, rather than upgrading reactively or not at all:

• Dashboard pages taking noticeably longer to load than they did when first set up, especially with multiple browser tabs open simultaneously, usually points to database or rendering load outgrowing available RAM.
• SSH itself feeling sluggish to connect or respond is often the clearest sign of genuine resource exhaustion, since SSH is normally near-instant even under moderate load.
• htop or top consistently showing high memory usage with active swap (check with free -h) is a reliable, objective signal rather than a subjective “feels slow” impression.
• MQTT message delivery becoming delayed under normal device load, which is unusual given how lightweight Mosquitto is, and usually indicates the CPU is genuinely saturated by something else running alongside it.

Any of these are reasonable triggers to either upgrade the VPS plan or, per the multi-site guidance referenced above, split services across more than one server.

A realistic first-month timeline

For anyone wondering how long this actually takes: provisioning a VPS and completing the security hardening checklist is typically an afternoon’s work for someone reasonably comfortable with a terminal, even if it’s their first time. Getting an MQTT broker and Node-RED running and talking to a handful of real devices is usually another afternoon. A working dashboard, whether hand-built with Grafana or via ThingsBoard, tends to be where people spend the most iterative time, often a week or two of refinement rather than a single sitting, simply because dashboards benefit from living with the data for a while before the layout feels right.

Frequently asked questions

Can I run all of this on the cheapest VPS plan available?

For MQTT alone, often yes. Once you add Node-RED, a dashboard, and a VPN, you’ll generally want at least 2GB of RAM to avoid the system swapping under load. Check the sizing table above for your specific combination.

Do I need a static IP?

A VPS already gives you one by default, which is one of its main advantages over a home connection. You don’t need to do anything extra to get this.

What if I outgrow a single VPS?

Most projects don’t, but if you do, the usual next step is splitting services across two VPS instances (for example, broker and dashboard separately) rather than jumping straight to a managed cluster. See Multi-Site Industrial IoT Data Aggregation for what that looks like at larger scale.

Is self-hosting actually cheaper than a managed platform?

Usually, once you’re past a handful of devices, yes, sometimes substantially. See Self-Hosted vs Managed IoT Platforms for the actual numbers and where the break-even point tends to sit.

Do I need separate VPS instances for testing and production?

For a personal or small business project, most people develop and run production on the same VPS without issue, since the cost of a second small instance for testing rarely justifies itself until a setup is genuinely business-critical or supports multiple customers.

How much ongoing maintenance does this actually take once it’s running?

With unattended security updates enabled (covered in the hardening checklist), ongoing effort is usually minimal: an occasional manual update check, watching disk usage on anything logging a lot of data, and the normal process of adding new devices or flows as a project grows. It’s not a “set up once, never touch again” system, but it’s far closer to that than people expect.

Should I document my setup somewhere as I build it?

Worth doing, even briefly. A short notes file covering which services run where, which ports are open and why, and any non-obvious configuration choices saves real time if you ever need to rebuild the server or hand the project to someone else.

Is there a meaningful difference between IoT-specific hosting and general-purpose VPS hosting?

Not really, at the level most projects on this site operate. “IoT hosting” as a marketing term sometimes just describes a general VPS with IoT-themed documentation; the underlying server is the same KVM virtual machine you’d use for any other purpose. What matters is the criteria in this guide, not whether a provider specifically labels a plan “for IoT”.

Can I start this project on a free-tier cloud server and upgrade later?

Some cloud providers offer free tiers, often with meaningful restrictions (limited hours, specific regions, smaller specs than even the cheapest paid VPS plans). It’s a reasonable way to experiment with the very basics before committing to a paid plan, though most people find a few pounds a month for a proper small VPS removes enough friction and limitation to be worth it once they’re past the earliest experimentation stage.