LoRaWAN Network Server: Embedded, Self-Hosted or Managed

Last updated: 1 September 2026

In short: The network server is the piece of a LoRaWAN deployment nobody asks about at quote stage and everybody argues about later. It decides who holds your device keys, whether the site keeps working when the internet drops, and how painful it is to add a second gateway. There are three ways to run one, and they suit genuinely different sites.

Buyers compare gateways on channels, sensitivity and IP rating. Those matter, but two gateways with identical radio specs can behave completely differently in service, because the software deciding what happens to each packet sits in a different place.

This guide explains what a network server does, the three places it can live, and how to choose without painting yourself into a corner you only notice at gateway number four.

What does a LoRaWAN network server actually do?

It is the brain between your gateways and your data. The LoRa Alliance describes LoRaWAN as a star-of-stars topology, where gateways relay messages between end devices and a central network server, with the architecture comprising end devices, gateways, network servers and application servers.

Gateways are deliberately dumb. They receive a radio packet, add some metadata and forward it. They do not know which device it came from in any meaningful sense, and they do not decrypt anything.

The network server does the work that makes a pile of packets into a network. It authenticates each device, removes duplicates when several gateways hear the same transmission, manages adaptive data rate so devices use the lowest power that still works, schedules any downlink messages, and hands the payload on to your application.

Deduplication is worth dwelling on. If three gateways hear one sensor, you get three copies. Something has to know they are the same message, and that something is the network server. Run two independent ones over the same estate and you get duplicated data with no single view of it.

Where your device keys live, and why it matters

Every LoRaWAN device joins the network using cryptographic keys. Session keys are then derived for the traffic itself, and the LoRa Alliance describes the standard as secure by design with end to end security implemented across multiple levels.

The practical question is custody. Whoever operates the network server holds or brokers the keys that let your devices onto the network, which has three consequences worth thinking about before you commit.

• Exit cost. Moving to a different network server means every device rejoins. On six devices that is an afternoon. On six hundred, spread across a live estate, it is a project.
• Trust boundary. A hosted server means a third party is in the path of your device authentication. For most commercial sensing that is fine. For anything on a control network it needs a conversation with whoever owns that network.
• Continuity. If the keys only exist on one gateway and that gateway is stolen or bricked, you may be recommissioning devices rather than swapping hardware.

None of these are reasons to avoid any particular option. They are reasons to make the choice deliberately rather than inheriting whatever the first gateway shipped with.

Option one: the embedded network server on the gateway

Many industrial gateways run a network server on the gateway itself. The Milesight UG67 datasheet lists a built-in network server with MQTT and HTTP APIs, alongside BACnet/IP and Modbus so LoRaWAN data can reach a BMS or PLC directly, plus Node-RED and an embedded Python SDK.

This is the fastest route to working data and it has one genuinely important property: it keeps running with no internet at all. Sensor to gateway to Modbus register, entirely on site, with no cloud in the path.

For a single-gateway site that is often the correct answer and not a compromise. A standalone building, a remote compound, a factory where the control system is the destination anyway.

The limits appear when you grow. One embedded network server generally means one gateway’s worth of coverage, so a device that moves out of range of that gateway is simply gone, and there is no deduplication across sites. Adding a second gateway usually means promoting the whole estate to a central server rather than running two.

Option two: self-hosted, on your own infrastructure

Run open source network server software on your own server or a virtual machine you control. The UG67 datasheet confirms compatibility with mainstream network servers including The Things Stack, ChirpStack, Actility and AWS, so the gateway simply forwards to whichever you run.

You get everything the embedded option lacks. Many gateways in one logical network, proper deduplication, one device inventory, your own retention policy, and keys that never leave infrastructure you own.

The cost is operational, and it is easy to underestimate. Somebody patches it, backs it up, monitors it, and is available when it stops at 02:00. That is a real ongoing commitment rather than a one-off setup task.

Self-hosting suits organisations that already run infrastructure and have a reason to keep data in house, such as a utility, a university estate, or anyone with a security policy that makes a third party network server awkward.

Option three: a managed or public network server

