ChirpStack is the standard open-source LoRaWAN network server. It runs on a VPS with 2 vCPU and 2GB RAM minimum. Your LoRa gateways connect to the VPS over the internet; ChirpStack decodes the LoRaWAN payloads and forwards device data to your MQTT broker or HTTP endpoints. No per-message cloud charges.
How LoRaWAN and a VPS fit together
LoRaWAN is a low-power wide-area network protocol designed for sensors that send small amounts of data over long distances. A LoRa gateway receives radio signals from sensors (up to several kilometres away) and forwards the packets over the internet to a network server.
The network server is where your VPS comes in. It:
- Receives UDP packets from LoRa gateways
- Handles LoRaWAN MAC-layer processing (OTAA/ABP device activation, ADR, downlinks)
- Decodes application payloads (with a custom codec per device type)
- Forwards decoded data to your application layer (MQTT, HTTP webhook, or integrated database)
ChirpStack: the right choice for self-hosted LoRaWAN
ChirpStack (formerly LoRa Server) is the most widely deployed open-source LoRaWAN network server. ChirpStack v4 runs as a single binary (or in Docker) and includes:
- Network server (MAC processing)
- Application server (device management, payload decoding)
- Web UI for device and gateway management
- Built-in MQTT integration
- REST API for automation
VPS sizing for ChirpStack
| Device count | Message rate | VPS minimum |
|---|---|---|
| 1-100 devices | Class A, low uplink rate | 2 vCPU, 2GB RAM |
| 100-1,000 devices | Class A/C, moderate | 4 vCPU, 4GB RAM |
| 1,000-10,000 devices | Any | 4-8 vCPU, 8GB RAM |
ChirpStack uses PostgreSQL for device state and Redis for real-time data. Both are included when deploying via the official Docker Compose file.
Installing ChirpStack with Docker Compose
# Clone the ChirpStack Docker repo
git clone https://github.com/chirpstack/chirpstack-docker.git
cd chirpstack-docker
# Edit configuration
cp .env.example .env
nano .env # Set your region, secret keys
# Start the stack
docker compose up -d
# Check it is running
docker compose ps
# chirpstack, chirpstack-gateway-bridge, postgresql, redis all should show healthyChirpStack’s web UI is available on port 8080 by default. Put Nginx in front for HTTPS access.
Connecting a LoRa gateway
Most LoRa gateways (RAK, Dragino, TTIG, Kerlink) support the Semtech UDP packet forwarder or the ChirpStack Gateway Bridge. Point the gateway at your VPS IP on port 1700 (UDP) for the Semtech forwarder, or configure the MQTT-based Gateway Bridge.
Open the required ports on your VPS firewall:
sudo ufw allow 1700/udp # Semtech UDP packet forwarder
sudo ufw allow 8080/tcp # ChirpStack web UI (use Nginx + HTTPS in production)
sudo ufw allow 1883/tcp # MQTT (or 8883 for TLS)Routing LoRaWAN data to dashboards
ChirpStack publishes decoded device uplinks to MQTT topics following the pattern: application/{applicationID}/device/{devEUI}/event/up. Node-RED subscribes to these topics and routes data to InfluxDB for time-series storage and Grafana for dashboards.
The full stack (ChirpStack + MQTT + Node-RED + Grafana + InfluxDB) runs comfortably on a single 4 vCPU / 4GB RAM VPS using Docker Compose.
LoRaWAN use cases that work well with a self-hosted VPS
- Agricultural monitoring (soil moisture, weather stations, livestock tracking)
- Smart metering (water, gas, electricity sub-meters)
- Cold chain and temperature monitoring
- Asset tracking across large sites
- Air quality and environmental sensing
- Building management (occupancy, CO2, energy)
The full ChirpStack VPS guide covers gateway placement, frequency plan configuration and payload codec writing.
Gateway placement and coverage planning
A LoRa gateway mounted at 5-10 metres height in a UK suburban environment typically covers 2-5km radius. In open rural areas, this extends to 10-15km with clear line of sight. The exact range depends on obstacles, building density and the spreading factor (SF) used by each sensor. SF12 gives the maximum range but the lowest data rate; SF7 gives higher data rate for shorter-range sensors.
For a single-site deployment (one farm, one industrial estate, one urban block), one gateway is usually sufficient. For city-wide coverage or multiple dispersed sites, multiple gateways connect to the same ChirpStack server on the VPS. ChirpStack handles deduplication when a sensor is heard by multiple gateways simultaneously.
Comparing a self-hosted LoRaWAN server to Helium or TTN
| Self-hosted ChirpStack | The Things Network (TTN) | Helium Network | |
|---|---|---|---|
| Coverage | Your own gateways only | Community gateways globally | Community hotspots |
| Data control | Fully yours | TTN processes data | Helium processes data |
| Cost | VPS + gateway hardware | Free (fair use) | Pay-per-message (DC tokens) |
| SLA | Your VPS SLA | None (community) | None guaranteed |
| Right for | Private, production deployments | Prototyping, urban coverage | Wide-area consumer IoT |
UK LoRaWAN deployments: OFCOM licensing
LoRa gateways operating on 868 MHz in the UK fall under the Short Range Devices (SRD) licence exemption. No spectrum licence is required. The gateway must comply with the relevant ETSI standard (EN 300 220) for power limits and duty cycle. Indoor gateways are generally straightforward; outdoor deployments in certain locations may require planning permission for the antenna mounting rather than any radio licensing.
Device management and payload codecs in ChirpStack
ChirpStack’s application server handles device management: adding devices (by DevEUI, AppKey for OTAA), organising them into applications and device profiles, and writing JavaScript payload codecs that decode the raw bytes each sensor type sends into readable JSON (temperature in degrees, humidity as a percentage, GPS coordinates in decimal degrees). Once a codec is written for a specific sensor model, it applies to all devices of that type. The decoded JSON is what appears on MQTT topics and in the web UI, and what flows into Node-RED and Grafana.
Most sensor manufacturers provide ready-made ChirpStack payload codecs for their devices. Check the manufacturer’s GitHub repository or documentation before writing a codec from scratch.
Frequently asked questions
What frequency plan should I use for a UK LoRaWAN deployment?
EU868 (868 MHz) is the standard for UK and European deployments. This is the default in ChirpStack for European regions. The specific channels depend on your LoRa gateway configuration.
Do I need a LoRa gateway for every sensor?
No. One LoRa gateway covers a large geographic area – typically 2-5km in urban environments and up to 15km in open rural areas. Multiple sensors report to one gateway. The gateway forwards all received packets to ChirpStack on the VPS.
Can I use The Things Network instead of a self-hosted ChirpStack?
Yes. The Things Network (TTN) is a free, community-run LoRaWAN network. It is a good starting point for prototyping. Self-hosted ChirpStack is better for production: no dependency on community infrastructure, full control over data, no fair-use data limits.
What is the difference between OTAA and ABP device activation?
OTAA (Over-The-Air Activation) is the recommended method: the device performs a join procedure with the network server and receives session keys dynamically. ABP (Activation By Personalisation) hard-codes session keys into the device. OTAA is more secure and should be used for all new deployments.
How long do LoRaWAN devices run on batteries?
LoRaWAN devices are designed for battery longevity. Class A devices (the most common) only transmit briefly and then sleep. Depending on message frequency and battery size, 2-10 years of battery life is achievable. ChirpStack’s Adaptive Data Rate (ADR) optimises transmit parameters to extend battery life further.