Building a Private LoRaWAN Network: Components, Hardware, and Steps with ChirpStack

WZ-IT operates chirphost. Current hosting starts from €129.90 net/month; setup and service level follow the proposal. Former package prices, location lists and cost comparisons in this dated article describe the previous offer, not current WZ-IT terms. View current service scope.

Anyone who wants to collect sensor data over long distances with minimal power consumption can hardly avoid LoRaWAN. The radio protocol bridges several kilometers in open terrain, lets battery sensors run for years, and is suitable for everything from soil-moisture measurement through asset tracking to fill-level monitoring in industry. The central question when building one, however, is not only "which sensors," but: public or private network?

Public networks such as The Things Network are ideal for first experiments. But as soon as proprietary or personally identifiable data is involved, or a larger sensor fleet is operated, data sovereignty, cost structure, and independence clearly argue for your own private network. This is exactly where ChirpStack comes in – the world's most widely used open-source LoRaWAN network server, which provides the functions of a telecom operator on your own server, without per-device license costs. This article explains the components of a private LoRaWAN network, helps with hardware selection, and walks through the steps of the ChirpStack setup – including the honest pitfalls in practical operation.

Also worth reading: ChirpStack vs. The Things Stack · ChirpStack Hosting: Managed vs. Self-Hosted

What LoRaWAN is and what it is suited for

LoRaWAN stands for Long Range Wide Area Network and is a radio protocol for the Internet of Things. It is optimized to transmit small amounts of data over long distances with very low energy consumption. A typical LoRaWAN sensor sends a few bytes every few minutes – a measurement, a meter reading, a status message – and runs for years on a single battery.

These characteristics make LoRaWAN the first choice for applications where cellular would be too expensive or too power-hungry and Wi-Fi too short-range: smart metering for water and heat utilities, environmental and machine sensing in industry, soil-moisture and weather stations in agriculture, occupancy and air-quality sensors in smart buildings, level and parking measurement in municipalities.

LoRaWAN has three device classes. Class A is the power-saving standard: each uplink is followed by two short receive windows, otherwise the device sleeps. Class B adds scheduled downlink windows at fixed times, Class C keeps the receiver continuously open – faster to reach, but more energy-hungry. In Europe, and thus in the DACH region, LoRaWAN operates in the license-free EU868 frequency band. License-free means no frequency application is needed. However, a transmission-time restriction (duty cycle) applies, which limits the maximum message frequency per device – a point that becomes relevant in dense networks.

Private or public? When your own network pays off

Public LoRaWAN networks such as The Things Network are free, quickly available, and excellent for testing. For productive enterprise use, however, three reasons argue for a private network:

• Data sovereignty: In a private network, the gateway speaks exclusively with your own server. The data never leaves your own infrastructure – relevant for GDPR, security regulations, and trade secrets.
• Cost structure: Commercial LoRaWAN platforms often bill per device per month. With thousands of sensors, this subscription model scales uncomfortably. Your own network has no per-device software costs after the one-time gateway investment when self-hosted.
• Control and independence: No dependence on the availability or business decisions of a third-party provider.

To stay honest: for experiments, prototypes, or projects with few sensors in a region with good TTN coverage, a public network is perfectly sufficient – and the fastest start. The shift to a private network pays off for productive, data-sensitive, or large deployments. If you already run devices on the public network, you do not have to start from scratch: the matching guide shows how to migrate an existing fleet from TTN to ChirpStack. The direct architecture comparison is in ChirpStack vs. The Things Stack.

The components of a private LoRaWAN network

A private LoRaWAN network consists of a few clearly delimited building blocks:

The data flow in one sentence: sensor sends an encrypted radio packet → gateway receives and forwards it as UDP → gateway bridge converts it to MQTT → ChirpStack authenticates, deduplicates, and decodes → integration passes the payload to the target application.

ChirpStack has established itself as the de facto standard for the network-server layer because it is open source, comes with a web interface to manage gateways, devices, and tenants, and can be extended via a gRPC API. Since ChirpStack v4, the network server and application server are merged into a single service, configured via a central chirpstack.toml plus region-specific region_*.toml files – which simplifies operation considerably compared to the separate v3 architecture.

Choosing hardware

Gateways

The gateway is the most important hardware decision. For indoor applications or small pilot projects, an 8-channel gateway from vendors like RAK Wireless (e.g. RAK7268) or Dragino is enough. For outdoor coverage, industrial environments, or larger areas, more robust devices from Kerlink, Multitech, or Robustel make sense – often with LTE backhaul for sites without a fixed line. The correct frequency band (EU868 in DACH) and the antenna position are decisive: the latter influences the range more than the gateway brand.

Sensors

The sensors depend on the use case – temperature, air quality, fill level, soil moisture, tracking, meter readings. Common EU868 vendors are Dragino, Milesight, and Elsys. It is important that the sensors are LoRaWAN-certified and provide or document a matching payload codec so that ChirpStack can decode the raw data.

Server requirements

ChirpStack itself is frugal. The stack runs as a Docker Compose setup of ChirpStack, PostgreSQL, Redis, and an MQTT broker (e.g. Mosquitto). For a pilot or small production network, a small server is enough. As the device fleet grows, database sizing and MQTT broker tuning become relevant.

Setting up ChirpStack – the steps at a glance

The following is an architecture roadmap, not a complete tutorial – it shows the order of steps from an empty server to the first received sensor value:

