ChirpStack is an open-source LoRaWAN network server, self-hostable on a VPS, that manages gateways and devices for long-range, low-power sensors, the kind of deployment where MQTT-over-Wi-Fi or cellular doesn’t fit because devices need to run for years on a battery and communicate over kilometres rather than metres. ChirpStack v4 combines its network and application server into a single component, talking to gateways via a Gateway Bridge over MQTT.
The problem this solves
Everything else on this site assumes devices with reasonably steady power and either Wi-Fi or a cellular connection. Plenty of real IoT use cases don’t fit that profile: a soil moisture sensor in a field, an asset tracker on a shipping container, a water meter in a remote location, all need to run for months or years on a small battery and communicate over distances Wi-Fi can’t reach. LoRaWAN is built specifically for this: long range (kilometres in open terrain), very low power consumption, at the cost of low bandwidth and infrequent messages, an entirely reasonable trade-off for sensors that only need to report occasionally.
How the pieces fit together
A LoRaWAN deployment has more moving parts than a simple MQTT setup, worth understanding before installing anything:
- End devices (sensors) communicate wirelessly with a LoRa gateway, the only wireless hop in the whole chain.
- A LoRa Gateway runs a Packet Forwarder (commonly the Semtech UDP or Basic Station implementation), listening across multiple channels and forwarding received data onward over a normal IP connection.
- ChirpStack Gateway Bridge sits between the Packet Forwarder and an MQTT broker, translating the gateway’s native protocol into the format ChirpStack’s own components understand.
- The ChirpStack Server (network server and application server merged into one component as of v4) handles device authentication, message routing, and provides the web interface and API for managing gateways, devices and tenants.
- A database (PostgreSQL for production, SQLite for smaller or embedded deployments) stores ChirpStack’s own configuration and device data.
Everything from the Gateway Bridge onward runs comfortably on a VPS; only the physical LoRa gateway itself needs to be in range of your devices, which can be anywhere with an internet connection back to your VPS.
Installing via Docker Compose
ChirpStack’s official deployment is Docker-based, the simplest path on a VPS already following this site’s Docker conventions:
git clone https://github.com/chirpstack/chirpstack-docker.git
cd chirpstack-docker
docker compose up -dThis brings up the ChirpStack Server, a PostgreSQL database, Redis (used internally for device session state), and Mosquitto if you don’t already have a broker running, all defined in the project’s docker-compose.yml. If you’re already running Mosquitto for other services on the same VPS, as covered in this site’s MQTT guide, ChirpStack can be configured to use that existing broker instead of running a second one, worth adjusting in the Compose file before first bringing the stack up.
Once running, the web interface is reachable on the configured port (commonly 8080 in the default Compose setup, worth checking for conflicts if ThingsBoard or another service is already using that port on the same VPS), with an initial admin account created during first setup.
Connecting your first gateway
Physical LoRa gateways vary by manufacturer, but the configuration step is consistent: point the gateway’s Packet Forwarder configuration at your VPS’s IP address and the relevant port (typically a UDP port for Semtech UDP forwarder-based gateways), matching whichever region’s frequency plan applies (EU868 for Europe, US915 for North America, and others depending on location, a regulatory requirement, not a configuration preference). Once connected, the gateway should appear as active in ChirpStack’s web interface, the first confirmation the whole chain is working before adding any actual sensors.
Registering a device
Each LoRaWAN device needs registering in ChirpStack with its DevEUI, AppEUI/JoinEUI and application key, credentials normally printed on the device itself or provided by its manufacturer. ChirpStack’s web interface handles this through a guided device registration flow, after which a properly configured device should complete its “join” procedure (LoRaWAN’s term for initial network authentication) and begin reporting data, visible directly in ChirpStack’s device view as it arrives.
Bridging into the rest of your stack
This is where ChirpStack connects to everything else covered on this site: ChirpStack supports MQTT-based integrations natively, publishing decoded device data to topics your existing Mosquitto broker can already handle, from which Node-RED or Grafana and InfluxDB pick it up exactly the same way as any other MQTT-based device. LoRaWAN’s complexity is genuinely contained at the gateway and network-server layer; once data reaches MQTT, it’s indistinguishable from any other source as far as the rest of your stack is concerned.
ChirpStack vs a public LoRaWAN network
| Approach | Best for |
|---|---|
| Self-hosted ChirpStack | Private deployments, full data control, custom integrations, no per-device network fees |
| Public network (e.g. The Things Network, a carrier LoRaWAN network) | Wide existing gateway coverage you don’t have to build yourself, lower upfront effort |
Self-hosting suits most projects on this site: full control, no recurring per-device network fees, and a deployment that fits the same VPS-based pattern as everything else here. A public network can be the better fit specifically where existing gateway coverage in your area is good and you don’t want to deploy your own gateway hardware at all.
Sizing for this role
ChirpStack itself is relatively light, the actual load scales with device count and message frequency rather than raw connection count, since LoRaWAN devices report infrequently by design. 2 vCPU and 2-4GB RAM is a reasonable starting point for most projects on this site, similar in profile to the MQTT and Node-RED combination covered elsewhere.
Frequently asked questions
Do I need to buy a LoRa gateway, or can I use a Raspberry Pi with a LoRa module?
Both are common. A Raspberry Pi with a LoRa concentrator HAT is a popular, lower-cost way to build a gateway for smaller deployments; dedicated commercial gateway hardware offers more channels and better range for larger or more demanding setups.
How far can LoRaWAN devices actually reach?
Highly dependent on terrain and obstacles: several kilometres in open rural conditions, often a few hundred metres to a kilometre or so in dense urban environments with buildings in the way. Testing range with your actual deployment site and devices is more reliable than relying on manufacturer headline figures alone.
Does ChirpStack support devices from any manufacturer?
Yes, as long as the device implements standard LoRaWAN, which is the entire point of the standard, ChirpStack isn’t tied to specific hardware. Device-specific payload decoders (translating a device’s raw bytes into meaningful values) are sometimes needed and are configured within ChirpStack per device profile.
Can I run ChirpStack on the same VPS as Mosquitto, Node-RED and ThingsBoard?
Yes, with attention to port conflicts (ChirpStack’s web interface and ThingsBoard both commonly default to port 8080, for example) and the same resource-sizing discipline as any multi-service Docker setup, covered in Docker on a VPS.
Is LoRaWAN suitable for anything beyond simple sensors?
Its low bandwidth (messages are small, and there are regulatory limits on how often a device can transmit) makes it unsuitable for anything needing frequent updates or large payloads, video being the clearest example of what it can’t do. For infrequent sensor readings, exactly the use case it was designed for, it’s an excellent fit.
Device classes: a distinction worth understanding
LoRaWAN defines three device classes, and which one a device implements affects how it behaves practically. Class A devices, the overwhelming majority of battery-powered sensors, only open a brief receive window immediately after they transmit, the most power-efficient option and the right default for anything reporting infrequently with no need to receive commands promptly. Class B devices add scheduled receive windows on top of Class A’s behaviour, a middle ground for devices needing somewhat more responsive downlink communication while still conserving power. Class C devices keep their receiver open continuously, sacrificing battery life for near-instant downlink responsiveness, generally reserved for mains-powered devices like actuators that genuinely need to respond to commands quickly. Most sensor deployments covered by this site’s use cases are Class A devices, and ChirpStack handles the distinction transparently once a device’s profile is configured correctly.
Downlink messages: sending commands back to devices
Beyond receiving sensor data, ChirpStack supports sending downlink messages back to devices, useful for occasionally adjusting a sensor’s reporting interval remotely or triggering an actuator. Because of LoRaWAN’s narrow receive windows on Class A devices specifically, downlinks aren’t instant the way an MQTT publish to a constantly-connected device would be, they’re queued and delivered the next time the device’s receive window opens, an important behavioural difference worth designing around rather than assuming downlink commands behave like a typical always-connected IoT device.
A note on application integrations beyond MQTT
While this guide focuses on MQTT integration to fit with the rest of this site’s stack, ChirpStack also supports HTTP webhook integrations and native connectors to several cloud platforms directly, worth knowing about if a specific project needs to forward LoRaWAN data somewhere beyond the MQTT-based pattern covered here, without needing an intermediate translation step.
What’s the regulatory consideration with frequency plans?
LoRaWAN operates in unlicensed spectrum bands that differ by region (868MHz in Europe, 915MHz in North America, and others), with specific duty-cycle and power limits set by local regulators. Configuring ChirpStack and your devices for the correct regional plan isn’t optional, using the wrong one can mean non-compliant transmission, not just a technical mismatch.
How do I monitor whether a LoRaWAN device has gone offline?
ChirpStack’s web interface shows last-seen timestamps per device; for automated alerting on a device going quiet, the same MQTT-based pattern covered in this site’s other guides applies, a Node-RED flow checking for expected message intervals and alerting when a device misses its expected reporting window.
Can ChirpStack manage gateways from multiple manufacturers in one deployment?
Yes, since ChirpStack’s Gateway Bridge works with any gateway running a compatible Packet Forwarder, regardless of manufacturer, mixed-vendor gateway deployments are entirely normal and well supported.
Gateway placement: getting coverage right
A single, well-placed gateway, ideally elevated with a clear line of sight toward where devices will actually be deployed, often covers a surprisingly large area for the kind of low-density sensor deployments common to projects on this site. For larger sites or anything with significant obstructions (multiple buildings, dense urban surroundings), a coverage survey using a portable test device before committing to a single gateway’s placement saves the frustration of discovering dead zones after sensors are already deployed and difficult to reach. ChirpStack’s per-gateway signal strength reporting, visible in its web interface, is useful for diagnosing weak coverage once a gateway is live.
Is battery life genuinely as good as LoRaWAN’s reputation suggests?
For well-designed Class A devices reporting infrequently, multi-year battery life on a single small cell is realistic and commonly achieved in practice, a genuine and significant advantage over Wi-Fi or cellular-connected sensors for this specific use case.
Can I run more than one gateway connected to the same ChirpStack server?
Yes, and it’s the normal pattern for covering a larger area or improving reliability through overlap; ChirpStack deduplicates messages received by multiple gateways automatically, so devices within range of two gateways simply benefit from improved reliability rather than causing duplicate data.
How do I choose between ChirpStack and a managed LoRaWAN platform like The Things Industries?
The same self-hosted-versus-managed trade-off covered elsewhere on this site applies here directly: ChirpStack gives full control and no recurring per-device fees at the cost of self-managing the infrastructure, while a managed LoRaWAN platform trades that control for convenience and support, worth weighing against your specific project’s scale and team capability.
Getting started without overcommitting upfront
A sensible first step before committing to a full deployment: a single gateway and two or three test devices, enough to confirm the whole chain (gateway, Gateway Bridge, ChirpStack Server, MQTT integration) works correctly in your specific environment before investing in additional gateways or a larger device rollout. The architecture scales cleanly from this small starting point, so nothing about starting small is wasted effort once a real deployment follows.
Can ChirpStack data feed into ThingsBoard instead of a hand-built Grafana dashboard?
Yes, since ChirpStack’s MQTT integration publishes standard MQTT messages, ThingsBoard can subscribe to them the same way it would any other device data, useful for organisations wanting LoRaWAN sensors alongside other device types in one unified ThingsBoard deployment.