How to Choose a VPS for an IoT Project

VPS pricing pages are designed to be compared on the wrong axis: RAM and storage, in big bold numbers, because those are easy to compare at a glance. For an IoT workload, the decisions that actually affect whether your setup is reliable in six months are mostly buried in the small print, or not mentioned at all. This page is the checklist that page is missing.

The problem with comparing on RAM and storage alone

Two VPS plans can both say “2 vCPU, 2GB RAM, 40GB SSD” and behave completely differently under real load. One might give you 2 genuinely dedicated CPU cores. The other might give you “burstable” access to a shared pool that’s also serving fifty other customers on the same physical host, throttled the moment you sustain real usage. MQTT and Node-RED are light enough that this rarely bites at small scale, but the moment you add a dashboard rendering live charts, or run a database doing constant writes, the difference becomes obvious as intermittent slowness that’s hard to diagnose if you don’t know to look for it.

Virtualisation type: KVM, and why it matters specifically for IoT

KVM (Kernel-based Virtual Machine) gives you a full, isolated virtual machine with your own kernel. The older alternative, OpenVZ-style container virtualisation, shares a kernel across all customers on the host, which is fine for a basic website but causes real problems for IoT workloads specifically: WireGuard, the VPN software most of this site’s industrial and remote-access content relies on, needs kernel-level support that container-based virtualisation often can’t provide cleanly. Most reputable providers have moved to KVM as standard now, but it’s worth confirming rather than assuming, especially on budget plans.

CPU: dedicated vs shared/burstable

This is the single most commonly glossed-over spec. “2 vCPU” on a dedicated-core plan and “2 vCPU” on a shared/burstable plan are not the same product, even at an identical price. Dedicated means those cores are yours, full stop. Shared/burstable means you get priority access up to a limit, with the underlying hardware also serving other tenants, and performance that can vary depending on what your neighbours are doing. For MQTT-only workloads this rarely matters. For anything running a database or rendering dashboards under real traffic, ask explicitly which model a plan uses rather than assuming.

Bandwidth: the constant-small-traffic trap

IoT telemetry is a strange traffic pattern: low volume per message, but constant, 24/7, for the life of the project. Providers advertising “unmetered bandwidth” are usually fine for this. Providers with a hard monthly cap are also usually fine, because the actual data volume from sensor telemetry is small, but it’s worth doing the maths once rather than assuming: a device reporting every 10 seconds, 50 bytes per message, generates roughly 1.3MB a day, trivial against almost any allowance. Camera footage is a completely different calculation and the one case where bandwidth caps genuinely matter, covered in the CCTV-specific guides on this site.

Storage: NVMe vs SSD vs spinning disk

Storage type	Relative speed	Where it matters for IoT
NVMe	Fastest	Database-heavy workloads: InfluxDB, ThingsBoard’s PostgreSQL backend, anything writing time-series data constantly
SATA SSD	Mid-range	Fine for MQTT-only or light Node-RED setups with no heavy database writes
Spinning disk (HDD)	Slowest	Rare on modern VPS plans, worth avoiding for anything beyond static file storage

Most VPS providers have standardised on NVMe by default now even at entry-level pricing, which has made this less of a decision point than it was a few years ago, but it’s still worth confirming rather than assuming on unfamiliar providers.

Backups and snapshots

A VPS is not backed up by default just because it exists on professional infrastructure. Ask specifically whether the provider offers snapshot functionality (a point-in-time image you can roll back to) and whether it’s included or a paid add-on. For an IoT setup holding months of sensor history or camera footage metadata, the ability to snapshot before a risky change (an OS upgrade, a major config change) is worth more than almost any other single feature on a pricing page.

IPv6 support

Increasingly relevant rather than optional: some ISPs and mobile networks now default to IPv6-only or dual-stack connections, and devices on those networks can have trouble reaching an IPv4-only VPS directly. It’s a minor checkbox item now, but worth confirming a provider supports it, since retrofitting it later is more hassle than checking upfront.

Putting it together: a practical checklist

• KVM virtualisation, confirmed, not assumed
• Dedicated (not just burstable) CPU, if running anything beyond MQTT alone
• NVMe storage
• Bandwidth allowance that comfortably covers your actual use case (telemetry: trivial; camera footage: check carefully)
• Snapshot/backup functionality available
• IPv6 support
• A monthly billing option, even if you plan to commit annually, so you can test before locking in

LumaDock meets all of the above on its standard VPS line, which is why it’s the provider used throughout this site’s own examples and screenshots.

A worked example: testing CPU allocation before committing

Rather than relying purely on what a provider states, it’s possible to get a rough sense of CPU allocation honesty directly. After provisioning a test instance (most providers, including LumaDock, support hourly or short-term billing for exactly this kind of check), run a sustained CPU benchmark:

sudo apt install sysbench
sysbench cpu --cpu-max-prime=20000 --threads=2 run

Run this at a few different times of day, particularly during hours when the provider’s infrastructure is likely under heavier general load (weekday evenings tend to show this most clearly on budget shared-CPU plans). A dedicated-core plan should show consistent results regardless of time of day. A heavily oversold shared/burstable plan often shows visible variance, which is the practical, observable difference between the two models discussed above, rather than just taking a sales page’s word for it.

