KubeSolo, Docker, or Podman runtimes across single nodes, small clusters, and tiered topologies, all deployed, updated, and governed centrally through Portainer and the Industrial App Portal.
Industrial IoT, IoMT, automotive IoT and smart infrastructure deployments share a common operational pattern, which is a large number of physically distributed devices, each running one or more containerized applications, that must be deployed, updated, configured, monitored and secured consistently, without on-site technical staff at most locations, often with intermittent or bandwidth-constrained connectivity, and with an application update cadence that is not friendly to manual per-device management.
The scale varies enormously and the structure does not. A connected vehicle platform might manage software on a hundred thousand or more in-vehicle compute units; a drone operations platform might manage containerized navigation, telemetry and payload processing across a fleet of hundreds of UAVs that each need mission-critical updates when the vehicle is in range; a pharmaceutical manufacturer might manage containerized monitoring and control applications on a few hundred bioreactors and packaging lines across 20 global plants; a hospital network might manage IoMT gateway devices at 50 sites; and a smart grid operator might have containerized edge analytics running at thousands of substations. In each case the requirement is consistent deployment, reliable updates, and centralized visibility across a fleet that cannot be managed device by device.
Device diversity adds the second dimension, because edge hardware is not homogeneous; the same fleet might contain x86 devices running Docker on full Linux, ARM-based embedded systems running Podman, and compute-capable devices at higher-value sites running KubeSolo. The topology is not always flat either, since many IoMT, industrial and smart infrastructure deployments use a tiered architecture where single-node devices closest to the data source feed into small three-node clusters that aggregate and forward upstream, and Portainer manages every tier from the same management plane with each node and cluster visible as a distinct environment in the fleet view.
The hardest part of industrial IoT at scale is not connecting devices; it is keeping them consistently operational over time. Initial deployment is a solved problem with enough manual effort, and keeping ten thousand devices updated, compliant and healthy without manual effort per device is not.
Portainer manages all three container runtimes from a single interface, so the choice of runtime is driven by device capability, existing operational standards, and application requirements rather than by the management tooling.
Portainer's single-command Kubernetes distribution for GPU-enabled and higher-capability edge devices; it installs in minutes, exposes GPU resources automatically, and connects to the central Portainer instance via outbound agent. The natural choice for vision inferencing, AI workloads, and any application that benefits from Kubernetes-native resource management.
The dominant runtime on x86 and ARM edge devices where KubeSolo is not required, with Docker Compose stacks managed through Portainer and full container lifecycle, volume, network and log access. Most industrial IoT ISV applications are packaged as Docker Compose stacks.
Preferred where a persistent Docker daemon is a security concern, or where rootless container execution is required; Portainer manages Podman environments with identical tooling to Docker, including Compose stack deployment. Other Kubernetes distributions are also supported where organizational standards require them.
Steps three through five below describe delivery through the Industrial App Portal, which is in development and not yet generally available; the agent installation, edge group targeting and fleet health steps are shipping capability in Portainer Business Edition today, and applications can be deployed to edge groups as Docker Compose stacks or Helm charts without the portal in the meantime.
On Docker or Podman devices the Portainer agent deploys as a container with a single run command configured with the central server address, and on KubeSolo devices it deploys via Helm. The agent establishes an outbound connection to the Portainer server, so no inbound firewall rules are needed at the edge site, and the device appears in the fleet view within seconds of agent startup with its runtime type, hardware details and running containers visible.
Edge groups define which applications deploy to which devices, so a device assigned to a line monitoring group automatically receives every application assigned to that group, both at first assignment and when new applications or updates are published later. Groups can be defined by geography, hardware type, customer, function or any combination, and a single device can belong to multiple groups.
ISVs or the enterprise IT team publish containerized applications to the Industrial App Portal catalog as Docker Compose stacks for Docker and Podman devices, or Helm charts for KubeSolo devices, with versioned configuration covering resource requirements, environment variable definitions, volume mounts and network configuration.
Portainer distributes the deployment instruction to all agents in the group simultaneously, or in batches for staged rollouts; each agent pulls the required images from the configured registry, which may be a self-hosted registry such as Harbor or a public registry with credentials, starts the containers, and reports status back to the server so progress is visible across the fleet in real time.
An updated version is published to the catalog and the operations team configures the rollout as an immediate push, a sequenced rollout by group, or a percentage-based rollout with health checks between batches; devices that were offline at publication receive the update automatically on reconnection, and the entire update history is recorded in the audit trail covering which devices were updated, when, by whom, with what version, and with what outcome.
The fleet dashboard shows online and offline state, container status, last check-in time and current application versions for every device, and filtering by group, hardware type or application version surfaces anomalies quickly. For a device with a failed container, the operations team can access logs, restart containers, or push a configuration change from the Portainer interface without physical access to the device or an SSH session.
Not all fleet deployments are flat, and a single Portainer instance manages single-node devices, small high-availability clusters, and multi-tier architectures simultaneously, with each appearing as a distinct environment in the fleet view and each receiving the same centralized deployment, update and governance capabilities.
The tiered pattern is easiest to describe in a hospital, where a single-node device at the bedside collects and normalizes patient data locally to reduce transmission latency and remove the dependency on network availability for time-sensitive readings, feeding a three-node floor cluster that provides resilience and handles aggregation, deduplication and upstream forwarding to the EHR or clinical data platform; if the bedside node is unavailable the patient device communicates directly with the floor cluster, and Portainer manages both tiers from one management plane with biomedical engineering teams scoped to their floor's environments and strict change control on any application touching clinical data.
The same pattern applies beyond healthcare. In industrial environments, machine-level single nodes read from PLCs and run local analytics, feeding zone-level three-node clusters that aggregate to a plant historian; in smart grid deployments, substation RTUs run single-node containerized edge analytics feeding district-level aggregation clusters. In each case edge groups in the Industrial App Portal map to the topology, so device-proximate nodes sit in one group and aggregation clusters in another, each receiving appropriately targeted application versions and update policies.
Containerized in-vehicle applications across populations from tens of thousands upward, partitioned across instances where the population exceeds the 150,000 devices a single instance manages, with over-the-air delivery that lands when the vehicle is in range and offline resilience in between.
Containerized OPC-UA analytics on hundreds or thousands of industrial PCs and edge servers, reading from PLCs, running local analytics, and feeding plant historians or cloud platforms.
Tiered gateway architectures handling HL7, FHIR and proprietary device protocol translation at the bedside, aggregating through floor clusters into the clinical data platform.
Edge analytics at substations, water treatment facilities and smart meter aggregation points, where sites are unstaffed and WAN connectivity is limited, so updates cannot depend on a site visit.
These are industry scenarios illustrating where the architecture applies. They are not Portainer customer references.
Most organizations at this scale already have fleet management tooling in place, whether AWS Greengrass, Azure IoT Edge, or a home-grown platform built around MQTT, Ansible, or a bespoke provisioning pipeline, and the problem is not that those tools fail outright; it is that they were designed around the device management and telemetry problems of the last decade rather than around a fleet where every device runs one or more containerized applications that need to be deployed, updated, rolled back and governed like software, because that is what they are. Greengrass works well inside the AWS ecosystem, and it becomes a constraint the moment an ISV ships a Helm chart, the fleet includes KubeSolo nodes alongside Docker hosts, or the operations team needs to manage a tiered topology from one interface. Home-grown tooling has no proven track record at scale and no roadmap, so every edge case becomes an engineering project.
Most IoT management platforms specialize in one runtime. Portainer manages Docker Compose stacks, Podman environments, and Kubernetes through KubeSolo or a full distribution with identical tooling from the same interface, which matters because a mixed-runtime fleet is the reality in most large industrial deployments.
Operations teams managing industrial fleets are not Docker experts, so the Industrial App Portal abstracts runtime detail behind a catalog-and-deploy model; the ISV publishes the application and the operations team deploys it, with configuration complexity living in the catalog entry.
The edge agent buffers state locally, continues running its workloads regardless of connectivity, and syncs when connectivity is restored, with queued instructions delivered on reconnection. This is the baseline behavior rather than a contingency mode.
Large deployments span multiple plants, customers or regions with their own operations teams, so access policies mirror that structure; a plant team sees its own devices, a customer administrator sees only that customer's fleet, and an ISV support team gets read-only log access without access to infrastructure configuration.
KubeSolo, which is preferred for GPU-capable or higher-capability devices, plus Docker and Podman. All three are managed from the same interface with the same deployment and monitoring tooling; Docker Compose stacks deploy to Docker and Podman environments, and Helm charts deploy to KubeSolo. A mixed fleet containing all three runtime types is managed from a single Portainer instance.
The edge agent buffers state locally and continues running workloads regardless of WAN connectivity, and update instructions queued while a device is offline are delivered on reconnection with no manual intervention required at the device.
Yes. Edge groups define which applications deploy to which devices, and groups can be defined by geography, hardware type, customer, runtime or any combination, with a single device able to belong to multiple groups. One instance manages devices across any number of sites and customer boundaries, with RBAC isolating each view.
Portainer manages up to 150,000 edge devices from a single instance, and the architecture has been deployed in automotive programs, drone fleets, and industrial deployments spanning multiple continents. Fleets larger than that are partitioned across instances rather than accommodated by scaling one up. Below the ceiling, the practical constraint tends to be the connectivity and compute profile of the edge devices rather than the management capacity of the control plane, so sizing for a specific fleet shape should still be validated with a solutions engineer.
Start free with up to 3 nodes, or talk to our industrial team about your OT deployment.
