Cloud, On-Premises, and Embedded LoRaWAN® Network Servers

When building a LoRaWAN® network, one of the first decisions you’ll face is: where should your Network Server live? Should it run in the cloud, on your own servers, or right inside the gateway itself? The answer depends on your project’s size, security requirements, and operational model — and choosing the right architecture can make a big difference in how easy your network is to manage.

Before diving into the three options, let’s start with a quick definition.

What Is a LoRaWAN® Network Server?

A LoRaWAN® Network Server (LNS) is the core software system that manages a LoRaWAN® network. Think of it as the brain behind the operation. It connects gateways, sensors, and applications together — receiving messages from gateways, removing duplicate packets, verifying security keys, managing device sessions, controlling adaptive data rate, and forwarding data to customer applications, dashboards, databases, or APIs.

In simple terms: the gateway is the radio access point, while the Network Server is the brain of the LoRaWAN network.

There are three main ways to deploy a LoRaWAN® Network Server, and each has its own strengths:

• Cloud Network Server
• On-Premises Network Server
• Embedded Network Server

Let’s look at each one in detail.

Cloud LoRaWAN Network Server

A Cloud Network Server is hosted remotely — typically in a large data centre operated by providers like AWS, Azure, or Google. It is accessed over the internet and can be managed by the LoRaWAN network operator, the enterprise customer, or a service provider.

In this model, gateways connect securely to the cloud LNS over an internet backhaul such as Ethernet or cellular. There is no need to install or maintain server infrastructure locally.

When is Cloud LNS the right choice?

A cloud LNS is usually the best fit when you want a fast, highly scalable, dependable, and easy-to-manage deployment. It is commonly used for:

• Utilities and smart cities
• Environmental monitoring
• Asset tracking
• Country-wide or continent-wide enterprise deployments
• Managed IoT services
• Customers without large internal IT teams

Main benefits

The biggest advantage of a cloud LNS is simplicity and scalability. You can start small and grow over time without worrying about server hardware, database maintenance, backups, or software upgrades.

Cloud LNS is also ideal for distributed networks. If your gateways are spread across multiple cities or countries, they can all connect to one centralized platform — making network monitoring, device management, and troubleshooting much easier.

What to keep in mind

A cloud LNS requires reliable internet connectivity between the gateways and the cloud. Customers in government, defence, utilities, healthcare, or critical infrastructure may have stricter data security or sovereignty requirements and may prefer an on-premises deployment instead.

In a nutshell: Cloud LNS is the go-to choice for fast deployment, easy scaling, and centralized management with minimal IT overhead.

On-Premises LoRaWAN Network Server

An On-Premises Network Server is installed within the customer’s own IT environment — whether that is a private data centre, a secure server room, or a controlled enterprise infrastructure. In this model, the customer owns or controls the server environment, and gateways connect via the customer’s private network, VPN, or a secure connection.

When is On-Premises LNS the right choice?

On-premises is typically selected when stronger control over data, security, infrastructure, and system integration is required. It is commonly used for:

• Utilities, airports, ports, and railways
• Oil and gas sites
• Government and defence projects
• Public safety networks
• Healthcare systems
• Large industrial facilities
• Customers with strict cybersecurity or compliance policies

For example, an airport may prefer an on-premises LNS because it needs full control over its IoT network, data handling, cybersecurity policies, user access, and integration with internal operational systems.

Main benefits

The main benefit of on-premises deployment is control. You decide where the server is located, who has access, how data is stored, how backups are performed, and how the system connects to internal applications.

This architecture is also valuable when operational data must not leave the private network. In some industries, this is not just a preference — it is a regulatory or contractual requirement.

On-premises LNS can also provide secure integration with internal systems such as SCADA, BMS, GIS, asset management platforms, or enterprise databases.

What to keep in mind

On-premises deployment requires more IT involvement. The customer or system integrator must manage server resources, operating systems, cybersecurity, backups, upgrades, monitoring, and — if required — high availability. It is a powerful architecture but not always the fastest to deploy, and in most cases it requires more ongoing maintenance than a cloud-hosted solution.

In a nutshell: On-Premises LNS is the right choice when local control, data sovereignty, and private system integration are non-negotiable.