Migrating between providers later

It’s worth planning for this possibility from the start, even if you don’t expect to need it. The practical approach that works regardless of which two providers are involved: stand up the new VPS alongside the old one, replicate the configuration (the security hardening checklist, then each service’s own setup), point devices at the new server’s IP or update DNS if you’re using a domain name, run both in parallel briefly to confirm everything works, then decommission the old instance. Keeping configuration notes as suggested earlier in this guide makes this process considerably faster when it does happen.

A note on support quality

Support response quality rarely shows up on a comparison table, but it matters more than people expect for a self-hosted IoT project specifically, since the kind of question that comes up (“why is my outbound WireGuard traffic being throttled”, for example) requires genuine technical support, not a generic helpdesk script. A reasonable way to gauge this before committing: submit a real, specific technical question through a provider’s pre-sales support channel and judge the response, not just the response time but whether the answer demonstrates actual technical understanding.

Frequently asked questions

Do I need to ask the provider directly about CPU allocation, or is it usually published?

It varies. Some providers state it clearly on the pricing page, others bury it in technical documentation or only confirm it if asked via support. If it’s not stated clearly, that’s itself a useful signal, and worth asking directly before committing.

Is more RAM always better for IoT workloads?

Not proportionally. See the sizing table in VPS for IoT: The Complete Guide for realistic figures by use case. Overpaying for RAM you’ll never use is one of the most common mistakes in this space.

Should I worry about the physical datacentre location?

For most IoT telemetry, not much. Latency differences of even 50-100ms are imperceptible for sensor data arriving every few seconds. It matters more for live, interactive use (remote desktop access to a PLC, live video streaming), where a closer datacentre genuinely helps.

What’s the actual difference between this guide and “VPS for IoT: The Complete Guide”?

That page covers the whole picture: what to run, how to size it, getting started. This page is the deeper dive specifically on the provider-selection decision itself, for when you’ve already decided a VPS is the right approach and need to pick one.

Is it worth paying more for a provider with a longer track record?

Often yes, though “longer track record” matters less than “demonstrable financial stability and clear ownership”, since a provider going out of business with little warning is a genuinely disruptive event regardless of how long they’d previously been operating. Checking who owns and operates a provider, not just how long their website has existed, is a more useful signal.

Red flags worth watching for

A handful of warning signs are worth more weight than a long checklist of nice-to-haves:

• Pricing pages that never mention virtualisation type at all. Reputable KVM providers tend to state this proudly, since it’s a genuine selling point over older container-based hosting. Its complete absence is itself a signal worth following up on.
• No published acceptable use policy, or one that’s vague about resource limits. A clear, specific policy (even one with real restrictions) is more trustworthy than one that’s deliberately vague, since vagueness usually means enforcement happens unpredictably rather than not at all.
• Support that’s only reachable via a ticket system with no stated response time. Worth testing directly with a real pre-sales question, as covered above, rather than assuming based on the website’s polish alone.
• Pricing that’s dramatically below comparable competitors with no clear explanation. Sometimes genuinely a good deal from a newer provider trying to build market share. Sometimes a sign of oversold, heavily shared infrastructure. Worth investigating rather than assuming either way.

How this decision differs for a business vs a personal project

Most of this guide applies identically either way, but a couple of considerations shift in weight for business use specifically: support response time and SLA terms matter more when downtime affects customers or operations, not just your own evening project, and data residency (which country a datacentre is physically located in) can be a genuine compliance requirement for some businesses, where it’s a personal preference at most for a hobbyist setup. Worth checking these explicitly if the VPS will be supporting anything customer-facing.

Can I negotiate pricing directly with a VPS provider?

For the small-scale plans most projects on this site use, rarely, pricing is usually fixed and published. This becomes more realistic at genuinely large scale (many servers, sustained high usage), which is well beyond what almost everything covered on this site needs.

How do I know if a provider’s “unmetered bandwidth” claim is genuine?

Check the acceptable use policy specifically, not just the marketing page, since “unmetered” sometimes comes with an unwritten fair-use ceiling enforced only when triggered. For typical IoT telemetry volumes, this rarely becomes relevant in practice, but it’s worth a quick read before committing if bandwidth is a genuine concern for your specific use case.

Should I read third-party VPS reviews before deciding?

They can be useful for general reputation, but treat them with some scepticism, since the hosting review space has a known problem with affiliate-incentivised “best of” lists that don’t reflect genuine hands-on testing. A provider’s own published technical documentation and a direct test, as covered above, tend to be more reliable than review-site rankings alone.

Does the operating system choice affect which VPS provider I should pick?

Most reputable providers offer the same core set of Linux distributions (Ubuntu, Debian, others) as standard templates, so this rarely narrows the field much. Worth a quick check that Ubuntu 22.04 or 24.04 LTS specifically is available, since that’s the assumption throughout this site’s other guides.

Is it worth choosing a provider purely because a guide like this one uses them as an example?

It’s a reasonable starting point precisely because the screenshots, commands and pricing referenced throughout this site are tested against that specific provider, removing one layer of “does this actually match what I’m seeing” friction for a first-time setup. It shouldn’t be the only factor, the criteria in this guide still apply regardless of which provider you ultimately choose.