ThingsBoard and ChirpStack do not compete with each other, they complement each other. That is the most common misunderstanding when planning a LoRaWAN solution. ChirpStack is a LoRaWAN Network Server: it brings the radio data from your sensors through the gateways into the network and makes it available as messages. ThingsBoard is an IoT application platform: device management, dashboards, alarms, rule engine, multi-tenancy. The two sit on different layers of the IoT architecture. The typical chain reads: ChirpStack -> MQTT -> ThingsBoard. This article explains the difference, the interplay, and when you only need one of them.
Why "ThingsBoard vs ChirpStack" is the wrong question
Searching for "ThingsBoard vs ChirpStack" assumes both do the same thing. They do not. A LoRaWAN sensor sends a few bytes over radio to a gateway. To turn that radio signal into a usable, decrypted message mapped to the right device, you need a network server. That is exactly what ChirpStack is. Only then does the work of the application platform begin: store values, show them in dashboards, monitor thresholds, trigger notifications, forward data to other systems. That is the domain of ThingsBoard.
For more background on both building blocks, see What is ChirpStack? and What is ThingsBoard?.
What ChirpStack does: the LoRaWAN Network Server
ChirpStack owns the network and connectivity layer for LoRaWAN. Its jobs:
- Connect and manage gateways (through the ChirpStack Gateway Bridge and an MQTT broker).
- Run LoRaWAN sessions: device activation (OTAA/ABP), deduplication of packets received multiple times, frame counters, adaptive data rate.
- Decrypt payloads and pre-decode them through codecs.
- Deliver data: ChirpStack publishes every uplink as JSON or Protobuf on an MQTT topic and additionally offers HTTP and cloud integrations.
Since version 4, the network server and application server have been merged into a single component, and multiple regions are served without separate instances (chirpstack.io/docs/architecture). The current release is ChirpStack v4.19.2 (September 2026) (GitHub releases), licensed under the MIT license and therefore free to use. What ChirpStack deliberately is not: an application platform. It ships a lean web interface for gateways, devices and tenants, but no freely buildable dashboards, no complex rule engine and no reports.
What ThingsBoard does: the IoT application platform
ThingsBoard sits one layer up, on the application and platform level. Its jobs:
- Device management through device profiles (transport, payload format, alarm rules, provisioning).
- Data ingestion through native transports: MQTT, HTTP, CoAP, LwM2M, SNMP.
- Visualization with freely buildable dashboards and widgets.
- Rule engine: rule chains process incoming messages, raise alarms, transform and forward data.
- Multi-tenancy, RBAC, white-labeling (the latter in the Professional Edition up to 4.3, with a commercial license from 4.4).
The current release is ThingsBoard 4.4 (September 2026) under the Business Source License 1.1: free up to 100 devices on one server for commercial use, licensed beyond that. The last line under Apache 2.0 is Community Edition 4.3 (January 2026, with Alarm Rules 2.0 and new calculated fields), which receives security updates until 20 July 2027 (ThingsBoard, announcement). What ThingsBoard deliberately is not: a LoRaWAN Network Server. It cannot process a LoRa radio signal and knows no LoRaWAN sessions. It expects data that someone delivers to it, for example ChirpStack.
Comparison table: ThingsBoard vs ChirpStack
| Criterion | ChirpStack | ThingsBoard |
|---|---|---|
| Purpose | LoRaWAN Network Server (bring data in) | IoT application platform (use the data) |
| Architecture layer | Network / connectivity | Application / platform |
| Core function | Gateways, LoRaWAN sessions, device activation | Dashboards, rule engine, device management |
| Protocols | LoRaWAN (radio), output via MQTT/HTTP | MQTT, HTTP, CoAP, LwM2M, SNMP |
| Dashboards | Minimal (device/gateway management) | Full, freely buildable |
| Rule engine | No | Yes (rule chains) |
| Multi-tenancy | Yes (tenants) | Yes (tenants, customers, RBAC) |
| License | MIT (free) | up to 4.3 CE: Apache 2.0 (free); from 4.4: BUSL 1.1, free up to 100 devices on one server |
| Current version | v4.19.2 (September 2026) | 4.4 (September 2026), LTS 4.3.1.6 |
| Competes with the other? | No, it delivers the data | No, it processes the data |
How they work together: ChirpStack -> MQTT -> ThingsBoard
The standard path in a self-hosted LoRaWAN solution looks like this:
- Sensor -> gateway: the LoRaWAN sensor transmits its bytes to a gateway in range.
- Gateway -> ChirpStack: the gateway forwards the packets to ChirpStack. ChirpStack decrypts, deduplicates and maps them to the device.
- ChirpStack -> MQTT: ChirpStack publishes the uplink as JSON on an MQTT topic (schema
application/<id>/device/<devEUI>/event/up). - MQTT -> ThingsBoard: ThingsBoard receives the message through an integration. An uplink converter decodes the payload and writes the values as telemetry to the matching device.
- Inside ThingsBoard: dashboards show the values, the rule engine checks thresholds, alarms and forwarding.
Two connection paths are common. The convenient native ChirpStack integration with ready-made uplink converters was reserved for ThingsBoard Professional Edition and Cloud up to 4.3 and is included in all license paths since 4.4, under the Community Grant only with the Professional Pack (thingsboard.io/docs). With the Community Edition it works too: ChirpStack pushes the data via MQTT or HTTP straight to the ThingsBoard device API, authenticated with the device access token (chirpstack.io/docs/guides/thingsboard). In practice, an MQTT broker (such as Mosquitto) sits between both services, plus each keeps its own data store (ChirpStack uses PostgreSQL and Redis, ThingsBoard PostgreSQL and optionally TimescaleDB/Cassandra).
When one is enough, when you need both
ChirpStack alone is rarely sufficient on its own. It makes sense when you run only a LoRaWAN Network Server and deliver the data to an existing target system (your own software, a database, a cloud service). ChirpStack's own interface is enough to manage gateways and devices, not for end-user dashboards.
ThingsBoard alone is enough when your devices do not speak LoRaWAN: MQTT, HTTP, CoAP, LwM2M or adapter-connected Modbus/OPC UA devices go straight into ThingsBoard, with no network server at all.
Both together is the rule as soon as you connect LoRaWAN sensors and need real dashboards, alarms, tenant separation and a rule engine. That is the classic build of a sovereign, self-hosted IoT platform: ChirpStack as the network server, ThingsBoard as the application layer, often complemented by Grafana for specialized dashboards. For a broader view of the building blocks, see the comparison of open source IoT platforms.
License and cost in brief
ChirpStack is MIT-licensed and has no editions or per-device fees. For ThingsBoard it depends on the version: the Community Edition up to 4.3 is Apache 2.0 and free, including commercial use, but receives security updates only until 20 July 2027. From version 4.4 the BUSL 1.1 applies: commercial production is free up to 100 devices on one server; beyond that you need a commercial license from 99 USD per month or a perpetual license from 4,999 USD one-time. Existing CE installations can move free of charge at their current size through the Community Grant. ThingsBoard Cloud bills by device (extra devices 0.30 USD/device, managed private cloud from 1,499 USD/month; as per thingsboard.io/pricing, October 2026). The license change is explained in the post ThingsBoard 4.4 under BUSL 1.1. A full breakdown is available under ThingsBoard pricing and How much does ChirpStack cost?.
Important for the total bill: the real cost driver of a self-hosted solution is not licenses but servers, operations and maintenance. This is exactly the advantage over managed IoT clouds (AWS IoT, Azure IoT, Cumulocity), whose per-device and per-message billing explodes with the number of devices. More on that in the comparison IoT self-hosted vs. cloud.
Operations and support
We plan, build and operate sovereign, self-hosted IoT platforms from ChirpStack and ThingsBoard on your infrastructure (Proxmox, Hetzner, on-prem), GDPR-compliant from Germany and without cloud lock-in. Learn more on our pages for ThingsBoard and ChirpStack, in the IoT hub and specifically on LoRaWAN. For a no-obligation initial consultation, book a meeting.
