This engagement was for Aceso Analytics AI and its healthcare clients. The requirement was a production-grade LoRaWAN network server, hosted on-premises, integrated with Kubernetes, and configured so that adding a new gateway or IoT application was a plug-and-play operation rather than a manual setup every time.
The requirement
Aceso Analytics AI builds AI-driven analytics products for healthcare. Their IoT layer depends on LoRaWAN: a low-power wide-area network protocol that connects the physical sensors and gateways in a healthcare environment to the data infrastructure behind the scenes.
The specific requirement was a self-hosted The Things Stack deployment on Kubernetes. The Things Stack is the leading open-source LoRaWAN network server. Running it on-premises on Kubernetes rather than using a managed cloud service was a deliberate data sovereignty decision: patient-adjacent IoT data from healthcare environments stays on infrastructure the client controls, not on a shared cloud instance.
The second requirement was operability. Adding a new gateway to the network or onboarding a new IoT application should not require deep LoRaWAN expertise each time. The deployment had to be configured so that both were plug-and-play operations.
| Requirement | Why it mattered |
|---|---|
| On-premises hosting | Healthcare data sovereignty, patient-adjacent sensor data cannot leave controlled infrastructure |
| Kubernetes deployment | Cluster management, automated restarts, resource isolation, consistent operations |
| LoRaWAN Things Stack | Production-grade network server for gateway management and IoT application routing |
| Plug-and-play gateway onboarding | Healthcare environments add gateways as facilities expand; manual setup at each site is not sustainable |
| IoT application integration | Multiple downstream analytics applications consuming sensor data through a single network server |
The deployment
The Things Stack was deployed as a production Kubernetes workload: Helm-managed, with proper resource requests and limits, persistent storage for the network server database, and service configuration that exposed the correct ports for LoRaWAN packet forwarding, the application API, and the management console.
The Kubernetes layer provided what a bare-metal or VM deployment of Things Stack would not: automatic pod restarts on failure, resource isolation from other workloads on the cluster, rolling updates for version upgrades, and a consistent deployment model that the operations team could reason about without needing to understand LoRaWAN internals.
Gateway onboarding was configured so that a new LoRaWAN gateway could be registered and operational without touching the server configuration. The gateway connects to the Things Stack instance using standard LoRaWAN packet forwarder configuration, authenticates against the pre-configured gateway server endpoint, and begins routing packets immediately. The IoT applications consuming that data are registered in Things Stack and receive uplinks through the application server without changes to the underlying Kubernetes deployment.
| Component | Configuration | Purpose |
|---|---|---|
| Things Stack | Helm deployment on Kubernetes, persistent DB | LoRaWAN network server: gateway management, device registry, application routing |
| Gateway server | Pre-configured endpoint, standard packet forwarder | Accepts connections from any LoRaWAN gateway without per-gateway server config |
| Application server | Registered IoT application integrations | Routes sensor data to Aceso Analytics AI and downstream healthcare applications |
| Identity server | Built-in Things Stack identity management | User and API key management for gateway operators and application developers |
| PostgreSQL | Persistent cluster storage | Network server state, device registry, application data |
| Kubernetes workload | Helm-managed, resource-limited pods | Automatic recovery, rolling updates, resource isolation |
The data sovereignty layer
Running Things Stack on-premises on Kubernetes rather than on a managed LoRaWAN service is a meaningful architectural choice, not just a preference. Healthcare IoT data, even at the sensor and gateway level, carries enough sensitivity that the network server itself is part of the compliance boundary.
A managed cloud LoRaWAN service routes all device uplinks through shared infrastructure. That means packet metadata, device identifiers, and application payloads transit a third-party system. For healthcare applications where the downstream data is patient-adjacent, on-premises hosting keeps the full data path inside controlled infrastructure.
The Kubernetes deployment on the client's own hardware meant that all Things Stack components ran on infrastructure the client owned, all data persisted to their own storage, and all traffic between gateways and applications stayed within their network boundary.
Challenges
Things Stack database initialisation on Kubernetes. Things Stack has a specific initialisation sequence for its internal databases. Getting this sequence to run correctly inside Kubernetes init containers, with the right dependency ordering between the identity server, network server, and application server pods, required careful Helm chart configuration and testing. A misconfigured init sequence produces a cluster that appears healthy but cannot register devices or route packets.
LoRaWAN frequency plan configuration for the healthcare environment. LoRaWAN frequency plans vary by region and by gateway hardware. Configuring Things Stack with the correct frequency plan for the gateways in the healthcare environment, and validating that the packet forwarder configuration on the gateways matched the server-side expectations, required hands-on testing with the actual hardware.
Persistent storage for Things Stack on Kubernetes. Things Stack maintains critical state in its PostgreSQL database including the device registry and session keys. Configuring this with appropriate persistent volume claims, backup strategy, and storage class selection for the on-premises cluster was a non-trivial infrastructure decision with direct implications for disaster recovery.
Results
| Metric | Outcome |
|---|---|
| Deployment type | Production-grade Kubernetes on-premises |
| Data sovereignty | All LoRaWAN traffic and device data on client-controlled infrastructure |
| Gateway onboarding | Plug-and-play: new gateways connect and operate without server-side changes |
| IoT application integration | Multiple healthcare analytics applications consuming sensor data through Things Stack |
| Cluster operations | Kubernetes-managed: automatic recovery, rolling updates, resource isolation |
| Compliance posture | Patient-adjacent IoT data path fully within controlled infrastructure boundary |
What changed for the operations team
Before this deployment, adding a gateway to the IoT network meant manual server configuration, documented procedures that required LoRaWAN knowledge to execute, and a person who understood both the hardware and the network server to complete the setup. With Things Stack on Kubernetes, a gateway operator registers the device through the Things Stack console and points the gateway's packet forwarder at the server endpoint. The network server handles the rest.
The Aceso Analytics AI team can expand their sensor network into new healthcare facilities without the IoT infrastructure becoming a bottleneck. The analytics applications consuming the data connect through stable Things Stack application server endpoints that do not change as the gateway network grows.
For on-premises Kubernetes deployments with data sovereignty requirements in regulated industries, see our InfraOps service.
If you are running IoT infrastructure in a healthcare or regulated environment and need on-premises Kubernetes that your team can actually operate, book a free 30-minute call.