What is an IoT stack? Ingestion, storage, dashboards, and automation explained

Strip away the vendor-specific detail and every IoT deployment that actually works, whether it is monitoring a construction site, a farm, or a warehouse, is built from the same four layers, wired together in the same order. Understanding those four layers makes it much easier to evaluate any IoT platform, including this one, because you can ask "what is this actually doing at each layer" instead of taking a feature list at face value.

Layer 1: Ingestion — getting readings off the device

Ingestion is how a reading gets from a physical sensor into the rest of the stack. Different sensors need different ingestion paths depending on their power budget and available connectivity: MQTT for devices with a network connection and readings that need to arrive instantly, LoRaWAN for battery-powered devices far from WiFi, HTTP polling for sensors that only expose a simple API, and cellular or vendor cloud APIs for everything else. A working platform needs to support more than one of these, because a real site is never running just one kind of sensor.

Layer 2: Storage — keeping the history, not just the latest reading

A live reading is not much use on its own; the value is in the history: was this vibration level normal for a Tuesday, or a spike? Storage is a time-series database, purpose-built to hold enormous volumes of timestamped readings and query them efficiently over time ranges, unlike a general-purpose database which struggles once you are writing thousands of rows a minute and querying "the last 30 days" regularly. This is also the layer that determines how long your history survives and how quickly you can query it.

Layer 3: Visualisation — turning rows into something a person can read

Rows in a database are not a dashboard. Grafana (or an equivalent) sits on top of storage, turning queries into live charts, gauges, and alerts. This is the layer most people think of as "the platform," but it is only useful because the two layers underneath it are already doing their job reliably.

Layer 4: Automation — acting on readings, not just displaying them

The last layer is where readings turn into action: an alert that pages someone, a webhook that notifies a third-party system, a flow that only fires after a threshold has been sustained for a set period rather than reacting to a single noisy spike. Node-RED typically lives here, subscribed to the same ingestion layer as storage and visualisation, but reacting to readings rather than just recording or displaying them.

A real example, end to end

A dust sensor on a demolition site publishes a PM10 reading over MQTT every ten seconds. That reading is written to storage (layer 2), rendered live on a Grafana dashboard the site supervisor keeps open (layer 3), and simultaneously picked up by a Node-RED flow (layer 4) that tracks whether readings have stayed above the site’s threshold for more than two minutes. When they do, the flow calls a webhook that notifies the water cart operator, and Grafana’s own alerting fires a parallel notification to the HSE manager’s phone. One reading, four layers, three simultaneous outcomes, none of which required custom backend code.

Why teams usually end up building this themselves, slowly

None of these four layers is exotic on its own, MQTT, a time-series database, Grafana, and Node-RED are all mature, widely-used open-source tools. The actual work is standing each one up correctly, wiring them together securely, keeping every tenant’s data isolated if you are running this for more than one team or site, and maintaining all four layers over time. That operational weight is usually what turns "we’ll just set up our own stack" into a project that takes months rather than an afternoon.

What a managed IoT stack actually removes

A managed version of this stack does not change what the four layers do, it removes the operational burden of running them: each layer provisioned automatically, pre-connected to the others, isolated per customer, billed for what is actually enabled, and pausable independently the moment you stop needing one of them. See our pricing page for how that is billed per service, or our integrations page for the full list of protocols the ingestion layer supports.

• Ingestion: getting a reading off the device, over MQTT, LoRaWAN, HTTP, cellular, or a vendor API
• Storage: a time-series database that can hold and query a high-volume reading history efficiently
• Visualisation: dashboards and alerting, typically Grafana, sitting on top of storage
• Automation: flows and integrations, typically Node-RED, that react to readings rather than just recording them
• The four layers are standard, mature, open-source tools; the hard part is running and connecting them reliably

Ready to see this running for your own sensors? Request a demo or explore what each service costs.