Embedded LoRaWAN Network Server

An Embedded Network Server runs directly inside the LoRaWAN gateway. Instead of connecting to an external cloud or on-premises server, the gateway itself has enough processing capacity, memory, and software intelligence to manage a local LoRaWAN network and forward data via MQTT, Modbus, or BACnet to PLCs, SCADA systems, or edge computers.

This architecture is unique because the gateway and the Network Server are combined into a single device. As a practical guide on scale: an embedded LNS can typically manage fewer than 500 devices if they send uplinks every 5 minutes, or fewer than 100 devices if they send uplinks every minute.

When is Embedded LNS the right choice?

Embedded LNS is best suited for small, local, or standalone deployments where simplicity and independence matter more than large-scale centralized management. It is commonly used for:

• Remote industrial sites
• Construction and agricultural sites
• Small buildings or isolated facilities
• Demonstrations and proof-of-concept deployments
• Locations with limited or unreliable internet connectivity
• Temporary deployments and trade show demos

For example, a remote pump station, warehouse, or farm may only need one gateway and a small number of sensors. An embedded LNS can collect sensor data locally and forward it directly to a PLC, SCADA system, or industrial computer — no cloud connection required.

Main benefits

The main benefit is simplicity. There is no separate server to install, host, or maintain. The gateway operates as a self-contained LoRaWAN network.

Embedded LNS is also particularly useful when internet connectivity is unavailable or unreliable — the local LoRaWAN network can continue operating independently, depending on the system design and application needs. It also reduces cost and complexity for small deployments where a full cloud or on-premises server would be unnecessary.

What to keep in mind

Embedded LNS is not designed for large or complex networks. It works best with one or a few gateways and a limited number of devices.

It also has limitations compared with cloud or on-premises platforms when it comes to advanced network management, redundancy, multi-gateway coordination, large-scale device provisioning, analytics, and enterprise integrations. Because each device’s credentials are stored only on one gateway, the device effectively loses connectivity if it moves outside that gateway’s coverage — meaning embedded LNS does not support mobility.

In a nutshell: Embedded LNS is perfect for small, local, or remote deployments where a standalone, self-contained operation is more important than large-scale management.

Quick Comparison

Not sure which model fits your project? Here is a side-by-side overview:

Architecture	Best For	Main Advantage	Main Limitation
Cloud LNS	Fast, scalable, multi-site deployments	Easy to deploy and manage	Requires internet connectivity and cloud acceptance
On-Premises LNS	Secure enterprise and critical infrastructure	Maximum control and data ownership	Requires IT resources and server management
Embedded LNS	Small, local, remote, or standalone networks	Simple and self-contained	Limited scalability and advanced management

How to Choose the Right LNS Architecture

The right LoRaWAN Network Server architecture depends on your business needs, security requirements, IT capabilities, network size, and operational model. Here is a simple guide:

Choose Cloud LNS when you want fast deployment, easy scaling, centralized management, and low IT overhead.

Choose On-Premises LNS when you need local control, strict cybersecurity, data sovereignty, private system integration, or operation within controlled enterprise infrastructure.

Choose Embedded LNS when the deployment is small, local, remote, or temporary — or when there is simply no justification for a separate cloud or on-premises server.

In many real-world projects, customers use more than one model. A large enterprise might use a cloud LNS for general building monitoring, an on-premises LNS for secure industrial operations, and an embedded LNS for small remote sites — all as part of the same overall solution.

The key point is that LoRaWAN is flexible. A well-designed solution should allow you to choose the deployment model that best fits your technical, commercial, and operational needs.

TEKTELIC Supports All Three Models

At TEKTELIC, we understand that not all IoT networks are built the same way. Some customers want simplicity. Some require full control. Others need a fully local, standalone operation. That is why our LoRaWAN platform supports cloud, on-premises, and embedded Network Server options — giving you the flexibility to deploy the right architecture for each project.

Whether you are building a smart city network, securing an industrial facility, or deploying sensors at a remote site, TEKTELIC has a solution that fits.

Want to learn more? Contact our team to discuss which architecture is right for your project: info@tektelic.com