IoT Infrastructure

On-Premises Deployment or Cloud Solution?

Designing an IoT system is not only about sensors and dashboards. The real engineering challenge begins when devices start transmitting data and we must decide where that data will live, how it will be processed, and who controls the infrastructure.

Before deciding on precisely which deployment type to use, it’s important to know what the word “infrastructure” actually includes. In general, an application’s infrastructure will include:

• Device connectivity (WiFi, BLE, LoRaWAN, OPC-UA, Modbus)
• Message broker (message queuing telemetry transport (MQTT))
• Device registry and authentication
• Data ingestion pipeline
• Storage (time-series database, object storage)
• Processing (rules engine, stream analytics, AI/ML)
• Visualization (dashboards including enterprise resource management (ERP), manufacturing execution system (MES), supervisory control and data acquisition (SCADA), customer relationship management (CRM), and others.

Whether we run this stack shown in Figure 1 locally or in the cloud, these components must exist somewhere. And the decision on the best location for each component will rest on a variety of factors that range from the technical to the purely business-oriented.

On-Premises IoT Deployment

In an on-premises IoT deployment, all system components run inside the organization’s local network, as shown in Figure 2. Network edge devices communicate with internal servers, data is processed locally, and dashboards are hosted on-site. The company maintains full control over infrastructure, performance, and security. The company also has full responsibility for acquiring, deploying, and maintaining all of the pieces that make up the infrastructure.

Typical Architecture

The implementation can be divided into back end and front end.

Back End—The back end handles data ingestion, processing, and storage. Devices publish telemetry to a locally hosted message broker (MQTT) [1]. A processing layer, such as Node-RED [2] or a custom service, parses payloads, applies rules, and generates alerts. Data is stored in a local database, often a time-series system [3] designed for telemetry.

All services typically run on an industrial PC or server using containerized applications [4]. This setup ensures low latency and independence from internet connectivity. An on-premises back-end also carries significant data privacy implications for the company, since no data leaves the company’s control or direct security coverage during normal process flow.

Front End—The front end provides dashboards and system monitoring tools. Visualization software runs on local infrastructure and is accessed through the internal network. Operators can monitor real-time data, historical trends, and alarms without relying on external services.

VPN for External Access—If remote access is required, a VPN should be used instead of exposing services directly to the internet [5]. A properly configured VPN encrypts traffic, limits access to authorized users, and protects critical infrastructure from external threats. In an on-premises IoT system, secure remote access depends on it.

Step-by-Step Example: Local MQTT + Time-Series Stack

Example Infrastructure Stack:

• Industrial PC (Intel i5/i7, 16–32GB RAM)
• Ubuntu Server LTS
• Docker / Docker Compose
• Mosquitto MQTT broker
• InfluxDB or PostgreSQL
• Node-RED or custom back end
• Grafana for dashboards

1. Install Docker

sudo apt update

sudo apt install docker.io docker-compose -y

2. Create docker-compose.yml

version: ‘3’

services:

mosquitto:

image: eclipse-mosquitto

ports:

– “1883:1883”

volumes:

– ./mosquitto.conf:/mosquitto/config/mosquitto.conf

influxdb:

image: influxdb:2

ports:

– “8086:8086”

grafana:

image: grafana/grafana

ports:

– “3000:3000”

3. Start Services

docker-compose up -d

• MQTT broker on port 1883
• InfluxDB on port 8086
• Grafana dashboard on port 3000

This is a production-capable baseline system. It’s important to note the limited number of hardware, software, and service components that make up this infrastructure stack. For many system designers, the decision of whether the infrastructure will be local or in the cloud will not rest on hardware requirements, but on the specific services needed, and whether those services are available for on-premises deployment.

When On-Premises Makes Sense

While there are many instances in which on-premises deployment may be the best choice, there are a handful of factors that can swing the decision arrow firmly in the direction of on-premises. These include:

Low-Latency Industrial Control—If PLCs or SCADA components are part of the overall design and there is a need for sub-100ms response times, local processing avoids the inherent latency of Internet round-trip times for data packets. Even with the best commercial network connections, there are aspects of physics that remain stubbornly unbeatable. Short trips are faster trips, all other things being equal.

Strict Data Control—Industries such as defense, energy, and pharmaceutical manufacturing often cannot transmit operational data outside their internal networks. Even if industry regulations don’t require positive control over data at all times, company policies, global geopolitics, and competitive considerations may provide justification for a local implementation.

Limited Internet Reliability—Remote mines, oil fields, or agricultural operations may have unstable connectivity. Even though satellite Internet connections have become more affordable and 5G cellular networks have become far more widespread, local processing ensures continued operation at dependable levels of performance and stability.

Cloud-Based IoT Deployment

Cloud IoT infrastructure, such as that shown in Figure 3, runs on services including:

• AWS IoT Core [6]
• Microsoft Azure IoT Hub [7]
• Managed platforms such as ThingsBoard Cloud [8] or The Things Network [9]

In a cloud-based IoT deployment, all back end and front end services are hosted in the cloud rather than inside the local network. Devices and gateways send data over the Internet to a remote IoT platform, where processing, storage, and visualization occur, with results sent back to the local network for action or display.

The local infrastructure is reduced to devices and possibly gateways, while compute, storage, and visualization are centralized remotely. This simplifies deployment and scaling but makes system operation dependent on internet connectivity and cloud service availability.

Hands-On Example: AWS IoT Core

These are the core actions required to bring a device online and send secure telemetry with AWS IoT Core:

• Log in to the AWS Console: Create a “Thing”
• Generate and Attach Certificates
• Create and Attach an IoT Policy
• Configure the Device MQTT Client: On the device (Linux gateway, SBC, or industrial PC), configure an MQTT client using TLS
• Route Data to Storage

One of the notable factors of the cloud deployment is just how simple the process can be. Cloud providers have, in general, gone out of their way to make the “getting started” process very easy. It’s important to note, though, that there can be a substantial gap between “functional cloud deployment” and “optimal cloud deployment.” The good news is that most cloud back-end components are very inexpensive at the level required to learn the settings and processes that separate functional from optimal. It can be a small investment worth making well before a production cloud deployment is required.

When Cloud Makes Sense

As with on-premises deployments, there can be many factors that make the case for infrastructure in the cloud. Some factors, though, point more urgently than others. Among the factors that weigh heavily on the cloud side of the scale are:

Rapid Scaling—Adding 10 devices or 10,000 devices uses the same back end. Scaling is automatic.

Global Access—Remote teams can access dashboards without VPN configuration.

Built-In AI/Analytics—Cloud providers offer managed ML pipelines, stream processing, anomaly detection and serverless functions

When you add to these qualities that include the ease with which new configurations can be designed and tested, it’s no wonder that cloud IoT infrastructure is becoming a more accepted first-choice option for many embedded computing designers and engineers.

The Cloud Perspective

There is no universal answer to the question of whether an IoT system should be deployed on-premises or in the cloud. The right choice depends on the technical requirements of the project and, just as important, on the company’s IT policies.

In many deployments, the first constraint is the existing network infrastructure. Some IT departments prefer to keep all operational data inside the corporate network and are willing to provide virtual machines or physical servers for an on-premises solution. Others are comfortable using cloud platforms and value the scalability, availability, and reduced maintenance they offer.

Data security is often the central concern in this decision. Questions about where data is stored, who has access to it, and how it is protected must be addressed early in the project. In highly regulated industries, these requirements can determine the architecture before development even begins.

In other words, (and this must be emphasized): Successful IoT projects are not built around a preferred platform. They are built around the realities of the customer’s IT environment.

RESOURCES
AWS IoT Core | aws.amazon.com/free/iot
Microsoft Azure IoT Hub | azure.microsoft.com/en-us/products/iot-hub
Node-RED | nodered.org
ThingsBoard Cloud | thingsboard.cloud
The Things Network | www.thethingsnetwork.org

REFERENCES
[1] mqtt.org
[2] https://nodered.org
[3] https://www.influxdata.com/time-series-database/
[4] https://aws.amazon.com/what-is/containerization/
[5] https://en.wikipedia.org/wiki/Virtual_private_network
[6] https://aws.amazon.com/free/iot/
[7] https://azure.microsoft.com/en-us/products/iot-hub
[8] https://thingsboard.cloud
[9] https://www.thethingsnetwork.org

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • JULY 2026 #432 – Get a PDF of the issue

Sponsor this Article