Build your IoT platform sovereignly and self-hosted? WZ-IT designs and runs vendor-neutral IoT architectures on open-source foundations - on your infrastructure. See our IoT services - IoT platform development
An IoT architecture splits cleanly into seven layers: sensor/device, connectivity, edge/gateway, platform, data storage, visualisation and integration. Each layer has a clearly defined responsibility, and for each there is a mature open-source component. Once you understand this separation, you build IoT systems that stay maintainable, can be swapped part by part and do not get stuck in a vendor cloud. This article shows which component sits where and what the full self-hosted picture looks like.
Contents
- The seven layers of an IoT architecture at a glance
- Layer 1: Sensors and devices
- Layer 2: Connectivity - LoRaWAN, MQTT and cellular
- Layer 3: Edge and gateway
- Layer 4: Platform - ThingsBoard
- Layer 5: Data storage - time-series with InfluxDB or PostgreSQL
- Layer 6: Visualisation with Grafana
- Layer 7: Integration with ERP and cloud
- The full self-hosted picture
- Build your architecture sovereignly with WZ-IT
The seven layers of an IoT architecture at a glance
Instead of thinking in terms of a single "IoT product", the layered model helps: data travels from the bottom (physical sensing) to the top (business application), and each layer only talks to the one directly above or below it. This decoupling is precisely why components can be swapped individually without rebuilding the whole system.
| Layer | Responsibility | Typical open-source component |
|---|---|---|
| 1 Sensor/device | Measure, actuate | LoRaWAN sensors (e.g. Milesight), Modbus/OPC-UA devices |
| 2 Connectivity | Transport the data | LoRaWAN, MQTT, NB-IoT/LTE-M/5G, Ethernet/Wi-Fi |
| 3 Edge/gateway | Protocol conversion, buffering | LoRaWAN gateway + ChirpStack, Node-RED, ThingsBoard Edge |
| 4 Platform | Device management, rules, tenants | ThingsBoard |
| 5 Data storage | Store time-series | InfluxDB, PostgreSQL/TimescaleDB, Cassandra |
| 6 Visualisation | Dashboards, alarms | Grafana |
| 7 Integration | Connect ERP/MES/cloud | REST, MQTT, Kafka, Node-RED |
Layer 1: Sensors and devices
At the very bottom are the physical devices: temperature, humidity, fill-level or energy meters, actuators and machine controllers. In industrial settings, existing assets often expose their values over fieldbuses such as Modbus or OPC-UA, while new radio sensors (for example from Milesight) run on batteries and send over LoRaWAN. What matters at this layer is a clean data model - which measurand, which unit, which reporting interval - because everything above is built on it.
Layer 2: Connectivity - LoRaWAN, MQTT and cellular
The connectivity layer carries readings from the device to the platform. Three paths dominate:
- LoRaWAN for low-power radio sensing over long ranges (sites, estates, agriculture). More in What is LoRaWAN?.
- MQTT as a lightweight publish-subscribe protocol for IP-capable devices and as the internal data bus. Details in What is MQTT?.
- Cellular (NB-IoT, LTE-M, 5G) for distributed single devices without local infrastructure, plus Ethernet and Wi-Fi inside buildings.
MQTT is often the connecting element here: LoRaWAN packets, cellular devices and edge nodes ultimately publish to MQTT topics that the platform subscribes to.
Layer 3: Edge and gateway
The gateway sits between radio and platform. With LoRaWAN, a LoRaWAN gateway receives the radio packets and forwards them to the network server ChirpStack, which handles decryption, deduplication and device management at the radio level (chirpstack.io). ChirpStack is open source and fully self-hostable - see What is ChirpStack? and our ChirpStack expertise.
At the edge, Node-RED does protocol conversion (Modbus/OPC-UA to MQTT), buffers data during outages and runs first-line pre-processing or threshold logic locally. For scenarios with unreliable connectivity there is also ThingsBoard Edge, which runs rules close to the machine and syncs with the central platform later.
Layer 4: Platform - ThingsBoard
The platform is the heart of the architecture. ThingsBoard handles device registration and management, a visual rule engine for processing and alarms, multi-tenancy and dashboards. Up to version 4.3 there was a Community Edition under Apache 2.0 with no device limit and a commercial Professional Edition. Since version 4.4 (29 September 2026) there is a single product under the Business Source License 1.1: commercial production is free up to 100 devices on one server, with a licence key and visible branding; above that the commercial licence starts at 99 USD/month (as of October 2026, thingsboard.io/pricing). Existing CE installations secure their size through the Community Grant (registration until 20 July 2027), and the 4.3 LTS line receives security updates until 20 July 2027. Background in the post ThingsBoard 4.4 under BUSL 1.1.
More on features and editions in What is ThingsBoard? and on our ThingsBoard expertise.
Layer 5: Data storage - time-series with InfluxDB or PostgreSQL
IoT generates time-series: many writes, time-indexed, kept for the long term. ThingsBoard uses PostgreSQL for master data and can store telemetry in PostgreSQL, TimescaleDB (the time-series extension for Postgres) or Cassandra. For pure sensor time-series with a high write load - especially together with Grafana - InfluxDB is widely used; today you can choose between InfluxDB 3 Core (open source) and commercial Enterprise variants. The decision follows data rate, retention period and existing operational know-how, not fashion.
Layer 6: Visualisation with Grafana
For dashboards, trends and alerting, Grafana is the standard. It is open source under AGPLv3 (since version 8, grafana.com/licensing), free to self-host and reads directly from InfluxDB, PostgreSQL/TimescaleDB and many other sources. Grafana complements the ThingsBoard dashboards wherever historical analysis, mixed data sources or central operations monitors are needed. There is a concrete guide at Grafana IoT dashboard with InfluxDB and on our Grafana expertise.
Layer 7: Integration with ERP and cloud
At the top, the prepared data stream leaves the IoT world and feeds into business processes: consumption values into the ERP, faults into the ticketing system, KPIs into a BI tool. ThingsBoard provides a REST API, MQTT and Kafka outputs and the rule engine for this; Node-RED builds the flexible flows to ERP, MES, webhooks or databases. The key point is that only aggregated values or alarms leave the system in a controlled way, while the raw data stays on your own infrastructure.
The full self-hosted picture
Put together, the result is an end-to-end open-source stack: LoRaWAN sensors send via a gateway to ChirpStack, IP devices and edge nodes publish over MQTT, ThingsBoard manages devices and rules, InfluxDB or PostgreSQL store the time-series, Grafana visualises, and Node-RED connects ERP and cloud. Everything runs on your own infrastructure - Proxmox, Hetzner or on-prem.
The difference from managed platforms such as AWS IoT, Azure IoT or Cumulocity: you pay for servers and operations instead of licences per device and data point, you keep data sovereignty in the EU, and you can swap any layer individually. Whether that pays off against the cloud is covered in IoT platform: self-hosted vs cloud. How this stack turns into a concrete use case is shown in Predictive maintenance & retrofit.
Build your architecture sovereignly with WZ-IT
We design IoT architectures layer by layer and run them as an open-source stack on your infrastructure - from the LoRaWAN gateway over ThingsBoard and InfluxDB to Grafana and ERP integration. Vendor-neutral, without per-device licences, with honest cost accounting.
See our IoT services - IoT platform development - Book an intro call
