IoT, the Internet of Things, is any physical object that can sense something, connect to a network and report back, without a person manually checking it. A video doorbell is an IoT device. So is a vibration sensor bolted to a factory pump. What changes between them is scale and stakes, not the underlying idea.
You’ve probably used a dozen IoT devices today without thinking of them that way. The term gets thrown around so loosely that it’s worth grounding in actual examples, because “IoT” means something quite different depending on whether you’re talking about a smart plug or a chemical plant.
IoT in everyday life
This is where most people meet IoT without realising it. A fitness tracker reading your heart rate. A smart speaker listening for a wake word. A connected car reporting tyre pressure to an app. None of these feel like “industrial technology”, and that’s the point: the sensor-connect-report pattern is now so ordinary it’s invisible.
The common thread is low stakes and low setup. If your fitness tracker drops connection for ten minutes, nothing breaks. That tolerance for imperfection is exactly what changes as you move up the list below.
IoT in the home
Here the devices get more purposeful: doorbell cameras, smart thermostats, leak sensors, door locks, plant moisture monitors. People start caring not just that the device works, but who else can see its data, and what happens if their internet goes down for an afternoon.
This is also where the first real decision shows up: do you trust a vendor’s cloud app with your camera footage and automations, or run it yourself? That question is the whole reason a Smart Home hub exists on this site.
IoT in business
Business IoT is less visible but bigger in scope: retail footfall counters, fleet vehicles reporting location and fuel use, refrigerated delivery vans tracking temperature, asset tags on equipment that’s expensive to lose. A lot of it runs over cellular connections rather than home Wi-Fi, because the devices are out in the world, not sat on a desk.
The stakes rise here too. A footfall counter going offline for a day is an inconvenience. A cold-chain sensor going offline on a vaccine shipment is a compliance problem. See Buying Guides and IoT Verticals for what this actually looks like to set up.
IoT in industry
This is IoT at its most serious: SCADA systems, PLCs controlling physical machinery, remote monitoring on oil and gas sites, predictive maintenance sensors on turbines. Downtime here isn’t an inconvenience, it can be a safety incident or a six-figure production loss. Reliability, redundancy and proper remote access aren’t nice-to-haves, they’re the entire job.
Industrial IoT on this site covers exactly this end of the spectrum: SCADA VPN concentrators, Modbus gateways, multi-site data aggregation.
How big is this, really?
Estimates vary a lot depending on what gets counted as a “device” and who’s doing the counting, which is worth knowing before you trust any single headline number. IoT Analytics, a research firm that specifically tracks this market, put the installed base at roughly 21 billion connected devices by the end of 2025, forecasting growth to around 39 billion by 2030. Other research firms land on different numbers using different definitions, sometimes by several billion either way. The exact figure matters less than the direction: this isn’t a niche technology category any more, it’s quietly running underneath retail, healthcare, logistics, agriculture and home life all at once.
What actually ties all of this together
Every example above, from a doorbell to a factory sensor, eventually needs somewhere to send its data: something always-on, reachable from anywhere, that can store readings, run automations, and serve a dashboard. For a handful of devices on your home Wi-Fi, your router can sort of fake this. For anything that needs to work reliably, be reachable when you’re not home, or scale past a handful of devices, that “somewhere” is usually a small server running constantly in a data centre.
That’s what a VPS is, and why it shows up throughout this site. If that term is new to you, What Is a VPS? is the natural next read. If you already know roughly what a VPS is and want to know which one fits an IoT project specifically, VPS for IoT: The Complete Guide is the deeper version of this page.
Frequently asked questions
Is my phone an IoT device?
Not usually, by most formal definitions. Most IoT statistics deliberately exclude phones, tablets and laptops, because those are general-purpose computers a person actively operates. IoT typically refers to purpose-built devices: sensors, cameras, trackers, controllers, things with one job.
What’s the difference between IoT and M2M (machine-to-machine)?
M2M came first and usually means two machines talking directly over a fixed link, often industrial. IoT is the broader, internet-connected evolution of the same idea, where devices report to a platform or dashboard rather than just to each other.
Do I need to be technical to use IoT devices?
No. Buying a smart plug and using its app requires no technical skill at all. Self-hosting your own dashboard and automations instead of relying on a vendor’s app, which is what most of this site covers, does involve some comfort with the command line, though less than people assume.
Why do businesses care about IoT more than consumers realise?
Because the economics are different. A consumer buys one smart device. A business might deploy thousands of sensors across sites, where even small efficiency gains (catching a fault early, reducing a delivery route, avoiding spoiled stock) multiply into real money.
What typically goes wrong with early IoT projects
The most common failure pattern: someone buys a device, picks the fastest app that works with it, and builds increasing amounts of business logic on top of a vendor’s free cloud tier. A year or two later, that vendor changes pricing, gets acquired, or simply discontinues the product, and the “IoT system” built on top of it becomes a collection of hardware with nowhere to send its data. This is the vendor lock-in problem the self-hosted approach on this site is built specifically to avoid, and it’s worth understanding it as a structural risk from the very start rather than a surprise to deal with later.
The second common failure pattern: using devices or protocols designed for one use case, home automation, in a context that needs something different, industrial reliability or regulatory compliance. The device might technically work, but the gap between what it was designed for and what it’s being asked to do creates fragility that only becomes obvious when it matters most.
The vocabulary worth knowing before going further
MQTT: the lightweight messaging protocol that most IoT devices use to report data, designed specifically for unreliable networks and constrained hardware. Think of it as a postal service for small packets of data, with a broker (usually Mosquitto) in the middle receiving and routing messages.
Broker: the central hub that receives messages from devices and distributes them to anything else that’s subscribed to listen, the piece that runs on your VPS and sits at the centre of most of this site’s architecture diagrams.
Gateway: a device at a site that speaks the local protocol, Modbus from a PLC, Zigbee from a sensor, LoRa from a field device, and translates into something an internet-connected system can understand. Often the piece that bridges the gap between an “old” industrial protocol and modern cloud infrastructure.
Edge vs cloud: “edge” means processing happens at or near the device itself, on-site, before data leaves for a central server. “Cloud” means the raw data travels to a central system and processing happens there. Most real deployments use both, with the ratio depending on latency requirements, bandwidth costs and what happens if connectivity is lost.
Where to go from here
If you’re new to self-hosting and VPS infrastructure entirely, What Is a VPS? is the next natural step before anything more specific. If you already know roughly what a VPS is and want to understand the full picture of what this site covers, VPS for IoT: The Complete Guide is the comprehensive version. If you have a specific use case already in mind, the category navigation covers the right starting point: Smart Home, Industrial IoT, Self-Hosting Guides, or IoT Verticals.
Security: the consideration that most introductions skip
Most “what is IoT” explainers don’t mention security until much later, but it’s worth flagging here because the decisions made at device selection and project design time are much harder to correct retrospectively. IoT devices have a poor security reputation for specific, structural reasons: they’re often manufactured with cost and simplicity as primary constraints, shipped with default credentials that never get changed, connected to networks without isolation from more sensitive systems, and left running for years without firmware updates. These aren’t abstract risks: Mirai, the botnet that disrupted large portions of the internet in 2016, was composed almost entirely of compromised consumer IoT devices including cameras and routers with unchanged default passwords.
The self-hosted approach this site advocates doesn’t automatically solve this, but it puts the decisions in the right hands. A Mosquitto broker running on your own VPS with per-device credentials and TLS, covered in the MQTT Security guide, is more controllable than a manufacturer’s cloud service with opaque security practices. WireGuard tunnels, covered throughout this site’s networking guides, mean devices don’t need to be publicly reachable at all. The security posture of a self-hosted IoT deployment is exactly as good as the choices made in building it, which is both a responsibility and a genuine advantage over depending on a manufacturer’s security decisions.
The data question behind every IoT deployment
Every sensor reading, every camera frame, every location ping is data, and every IoT deployment therefore has a data question underneath it: where does this data live, who can access it, how long is it kept, and what happens to it if the company providing the platform changes? For consumer devices used entirely within a private home for personal purposes, these questions are largely theoretical. For any deployment with a commercial dimension, a landlord monitoring a property, an employer monitoring equipment, a business collecting customer data, they become active legal obligations under UK GDPR, covered in detail in UK GDPR and IoT Data: What Self-Hosters Need to Know.
Self-hosting gives more direct control over these questions than using a managed platform does. When data lives on infrastructure you control, you decide the retention policy, the access controls, and what happens when you no longer need it. When it lives on a third-party platform, those decisions are made for you, often optimised for the platform provider’s interests rather than yours. This is one of the less-discussed but genuinely important arguments for the self-hosted approach, alongside the cost and flexibility arguments this site covers more frequently.
What this site covers, and what it doesn’t
This site is specifically about the server-side infrastructure connecting IoT devices to dashboards, automation and remote access: the VPS, the MQTT broker, the dashboards, the VPN tunnels. It covers the software stack you’d run on a small cloud server to tie devices together, not the devices themselves, the specific applications of that data, or the business case for any given IoT project. It also doesn’t cover the full range of industrial SCADA and automation platforms, focusing on the open-source, self-hosted tools accessible to developers, integrators and technically capable businesses rather than enterprise platform licensing.