Before we built Chirpcloud, we ran our own LoRaWAN network servers. ChirpStack on a couple of VMs, a few hundred devices, nothing fancy. It worked, right up until it didn't.
What a LoRaWAN network server actually does
If you are new to this, the network server is the bit in the middle. Gateways pick up radio transmissions from sensors and forward them. The network server handles device authentication, deduplication (since multiple gateways often hear the same packet), adaptive data rate management, and routing data to the right application. It also manages the join process when new devices come online and handles any downlink commands you want to send back to devices.
It is not the most visible part of an IoT deployment, but everything passes through it. When it goes down, your entire sensor network goes dark.
The self-hosting experience
Self-hosting gives you complete control, and for small deployments that can be all you need. We ran ChirpStack on a pair of Linux VMs with a PostgreSQL database and Redis for caching. Setup took about a day. For the first six months, it was fine.
The problems started when we scaled past a few hundred devices. Database performance needed tuning. We hit memory limits during traffic spikes when a large batch of devices all joined at once. Backups needed automating properly. TLS certificates needed renewing. ChirpStack released updates and we had to find time to test and apply them without disrupting live devices.
None of this was insurmountable, but it was a steady drip of operational work that pulled engineering time away from the things we were actually trying to build. And the night one of the VMs ran out of disk space at 2am, taking the entire network offline for three hours, was the point where we decided something had to change.
Why we built Chirpcloud
Chirpcloud came out of that experience. We wanted managed LoRaWAN network server hosting that just works, the same way you would use a managed database rather than running PostgreSQL on bare metal.
Under the hood, Chirpcloud runs ChirpStack with high-availability infrastructure, automated backups, monitoring, and scaling built in. Devices connect, data flows, and the operational burden sits with us rather than with the client.
What that means in practice: no servers to patch, no database tuning, no 2am outages because a disk filled up. New devices can be onboarded through the API or the web console. Scaling from a hundred devices to ten thousand does not require any infrastructure changes on the client side.
We also handle the bits that are easy to forget. Security patches get applied promptly. TLS is managed automatically. We monitor packet delivery rates and gateway connectivity so we can flag issues before they affect data flow.
When self-hosting still makes sense
We are not going to pretend managed hosting is always the right answer. If you have strict data sovereignty requirements that prevent any third-party processing, self-hosting might be necessary. If you have a large DevOps team that already manages similar infrastructure and you need deep customisation of the network server behaviour, running your own instance gives you that flexibility.
But for the majority of organisations deploying LoRaWAN, the network server is a means to an end. You want sensor data to flow reliably from device to application. How the network server achieves that is an implementation detail, and paying someone else to worry about it usually makes more sense than building that expertise in-house.
How it fits with the rest of the stack
Because Chirpcloud is part of Connect IoT Group, it integrates directly with EdgePilot for gateway management, Hexaspot for device provisioning, and Trackpac for application-layer dashboards. When a new device ships from Hexaspot, it can arrive pre-registered on Chirpcloud and ready to report data the moment it powers on. That kind of coordination across the stack is difficult to achieve when every layer comes from a different vendor.
Skip the server management. Chirpcloud gives you managed LoRaWAN network hosting with zero infrastructure overhead.
Visit Chirpcloud
