You picked LoRaWAN for the range and the battery life. Good. Now you have a second decision that matters just as much, and most teams rush it: who runs the network your devices talk to?
There are three answers. You can join a public community network like The Things Network. You can ride a decentralized coverage network like Helium. Or you can run your own gateways with a network server such as The Things Stack or ChirpStack. Each one moves the same LoRaWAN packets. What changes is who controls coverage, who guarantees uptime, who sees your traffic, and who pays for what.
This guide walks the three models, the tradeoffs between them, and when each one is the right call. At the end it connects the network-server decision to the layer above it, because that is the part teams forget about until the data starts flowing and nobody has decided where it goes.
The three models, plainly
Public community network. The Things Network is the best-known example. It is a shared, community-run LoRaWAN network. Anyone can put up a gateway and add it to the public coverage map, and anyone can register devices and use the network for free, within fair-use limits. The infrastructure belongs to whoever set up the nearest gateway, which might be you, might be a hobbyist three streets over, might be nobody at all.
Decentralized coverage network. Helium is the well-known case here. Gateway operators are paid through a token incentive to provide coverage, which is meant to grow the map faster than a pure-volunteer model. From the device side it still behaves like a public network: you do not own the gateways, and your traffic depends on coverage that other people choose to run.
Private network. You buy and place your own gateways, and you point them at a network server you control. That server is usually The Things Stack or ChirpStack. The coverage is yours, the uptime is yours to manage, and the data never crosses someone else’s infrastructure. You carry the hardware cost and the operations work in exchange.
What the network server actually does
Before the tradeoffs, one piece of vocabulary that trips people up. The LoRaWAN network server is the brain between your gateways and your data. It deduplicates packets that arrived through several gateways, checks the device’s security keys, handles join requests, manages data rates, and then forwards the decrypted payload onward.
The Things Stack and ChirpStack are both network servers. The difference between public and private LoRaWAN often comes down to who operates this server. On The Things Network, the community runs The Things Stack for you. On a private network, you run The Things Stack or ChirpStack yourself, on your own hardware or in your own cloud account.
This matters for the next section, and it matters a lot for the part about application platforms later.
The tradeoffs that decide it
Six factors separate the three models. No model wins on all six.
Coverage. Public and decentralized networks give you coverage you did not build, where it exists. In a dense city The Things Network or Helium might already reach your site. In a rural field, a basement, or a private industrial campus, that coverage is thin or absent, and you cannot make community gateways appear by wanting them. A private network gives you coverage exactly where you put a gateway and nowhere else.
Control. On a private network you set the channel plan, the gateway placement, the data-rate policy, and the upgrade schedule. On a public or decentralized network you take what is there. If a community gateway near you goes offline, that is not your gateway to fix.
Reliability. A gateway you own and monitor is a gateway you can hold accountable. Community and decentralized gateways can come and go without notice, because the people running them owe you nothing. For a hobby project that is fine. For a production site it is a risk you have to price in.
Security. LoRaWAN encrypts payloads end to end regardless of which model you use, so the radio link is not the worry. The difference is operational: on a private network your join servers, your keys, and your traffic stay inside infrastructure you control. For regulated work, that boundary is often the deciding factor on its own.
Cost. Public community networks cost nothing per message within fair use, which is hard to beat for small or early projects. Decentralized networks usually carry a per-packet or data-credit cost. A private network is the opposite shape: real money up front for gateways and setup, then near-zero cost per message after that. For a dense deployment with many devices on one site, the private model often wins on total cost over the device lifetime, even though it looks more expensive on day one.
SLA. This is the short one. Community and decentralized networks come with no service-level agreement. Nobody promises you uptime. A private network has whatever SLA you build and operate, which means you own both the promise and the work to keep it.
When each one fits
Start from the job, not the network.
Hobby, prototyping, and proof of concept. If you are testing whether LoRaWAN even fits your idea, join The Things Network. Free, fast to start, no hardware commitment if coverage already reaches you. Helium fits a similar early stage when you want broader coverage and accept a small per-packet cost. Do not stand up your own server to send a hundred test messages.
Production deployments. Once devices are in the field earning their keep, the calculus shifts toward control and reliability. Many teams move to a private network at this point, or at least to a paid, operated instance of The Things Stack, so that coverage and uptime are someone’s actual responsibility. Whether you self-host or use an operated network server, the goal is the same: no surprise gaps.
Regulated or remote sites. Healthcare, utilities, anything with data-residency rules, or any site with no community coverage at all. Here a private network is usually the only honest answer. You need the data boundary, the guaranteed coverage, or both, and a public map cannot give you either.
The line is not rigid. Plenty of real deployments mix models: a private network on the main campus, The Things Network for a satellite location that already has coverage. That is fine, and it leads directly to the next point.
The network server is not your application
Whichever model you choose, the network server moves and decrypts packets. That is all it does. It does not store history, draw a dashboard, alert an operator when a tank runs low, or trigger a pump. Those jobs live one layer up, at the application platform. This is where projects usually stall.
That is where TagoIO sits. TagoIO is a managed IoT application platform that runs above the network server. It ingests the decrypted data coming out of your LoRaWAN network, stores it, shows it in dashboards, manages your devices, and lets you build alerts, APIs, and automated actions on top.
Because TagoIO integrates downstream of the network server, the model you picked underneath does not lock you in. Running The Things Network? TagoIO pulls data from The Things Stack. Self-hosting ChirpStack on a private network? TagoIO connects to ChirpStack. Mixing both across sites? The application layer stays the same while the networks differ underneath. You can change or combine network models without rebuilding the dashboards and logic your team relies on.
For teams that need to resell or white-label the application to their own customers, TagoRUN provides that on the same platform. For edge processing close to the gateways, TagoCore is an open-source runtime that runs the application logic on site. The platform itself is ISO 27001 certified and GDPR-aligned, which tends to matter most to the same regulated teams that lean private on the network side.
The short version
There is no best LoRaWAN network model, only the right one for the job in front of you. Decide by coverage, control, reliability, security, cost, and SLA, weighted by what your project actually needs. Use The Things Network for hobby and prototyping, Helium when you want decentralized coverage and accept its cost, and a private network on The Things Stack or ChirpStack when you need control, guaranteed coverage, or a hard data boundary for production and regulated work.
Then pick the application layer that sits above all of it, so the data you worked to collect turns into something a person can see and act on. Get the network model right early. Like the radio choice before it, it is hard to undo once the sensors are in the field.
