A smart camera fleet rarely operates in a single environment type. The same product line might watch a retail floor over standard connectivity, monitor an outdoor perimeter on a bandwidth-constrained cellular link, and secure a government facility on an air-gapped network. One customer runs the supporting infrastructure on a Windows appliance, while another may run it on a Linux server. The hardware on the wall is identical, but everything else around it is not.
Deployment variability is not an edge case; it is a defining condition of IoT products at scale. Managing the complexity of today’s AI-enabled IoT products – across tens of thousands of devices, deployed across diverse networks and connectivity, and environments with strict security compliance requirements – poses a significant challenge for continued advancement. And, the infrastructure that delivers software to those products must meet each environment on its own terms, or it becomes a limiting factor in the product's and the company’s success.
Software update challenges in AI-Driven IoT products
Software updates are essential for all IoT products. But for AI-enabled IoT devices, software updates are the crux of continuous progress and creating business value. Despite their importance, for many IoT products, delivering a stream of software updates in a secure, robust, and continuous manner challenges existing infrastructure and ecosystem factors beyond what they can support.
Machine-agnostic capability drives competition. In the smart camera industry, where every customer site can be different, a machine-agnostic software update infrastructure isn't just an operational convenience; it directly protects R&D throughput and advances competition. Every hour an engineering team spends porting an update mechanism to a customer’s operating system or network appliance is an hour not spent on the camera capabilities that actually differentiate the product. When the same update infrastructure works across any environment a customer presents, OEMs can redistribute that engineering effort into features, and the addressable market widens to include sites a single-environment approach would rule out.
Highly secure and isolated environments are the standard in many arenas. Many of the most valuable places to deploy a smart camera are also the most restrictive. Government facilities, defense sites, and critical infrastructure routinely run on segregated or air-gapped networks, where devices cannot reach an external server either by location or design. In many sectors, isolation is the standard security posture.
Other customers may stay connected but rely on tightly constrained bandwidth, or operate under zero-trust policies that authenticate every device, connection, and update regardless of origin. An approach that assumes every device can reach an external server cannot address some of the most valuable use cases. Infrastructure that adapts to the environment makes the products it supports viable for these markets, expanding the total addressable market.
Fleet heterogeneity is the norm, not the exception. Real-world IoT deployments, like video monitoring systems, operate across a wide range of host environments. One site runs its network infrastructure on a Windows server; another relies on Linux; a third hands the integrator whatever general-purpose machine is available on-premise. Network policies, connectivity models, and security postures vary just as widely. The spread widens over time as customers expand into new locations where the infrastructure differs from that in the original deployment. The update mechanism must reliably accommodate the growing variance of environments. A software update infrastructure that can’t absorb variation forces either over-engineering on the customer side or under-serving legitimate operational needs.
Restrictive infrastructure requirements limit product value
When the update infrastructure is tied to a specific network model or use case assumption, every new customer environment becomes its own engineering project. Many enterprise and government deployments operate on segregated or air-gapped networks where IoT products cannot reach external update servers directly. Any update infrastructure must be able to operate in connectivity-constrained environments, either through on-premise proxying or local network relays.
Each environment that a machine-dependent approach cannot cover is either a deployment the product loses or a bespoke variant the team has to build, test, and maintain indefinitely. Both outcomes divert resources from the product and slow the pace of improvement.
The challenge grows over time. Even when infrastructure initially fits a customer's environment at initial deployment, the environment rarely stays the same. A site that starts with open internet access may move behind an air-gapped perimeter as security policies tighten. Cellular connectivity that was affordable for a modest fleet becomes prohibitively expensive as the deployment scales from hundreds to thousands of devices. A customer that initially operated a single site may expand into new regions with different compliance rules or bandwidth realities altogether.
Infrastructure built on a single assumption at the outset cannot absorb changing environments without significant rework or replacement. The result is constraints on a product’s update capability, and thereby, growth, forcing trade-offs between the pace of innovation and expansion and the cost of re-engineering how software reaches devices in the field.
Organizations need a future-proof update infrastructure that evolves alongside the business. The infrastructure must be flexible enough to accommodate access diversity, resilient to handle changes in connectivity and scale, and architected so that a changing environment does not require rebuilding from scratch. In this context, future-proofing is the essential consideration in implementing infrastructure that supports growth.
Machine-agnostic software update infrastructure future-proofs operations
The solution to address these challenges centers on a containerized software update mechanism for machine-agnostic deployment reach.
Machine-agnostic gateway via Docker
Mender Gateway is the component responsible for relaying update traffic between the Mender Server and the product fleet on a local network. Containerizing Mender Gateway using Docker is a seemingly simple decision with significant downstream benefits.
Docker abstraction means the gateway can run on Windows hosts, macOS developer machines, or arbitrary Linux servers present in the target network, without any platform-specific porting work. The same gateway container image, configured identically, can serve both a product fleet deployed behind a Windows-based network appliance at a retail site and a fleet behind a Linux server at a logistics hub. The customer’s environment dictates nothing about how the update mechanism is built or maintained.
Deploying the software update infrastructure in a machine-agnostic manner directly reduces the engineering overhead of supporting diverse customer environments.
Robust fleet management and security controls
At scale, the operational layer matters as much as the technical one. Enterprise fleet management capabilities enable dynamic device grouping, allowing segmentation by customer, site, firmware version, or any other custom attribute.
For air-gapped or segregated network environments, the Dockerized gateway operates as an on-premise relay. Devices on the segregated network connect to the gateway as if it were the update server. No special firewall exceptions or network redesign is required. The same infrastructure that updates a connected retail fleet updates an isolated government deployment, without a separate engineering effort for each.
Because the underlying infrastructure is consistent across environments, every deployment – connected, bandwidth-constrained, or fully air-gapped – utilizes the same set of robust update capabilities. A/B updates keep one known-good software version intact while the new version automatically installs to the second partition, ensuring automatic rollback if anything fails and eliminating the risk of a bricked device in the field. Delta updates transmit only the difference between the current and target software versions, a critical advantage for sites where bandwidth is limited or expensive. Phased rollouts allow updates to be deployed to a controlled subset of the fleet first, validating stability before wider release. None of these capabilities are reserved for the easiest deployments; they apply uniformly regardless of environment restrictions.
Endless possibilities with infrastructure flexibility
Traditional connectivity, bandwidth-constrained, and air-gapped environments are all accessible through a single approach — without bespoke builds or engineering hours diverted from the product itself. Purpose-built, future-proofed infrastructure results in a broader market reach, faster pace of improvement, and robust security posture that holds up wherever a device is deployed.
See how it works
To learn how to containerize Mender with Docker, check out Mender Gateway: OTA Updates for Segregated Networks.
