Running Your Own ChirpStack LoRaWAN Network Server on Raspberry Pi

This site's LoRaWAN gateway guide walks through joining The Things Network (TTN) — a free, hosted LoRaWAN network server that most hobbyists reach for first because there's nothing to run yourself. But TTN is only one piece of the LoRaWAN stack: a gateway forwards raw radio packets somewhere, and that "somewhere" is a network server that handles de-duplication, MAC layer processing, join procedures, and routing decoded payloads onward to an application. ChirpStack is the leading open-source network server, and running it yourself on a Raspberry Pi gives you a private LoRaWAN deployment with no dependence on a third-party service, no coverage-map uncertainty about whether TTN has a nearby community gateway, and full control over device provisioning — genuinely useful once you're running more than a couple of sensor nodes or want the network entirely offline from the public internet.

Why Self-Host Instead of Using TTN

ConsiderationThe Things Network (Hosted)ChirpStack (Self-Hosted) Setup effortLow — register gateway and devices in a web consoleHigher — you run the network server, application server, and database yourself Internet dependencyRequires internet access for every uplink to reach TTN's serversCan run fully offline/local if your gateway and applications are also local Data ownershipPayloads pass through TTN's infrastructurePayloads never leave your own network unless you choose to forward them Device/gateway limitsFair-use policies on community gatewaysLimited only by your own hardware Best fitHobby projects, community coverage areas, quick startsProperty-wide sensor networks, offline/remote sites, privacy-sensitive deployments, learning the full LoRaWAN stack

If you're covering a single farm, shop, or off-grid property with your own gateway and your own sensor nodes, there's rarely a good reason to route that traffic through a public network server at all — ChirpStack keeps the whole stack local and gives you a real look at what a network server is actually doing between your gateway and your application.

Architecture Overview

ChirpStack (v4) is split into a few cooperating services, all of which can run comfortably on a Raspberry Pi 4 or 5 for a small-to-medium deployment:

• ChirpStack Gateway Bridge — receives packet-forwarder UDP traffic from your LoRa gateway (the same Semtech UDP packet-forwarder protocol used to reach TTN) and converts it to MQTT.
• ChirpStack Network Server — the core service handling MAC commands, de-duplication across multiple gateways, ADR (adaptive data rate), and device session state, backed by a PostgreSQL database and Redis for session state.
• MQTT broker (typically Eclipse Mosquitto) — the message bus everything communicates through, including your own applications subscribing to decoded uplink payloads.
• ChirpStack web UI — where you provision gateways, register devices, define device profiles, and view live event logs.

Installation on a Raspberry Pi

1. Start from a 64-bit Raspberry Pi OS (Lite is fine) on a Pi 4 or 5 with at least 4GB RAM — PostgreSQL, Redis, and the ChirpStack services together are noticeably heavier than a typical single-service Pi project.
2. Install Docker and Docker Compose — ChirpStack's official Docker Compose setup is by far the least error-prone way to get PostgreSQL, Redis, Mosquitto, the Gateway Bridge, and the Network Server running together with correct networking between them, rather than installing each service natively and wiring up configs by hand.
3. Pull ChirpStack's official docker-compose configuration, adjust the region-specific frequency plan in the network server config to match your local ISM band (US915, EU868, AU915, etc. — this must match your gateway and end-device hardware exactly or nothing will join), and bring the stack up.
4. Point your existing LoRa gateway's packet-forwarder configuration at the Pi's IP address on the Gateway Bridge's UDP port, the same way you'd configure it to reach a TTN forwarding endpoint, just pointed inward at your own network instead.
5. Log into the ChirpStack web UI, register your gateway by its EUI, then provision device profiles and register your end devices with their DevEUI, AppEUI/JoinEUI, and AppKey for OTAA joining — the same credentials you'd normally have entered into TTN's console.

Getting Your ESP32 Nodes to Join

Nothing changes on the device side — an ESP32 running RadioLib or a LoRaWAN stack configured for OTAA join behaves identically whether it's joining TTN or your own ChirpStack instance, because it's talking the same standard LoRaWAN join procedure either way. The only difference is which server the join request routes through, which is entirely determined by which gateway receives it and where that gateway's packet forwarder points. This means you can migrate a sensor network from TTN to a self-hosted ChirpStack instance (or run both side by side, pointing a second gateway at each) without touching a single line of device firmware.

Getting Data Out

ChirpStack publishes decoded uplink payloads to its MQTT broker on a per-application topic. From there, feeding Node-RED or Home Assistant's MQTT integration — both already covered on this site for ESP32 sensor networks — is a direct drop-in: point them at your Pi's Mosquitto broker instead of a cloud MQTT bridge, and the rest of your automation pipeline doesn't need to know or care that the network server underneath it is now local rather than TTN's infrastructure.

When TTN Still Makes More Sense

If you're relying on community gateway coverage you don't own, want the absolute fastest path to a first working sensor, or don't have a Pi you want dedicating to always-on infrastructure, TTN remains the better starting point. ChirpStack earns its added complexity once you own the whole chain — your own gateway, your own devices, and a reason to keep that traffic off a third party's servers — and it's also simply a good way to understand what a LoRaWAN network server is actually doing, rather than treating it as an opaque cloud service.