Self-hosting an IoT platform on a VPS trades a flat, predictable monthly cost and full control for the time spent setting up and maintaining it yourself. A managed platform trades a usually higher, often usage-based cost for someone else handling infrastructure, scaling and updates. Neither is universally better; the right choice depends mostly on scale, technical comfort, and how much that time is worth to you.
The core trade-off, stated plainly
Every “self-hosted vs managed” decision in software comes down to the same underlying exchange: money and convenience on one side, control and cost-predictability on the other. IoT platforms are no exception, but the specifics matter, because the stakes (data ownership, uptime, what happens if a vendor changes pricing or shuts down) are higher than for, say, choosing a note-taking app.
What “managed” actually means in this context
A managed IoT platform, whether that’s AWS IoT Core, Azure IoT Hub, ThingsBoard Cloud, or a smaller specialist platform, runs the infrastructure for you: the servers, the scaling, the patching, the uptime guarantees. You interact with it through a dashboard and APIs, never touching the underlying machines. In exchange, you pay for that convenience, usually through a combination of per-device, per-message, or tiered subscription pricing, and you accept the platform’s architecture and limitations as given rather than something you can change.
What self-hosting actually means
Self-hosting, as covered throughout this site, means running the same kind of software (an MQTT broker, a rule engine, a dashboard, or a full platform like ThingsBoard’s Community Edition) on a VPS you control. You pay a flat fee for the server regardless of usage, and you’re responsible for setup, security and maintenance, all covered in this site’s other guides, in exchange for full control over the software, the data, and the cost.
A decision framework
| Factor | Favours self-hosted | Favours managed |
|---|---|---|
| Device count and message volume | Small to medium (hundreds to low thousands) | Very large scale, rapid unpredictable growth |
| Technical comfort | Comfortable with Linux, willing to learn | No spare capacity for any infrastructure work |
| Cost predictability | Want a flat bill regardless of usage | Comfortable with usage-based billing |
| Data control | Data sovereignty or privacy is a real requirement | Not a significant concern for the project |
| Need for rapid feature delivery | Happy building integrations yourself | Want vendor-built integrations and features out of the box |
| Tolerance for vendor risk | Want to avoid dependency on a single vendor’s pricing or survival | Comfortable depending on a large, established vendor |
Cost at different scales
This mirrors the pattern covered in VPS vs AWS IoT Core: Cost Comparison for SMBs: managed platforms often look genuinely competitive, sometimes even free, at small scale, then scale their cost with usage in ways that compound as a project grows. A self-hosted VPS’s cost stays roughly flat across a wide range of device counts, since the underlying server’s capacity, not the billing model, is what eventually needs upgrading. The crossover point where this matters most is exactly the small-to-medium scale most projects on this site operate at.
Vendor lock-in: a real, underappreciated cost
Beyond raw pricing, it’s worth weighing a cost that’s harder to put a number on: how hard would it be to leave? Standard, open protocols (MQTT, Modbus) and open-source software (Mosquitto, Node-RED, ThingsBoard CE) keep this cost low, since the same data and the same protocol work regardless of which provider’s infrastructure they’re running on. Proprietary managed platforms with custom APIs and data formats make leaving meaningfully harder and more expensive, a cost that’s easy to ignore when first choosing a platform and very visible the day you actually want to leave.
A middle ground worth knowing about
The choice isn’t strictly binary. ThingsBoard’s Community Edition, self-hosted on your own VPS, gives much of a managed platform’s convenience (device management, dashboards, a rule engine, multi-tenancy) without the per-device or per-message billing of a true managed service, at the cost of you handling the server itself. For many projects on this site, this middle ground genuinely captures the best of both: platform-level convenience, self-hosted economics.
A realistic migration path
It’s common, and entirely reasonable, to start on a managed platform’s free tier to validate an idea quickly, then migrate to self-hosting once device count and message volume make the cost case clear, or to start self-hosted and later adopt managed infrastructure if a project’s scale or team genuinely outgrows what makes sense to run yourself. Standard protocols make this migration considerably less painful than it would be with a fully proprietary platform on either end, which is itself a strong argument for choosing MQTT-based, open-standard components from the start regardless of which side of this decision you land on initially.
Frequently asked questions
Is self-hosting actually more work than people expect?
Initial setup takes real but modest effort, covered across this site’s guides, typically a few afternoons for a working stack. Ongoing maintenance, with the security hardening and automated updates covered elsewhere on this site, is usually less ongoing effort than people assume once the initial setup is done.
Can a small team realistically self-host without dedicated infrastructure staff?
Yes, this is the assumption throughout this site: most guides here are written for a single developer or small team without a dedicated DevOps function, using standard, well-documented open-source tools rather than anything requiring specialist infrastructure expertise.
What happens if a managed platform vendor shuts down or changes pricing dramatically?
This is a real, documented risk in the IoT platform space specifically, several notable platforms have shut down or pivoted business models, leaving customers with limited migration time. It’s a genuine factor worth weighing, particularly for anything business-critical, alongside the convenience a managed platform offers.
Does self-hosting mean I lose access to vendor support entirely?
For the open-source tools covered on this site, community support (forums, documentation, GitHub issues) replaces vendor support, which is usually adequate for the well-established, widely used tools featured here, though it’s a genuinely different support model than a paid vendor relationship with guaranteed response times.
Is there a hybrid approach where some devices use a managed platform and others are self-hosted?
Yes, and it’s not unusual for organisations with mixed requirements, critical or high-volume devices on managed infrastructure with strong SLAs, lower-stakes or cost-sensitive devices self-hosted. This adds operational complexity, worth doing deliberately rather than as an accident of how a project grew.
Two realistic scenarios worked through
Scenario one: a small business monitoring 30 retail locations’ refrigeration units. Device count is modest and stable, growth is slow and predictable, and the business has one IT-comfortable staff member but no dedicated infrastructure team. Self-hosting on a single VPS, following this site’s MQTT, Node-RED and Grafana guides, fits well here: low ongoing cost, manageable complexity for one capable person, and no risk of usage-based billing surprises as the business adds a handful of new locations over time.
Scenario two: a startup building a consumer IoT product expecting to scale from zero to fifty thousand devices within a year if the product succeeds. Here, the unpredictable, potentially rapid growth curve and the need to avoid manual capacity planning during a critical growth phase tilts the decision toward a managed platform, even at higher unit cost, since the operational risk of a self-hosted VPS being caught undersized during a sudden growth spike outweighs the cost savings at this specific stage. This same startup might reasonably revisit the decision once growth stabilises and the cost curve becomes predictable.
Neither scenario is more “correct” than the other in the abstract, the right choice depends on the specific shape of growth, team capability and risk tolerance involved, not a universal rule favouring one approach.
Total cost of ownership, not just sticker price
A fair comparison weighs more than the monthly bill on each side. For self-hosting: the VPS cost, plus the time spent on initial setup and ongoing maintenance, plus the risk cost of something going wrong without a vendor’s support team to call. For managed platforms: the usage-based bill, plus any integration or migration effort if a platform’s specific architecture doesn’t fit your needs cleanly, plus the less tangible but real cost of vendor dependency discussed above. Reducing this entirely to “which platform’s pricing page shows a smaller number” misses real costs on both sides.
How do I estimate which option is actually cheaper for my specific project?
Work through the worked-example approach in VPS vs AWS IoT Core: Cost Comparison for SMBs using your actual device count and message frequency, since the right answer genuinely depends on those specifics rather than a universal rule.
Does company size matter in this decision, separately from device count?
Somewhat, a larger organisation often has more spare capacity to absorb infrastructure maintenance work even at modest device counts, while a very small team might prefer a managed platform’s convenience even at a scale where self-hosting would otherwise make financial sense, simply because nobody has bandwidth for the setup.
Is it harder to hire for a self-hosted stack than a well-known managed platform?
Generally not significantly, since the tools covered on this site (Linux, MQTT, Docker, standard open-source software) are common, widely documented skills, arguably more broadly transferable than deep expertise in one specific vendor’s proprietary platform.
Planning an exit strategy regardless of which you choose
Whichever side of this decision a project lands on, it’s worth deliberately keeping an exit path open rather than assuming the initial choice is permanent. For managed platforms, this means favouring ones built on open standards (MQTT-based device connectivity, for example) over fully proprietary protocols, so devices aren’t hostage to one vendor’s specific API. For self-hosted setups, it means the documentation habit covered elsewhere on this site, keeping clear notes on configuration so a migration, should one ever be needed, doesn’t require reverse-engineering your own past decisions from scratch.
Can I trial both approaches in parallel before committing?
Yes, and it’s a reasonable way to make this decision concretely rather than abstractly: stand up a small self-hosted stack alongside a managed platform’s free tier, run a real subset of devices on each for a few weeks, and compare the actual experience and projected cost at your real scale before committing fully to either.
Does this decision need to be made once and locked in permanently?
No, and treating it as permanent is itself a risk worth avoiding. Revisiting the decision periodically, particularly after a significant change in device count, team capability, or available time, keeps the choice matched to current reality rather than a decision made under very different circumstances.
What’s the single most common mistake teams make in this decision?
Choosing based on what’s fashionable or what a similar-looking company uses, rather than working through the actual decision framework above against their own specific device count, team capability and cost tolerance. The right answer genuinely differs between projects that look superficially similar.
A final, practical way to decide
If the decision framework above still leaves things genuinely close, a useful tiebreaker: imagine explaining to a colleague six months from now why the project is struggling, would it more likely be “the monthly bill grew faster than expected and nobody noticed” or “nobody had time to keep the server patched and something broke”? Whichever failure mode feels more plausible for your specific team and project says more about the right choice than any abstract comparison table can. Sit with that question honestly rather than answering it the way you’d like to be the kind of team that answers it.
Does open-source software always mean self-hosted, or can it be offered as a managed product too?
It can be both; ThingsBoard itself is a good example, the same open-source Community Edition covered throughout this site can also be consumed as ThingsBoard Cloud, a managed product. The licence and the hosting model are genuinely separate decisions, worth not conflating when comparing options.
A worked example bringing the whole decision together
Consider a small business installer monitoring 40 customer sites’ equipment, growing by roughly five to ten new sites a year. At this scale and growth rate, self-hosting on a single, modestly specified VPS following this site’s other guides keeps cost flat and predictable as the business grows, with the technical effort, MQTT, Node-RED or ThingsBoard CE, well within reach of one capable person managing the business’s technical side alongside their other responsibilities. Compare this against a managed platform charging per device or per site: at 40 sites the monthly bill is already a real, ongoing business expense, and it only grows as more customers are added, eating directly into the margin on each new installation rather than staying fixed. This is precisely the kind of business where the framework in this guide tips clearly toward self-hosting, not because managed platforms are inferior in the abstract, but because this specific business’s growth shape and team size make the trade-off land that way.
Change a few details, say the same installer instead wins a single large enterprise contract requiring guaranteed uptime SLAs and rapid scaling to thousands of devices within months, and the same framework points the other way, toward a managed platform’s elastic infrastructure and contractual support guarantees being worth their higher cost for that specific engagement. The framework doesn’t change; the inputs do, and that’s exactly why a generic universal answer was never going to serve every reader of this guide equally well.