Somebody else runs it and you point your gateways at it. No patching, no backups, no 02:00, and typically a per-device or per-message subscription.

The trade is control and cost shape. You are dependent on their availability and their roadmap, your keys are brokered by them, and a per-device fee that looks trivial at twenty devices is a meaningful annual line at two thousand.

It suits pilots, distributed estates with no central IT, and anyone whose priority is getting to useful data quickly. It suits proving a concept before committing to infrastructure.

Comparing the three

Notice what is not in that table: radio performance. Your network server choice does not change range, battery life or capacity. It changes ownership, resilience and running cost.

Getting the data out once it has been decoded

Decoding is only half the job. The payload has to reach whatever consumes it, and the integration route you pick is harder to change later than the hardware.

MQTT is the default and usually the right one. Devices publish to topics, anything can subscribe, and adding a second consumer later costs nothing. Pick a topic structure that encodes site and device identity rather than gateway identity, because gateways get replaced and sites do not.

HTTP webhooks suit low-rate data going to one destination. They are simple to debug and simple to outgrow, because every new consumer means another endpoint configured at source.

Direct to a control system via Modbus or BACnet skips the middle entirely. Sensor readings appear as registers or objects that a BMS or PLC already knows how to read, with no broker, no cloud and no integration code. On a building with an existing head end this is frequently the shortest honest path from sensor to screen.

The trap is coupling. If your dashboard reads directly from one box’s interface, that box is now load-bearing infrastructure, and replacing it means rebuilding everything downstream. Publish through a broker and the same swap is a reconfiguration.

Decide the payload format early too. A decoder that turns raw bytes into named, unit-tagged fields belongs in one place, applied once, not reimplemented in every dashboard that consumes the feed. Getting that wrong is how three teams end up disagreeing about what “level” means because each wrote their own decoder against the same bytes.

The migration path most sites should plan for

Start embedded, design for central. This is the pragmatic route and it costs nothing to keep open.

Run the first gateway on its built-in network server and get real data flowing in a day. Meanwhile do two things that make a later move cheap: keep a proper record of every device identifier and its keys in something that is not the gateway, and push data out over MQTT rather than wiring your application to a gateway-specific interface.

Do that and promoting to a central network server later is a configuration change plus a rejoin, rather than a rebuild. Skip it and you will discover at gateway number three that your dashboards are hard-wired to one box.

Whichever route you take, put the gateway somewhere it can be reached and powered properly. Our guide to off-grid monitoring power budgets covers the sites where that is the hard part.

Frequently asked questions

Do I need a network server for LoRaWAN?

Yes, always. It is not optional infrastructure. Without one a gateway is just a radio receiver with nothing to authenticate devices, remove duplicate packets or manage data rates.

Can I run two network servers over the same site?

You can, but you should not. Two of them over overlapping coverage means duplicated messages, split device inventories and adaptive data rate decisions made with half the picture.

What happens to an embedded network server if the internet drops?

It keeps working locally. Devices still join, uplinks are still received, and local outputs such as Modbus or BACnet keep updating. What stops is anything that has to reach the cloud, so buffer if the cloud is where the data has to end up.

How hard is it to move between network servers?

The server side is straightforward. The devices are the work, because each one has to rejoin. Keep your keys documented outside the gateway and it is manageable; do not and it becomes a site visit per device.

Does the choice affect battery life?

Indirectly. Adaptive data rate is a network server function, and a server that manages it well keeps devices transmitting at the lowest workable spreading factor, which is exactly what preserves battery. The radio hardware is identical either way.

The short version

Pick the network server for the shape of your estate, not for the shape of your first site. One building with a local control system is genuinely well served by an embedded server. Anything that will grow to several gateways needs a central one, and the cheapest time to plan that is before you have devices in the field.

For the hardware side of the same decision, our LoRaWAN gateway buyer’s guide covers which gateway to choose, and what LoRaWAN is covers the fundamentals underneath both.

The Milesight UG65 gateway ships with a built-in network server and is priced and in stock. Add it to a quote and we will come back within one working day.