1. Deploy ChirpStack – start a Docker Compose stack of ChirpStack, PostgreSQL, Redis, and Mosquitto. In chirpstack.toml, enable the EU868 region and set the parameters including net_id in the corresponding region_eu868.toml.
2. Configure the gateway – set up the packet forwarder or ChirpStack gateway bridge on the gateway, with the server's MQTT broker as the target. Optionally mutual TLS with per-gateway client certificates.
3. Register the gateway – create the gateway EUI in the ChirpStack web interface.
4. Create a device profile – set the LoRaWAN version, regional parameters, and device class (A/B/C).
5. Add sensors – enter the DevEUI and AppKey, store the payload codec.
6. Join procedure – the sensor performs the OTAA join and appears in the live frame log.
7. Set up the integration – connect PostgreSQL, MQTT, Grafana, or ThingsBoard for data forwarding.

At the latest at the live frame log, it becomes clear whether the gateway, bridge, broker, and server work together correctly – the most common point where errors surface in practice.

The caveats in practical operation

A private network is not "set and forget." These points should be planned for realistically:

• Duty cycle: EU868 is license-free but subject to a transmission-time restriction (typically 1% per sub-band). This limits the message frequency per device – relevant in dense deployments.
• Gateway placement: The range depends massively on antenna position and environment. An indoor gateway does not cover what an outdoor gateway with a high antenna achieves.
• Configuration complexity: The interplay of packet forwarder, gateway bridge, MQTT broker, and network server is error-prone and partly poorly documented. This is where most time is lost in practice.
• Scaling: As the fleet grows, database tuning, MQTT broker sizing, and backup strategy become a continuous task.
• Monitoring: Gateway reachability, packet loss, and sensor battery levels need to be monitored, otherwise an outage is only noticed when data is missing.

Self-hosted or managed?

Self-hosting ChirpStack gives full control and incurs no ongoing license costs – but it is exactly the operational effort from the previous section: server, MQTT broker, database, backups, updates, monitoring, and scaling. For a small pilot project with a technical team, that is perfectly legitimate.

A managed solution takes over this operational load and delivers a ready-to-use network server. You then only deal with gateways and sensors. This makes sense when there is no dedicated team for continuous operation or when the network runs productively and business-critically. The honest trade-off with concrete criteria is in ChirpStack Hosting: Managed vs. Self-Hosted; how ChirpStack compares to a commercial enterprise platform is shown in ChirpStack vs. Actility ThingPark.

What the managed route looks like in practice is shown by managed ChirpStack hosting in German data centers: a dedicated instance, MQTT broker, backups and updates included.

Data sovereignty and compliance

The strongest reason for a private network in the DACH market is data sovereignty. LoRaWAN encrypts the radio transmission by default with AES-128 on the network and application layers – so the transmission itself is secured. The actual compliance question is where the data flows afterward:

• GDPR: If sensors capture personally identifiable data (e.g. occupancy or tracking sensors), GDPR applies. A private network keeps the data in your own infrastructure – cleaner for data-protection documentation than a US-cloud LNS.
• EU Data Act: Who owns the sensor data of a connected product, and in what format it must be accessible, is governed by the EU Data Act for LoRaWAN sensor data – with the design obligation taking effect on 12 September 2026 for newly placed products.
• Federal Network Agency: The EU868 duty-cycle rules must be observed.
• NIS2: In critical-infrastructure sectors (energy, water), IoT networks fall under the security requirements – encryption and access control are subject to documentation.

With a German managed provider, the network server itself additionally stays in EU-sovereign infrastructure – the entire chain from the sensor through the gateway to the server is then within your own area of responsibility.

Note: not legal advice. For specific compliance questions, consult data-protection and legal advisers.

New article: German building owners face a deadline on 31 December 2026: remote-readable meters under the Heating Cost Ordinance and where LoRaWAN fits.

Conclusion

A private LoRaWAN network is not rocket science, but it is also not plug-and-play: with sensors, a gateway, a gateway bridge, ChirpStack as the network server, and an integration, the architecture is in place – the stumbling blocks lie in configuring the components, gateway placement, and ongoing operation. Anyone who wants data sovereignty, predictable costs without a per-device subscription, and full control is exactly right with their own network built on ChirpStack.

Managed ChirpStack from chirphost takes over the most demanding part – operating the network-server layer:

• ✓ ChirpStack v4 ready to run, without configuration stumbling blocks
• ✓ PostgreSQL, MQTT broker, backups, updates, and monitoring included
• ✓ Network server in German infrastructure (data sovereignty)
• ✓ No per-device software costs
• ✓ Try it free for 7 days

What the plans cost and which plan fits which fleet size is set out in the pricing for managed ChirpStack.

Agree scope and provisioning with WZ-IT. Provisioning and contract terms are agreed with WZ-IT in the proposal. There is no self-service portal or automatic trial subscription.

Read more: ChirpStack vs. The Things Stack and ChirpStack Hosting: Managed vs. Self-Hosted.

If you would rather not operate the network layer yourself, scope, SLA and the eight regions are covered on the rent a LoRaWAN network server page.

Sources

• ChirpStack – official website
• ChirpStack – architecture documentation
• ChirpStack – gateway configuration
• ChirpStack GitHub repository
• Robustel – Build a Private LoRaWAN Network with ChirpStack
• prbs23 – Getting Started With a Private LoRaWAN Network Using ChirpStack v4
• LoRa Alliance – Regional Parameters (RP002, EU868)