What is ChirpStack?

ChirpStack is an open-source LoRaWAN Network Server (LNS). It forms the software layer between your LoRaWAN gateways and your application: it receives the radio data from sensors, decrypts it, manages devices and gateways, and delivers the data in a clean, structured form, via MQTT, HTTP or directly to a database.

Unlike the IoT services of the large cloud providers, ChirpStack belongs to no corporation. It is licensed under the MIT license, is developed primarily by Orne Brocaar (formerly known as LoRa Server, renamed to ChirpStack in 2019), runs on your own infrastructure and ties you to no vendor, neither for hardware nor for operation. That is the decisive difference from proprietary platforms whose providers can change prices or discontinue the service. And the project is no newcomer: it has been used in practice since 2016 (back then as LoRa Server) and is deployed by thousands of users worldwide.

Where ChirpStack sits in the LoRaWAN stack

A LoRaWAN system has four layers:

1. End devices are the sensors that transmit over radio (temperature, fill level, door status and much more).
2. Gateways receive the radio signals and forward them over IP. A gateway is a pure relay, not intelligence.
3. The Network Server is ChirpStack. This is where the real work happens: device authentication, decryption, deduplication of multiply received packets, routing and device management.
4. The application is your dashboard, your database or your platform, which receives the finished, prepared data.

ChirpStack is layer 3, the brain between radio and application. Without a Network Server, your gateways' data is useless: encrypted bytes with no meaning.

The components of ChirpStack v4

With version 4, ChirpStack took a big step toward simplification. Where version 3 still required several separate services (a dedicated Network Server and a separate Application Server), v4 merges these into a single application, rewritten in Rust instead of Go. This significantly reduces installation and maintenance effort, and multi-region operation is now built in, instead of needing a separate server per region.

A complete ChirpStack v4 setup consists of a few building blocks:

• ChirpStack is the unified server including the web UI and gRPC/REST API. The core.
• ChirpStack Gateway Bridge translates between the gateway protocol and MQTT. It is a separate component and can run on the server or directly on the gateway.
• PostgreSQL is the database for devices, applications and configuration. For small or edge setups, ChirpStack v4 alternatively supports SQLite.
• Redis keeps session and device state quickly available.
• MQTT broker, usually Mosquitto, is the central message bus for the data exchange.

This manageable architecture is one reason ChirpStack runs reliably, from a single virtual machine to resource-constrained edge hardware. Organizationally, v4 arranges everything under the concept of the tenant: devices belong to applications, applications to a tenant, which enables clean multi-tenant setups.

What the Network Server actually does

Beyond pure data forwarding, ChirpStack handles the tasks that make LoRaWAN usable in practice:

• Deduplication: When several gateways receive the same packet, it is processed only once.
• Adaptive Data Rate (ADR): With ADR enabled, ChirpStack ensures each device operates at the most efficient data rate and TX power. This saves battery and eases the radio spectrum.
• Device classes A, B and C: All three LoRaWAN classes are supported, from the battery-saving Class A to the low-latency Class C (more in our article on the LoRaWAN device classes A, B and C).
• Live frame-logging: ChirpStack shows every packet per gateway and device in real time, with all RX/TX metadata and the raw LoRaWAN PHYPayload in a readable format. Effectively a Wireshark for LoRaWAN, and indispensable when debugging.
• LoRaWAN 1.0 and 1.1: Both MAC versions are supported simultaneously, including all regional frequency bands and parameter revisions.
• gRPC and REST API: Everything the web interface can do is also available via API. On top of that come ready-made integrations with cloud providers, databases and visualization platforms. This is the basis for automation and connecting to existing systems.

These tasks are the reason a LoRaWAN network needs a Network Server at all: only they turn received radio packets into a reliable, operable system.

ChirpStack vs. The Things Network vs. commercial servers

LoRaWAN data needs a Network Server. There are three fundamental routes:

Honestly: for a quick hobby project or a first test, TTN is perfectly sufficient and ready in minutes. But as soon as it becomes productive, with real customers, data-protection requirements or the wish for independence, there is often no way around your own Network Server. ChirpStack is the established open-source standard here.

When ChirpStack makes sense

ChirpStack is the right choice when you:

• need data sovereignty, for example for GDPR reasons or because the data must not leave the company,
• want to stay independent of gateway manufacturers and mix devices from different vendors,
• manage multiple sites or regions centrally,
• do not want to pay recurring per-device license fees,
• or want to keep full control over configuration, integration and operation.

For a few sensors in a non-critical project, TTN is often enough. From production use onward, your own Network Server becomes the sensible foundation, and ChirpStack is the most mature open-source option for it.

In the next step we show how to set up ChirpStack v4 cleanly, from the first package to the first sensor that delivers data.