ThingsBoard vs ChirpStack: Difference and How They Work Together

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.18.0 (May 2026), 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).

The current release is ThingsBoard 4.3 (January 2026) with Alarm Rules 2.0 and new calculated fields. The Community Edition is licensed under Apache 2.0 and is free, including for commercial use. 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

How they work together: ChirpStack -> MQTT -> ThingsBoard

The standard path in a self-hosted LoRaWAN solution looks like this:

1. Sensor -> gateway: the LoRaWAN sensor transmits its bytes to a gateway in range.
2. Gateway -> ChirpStack: the gateway forwards the packets to ChirpStack. ChirpStack decrypts, deduplicates and maps them to the device.
3. ChirpStack -> MQTT: ChirpStack publishes the uplink as JSON on an MQTT topic (schema application/<id>/device/<devEUI>/event/up).
4. 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.
5. 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 is part of ThingsBoard Professional Edition and Cloud (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

Both core components are open source and free of license fees. ChirpStack is MIT-licensed and has no editions or per-device fees. ThingsBoard Community Edition is Apache 2.0 and also free, including commercial use. For features such as white-labeling, advanced RBAC, scheduler and the ready-made platform integrations there is the Professional Edition: as a perpetual license from 4,999 USD one-time or as a cloud/managed model with a per-device component (cloud extra devices from 0.30 USD/device, managed private cloud from 1,499 USD/month; as per thingsboard.io/pricing, June 2026). 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.