Air-gapped / fully offline operation
Industrial & IoT · Platform Comparison
OT edge does not run on IT assumptions.
The platform has to match the environment.
Factory floors, remote substations, and distributed device fleets operate under constraints that mainstream container management tools were never designed for: intermittent connectivity, air-gapped networks, constrained hardware, ISA-95 security boundaries, and operations teams who are not Kubernetes engineers. This page covers how the options available in the market actually perform against those constraints.
Connectivity
OT environments are often air-gapped, intermittently connected, or isolated by security zone. Any management plane that assumes persistent uplinks will fail in the field.
Operational ownership
Deployments are managed by OT engineers or IT generalists, not Kubernetes specialists. Platforms requiring YAML fluency or cluster expertise create a staffing dependency that doesn't exist on site.
Governance and audit
Industrial deployments carry regulatory obligations. What is running, who changed it, and when it changed must be auditable from a central point — across every site, regardless of connectivity state.
Operating models
Cloud-connected device management vs. autonomous edge governance
Cloud-Connected Device Management (Azure IoT Edge, AWS Greengrass, Balena)
Designed for managed device fleets with reliable uplinks to a cloud control plane. Deployment and update workflows depend on cloud connectivity. Purpose-built for IoT device management scenarios with device twins, telemetry pipelines, and cloud-native toolchains.
+
Strong cloud-native integration for telemetry and device state
+
Managed update pipelines for device fleets
+
Familiar toolchain for cloud-native teams
-
Requires persistent or periodic cloud connectivity to operate
-
Air-gapped and OT-isolated networks are fundamentally unsupported
-
Cloud vendor lock-in: governance model, pricing, and data residency all tied to one provider
-
Not designed for multi-site fleet governance with RBAC, policy propagation, or auditability
Autonomous Edge Governance (Portainer)
Designed for environments where connectivity cannot be assumed. An async edge agent operates independently, buffers instructions, and syncs when connectivity allows. Central governance — identity, policy, deployment, audit — operates at fleet scale without requiring a persistent uplink from any individual site.
+
Async agent: sites operate independently, sync when connected
+
Air-gapped and ISA-95 zone-isolated operation by design
+
Fleet-wide policy propagation and RBAC from a single control plane
+
Full audit trail regardless of connectivity state at time of change
+
Self-hosted, no cloud vendor dependency, no data residency risk
+
Operable by OT engineers and IT generalists, no Kubernetes expertise required
+
Runtime-agnostic: Docker, Podman, and Kubernetes
Platform landscape
How each platform fits industrial and OT deployments
These are structural observations, not value judgments. Each platform was designed for a different operating context.
Azure IoT Edge
Microsoft cloud-connected edge runtime
Azure IoT Edge deploys containerized modules to edge devices and manages them via the Azure IoT Hub control plane. Strong integration with the Azure ecosystem, device twin state management, and cloud-native telemetry pipelines. The governance model is fundamentally cloud-dependent: deployments, updates, and monitoring all flow through Azure connectivity.
+
Deep Azure ecosystem integration
+
Device twins, telemetry routing, and cloud-native monitoring
+
Familiar for organizations already standardized on Microsoft
-
Requires Azure connectivity — air-gapped and ISA-95 isolated environments are not supported
-
No multi-site RBAC, policy propagation, or centralized identity management independent of Azure
-
Hard lock-in to Azure licensing, data residency, and pricing changes
-
Not designed for Kubernetes workloads or multi-runtime environments
AWS IoT Greengrass
Amazon cloud-connected edge runtime
AWS Greengrass extends AWS Lambda and container execution to edge devices, with device management and deployment orchestrated through AWS IoT Core. Suited for organizations deeply invested in the AWS toolchain. Governance, fleet management, and audit all route through AWS, which creates the same connectivity dependency as Azure IoT Edge.
+
Native AWS integration, Lambda at the edge, Greengrass components
+
Strong device fleet management within the AWS ecosystem
-
Air-gapped and OT-isolated environments are fundamentally outside the design scope
-
No RBAC model designed for multi-site industrial governance
-
AWS vendor lock-in: licensing, data residency, and regional availability all AWS-dependent
-
Complex pricing model; costs scale unpredictably with fleet size and data volume
Balena
IoT device fleet management, SaaS-delivered
Balena provides container-based device fleet management through a SaaS control plane (balenaCloud). Strong focus on developer experience, delta updates, and device lifecycle. Well-suited for connected IoT product companies managing device fleets. The SaaS delivery model and cloud routing architecture create data residency and connectivity constraints that are difficult to accommodate in regulated OT environments.
+
Good developer experience for connected IoT fleets
+
Delta update efficiency and device lifecycle tooling
+
Open-source components available (openBalena) for self-hosted deployment
-
SaaS-first model; self-hosted openBalena is significantly less capable and unsupported
-
No enterprise RBAC, policy propagation, or identity integration
-
Not designed for regulated OT environments or ISA-95 network segmentation
-
Audit and governance capabilities are limited compared to enterprise requirements
k3s / MicroK8s / Bare Kubernetes
Lightweight Kubernetes distributions, self-managed
Lightweight Kubernetes distributions like k3s and MicroK8s reduce the hardware requirements for running Kubernetes at the edge. They solve the resource constraint problem but not the governance problem. Running k3s on 50 factory nodes gives you 50 independent Kubernetes clusters to manage, update, audit, and govern individually. The distribution is lightweight; the operational model is not.
+
Low resource footprint, suitable for constrained hardware
+
Full Kubernetes API compatibility
+
Open source, no licensing cost for the distribution itself
-
No centralized governance, RBAC, or policy across the fleet
-
Each node or cluster requires individual management — operational burden scales with fleet size
-
Requires Kubernetes expertise that OT teams typically do not have
-
Audit and change tracking must be built custom on top
-
Air-gap and update workflows require additional tooling (Flux, Argo, custom scripts)
Ansible / Puppet / Chef for Containers
Configuration management extended to containerized workloads
Many OT and industrial IT teams already operate configuration management tooling and attempt to extend it to container workloads. This works for simple, uniform deployments but does not provide centralized container governance, RBAC, GitOps-based deployment standardization, or the real-time operational visibility that container fleets require. Configuration management and a container control plane solve different problems.
+
Reuses existing operational tooling and team skills
+
Works well for configuration drift enforcement on homogeneous fleets
-
Not designed for container lifecycle management, GitOps, or deployment promotion
-
No native container RBAC, registry management, or runtime visibility
-
No audit trail of container-level changes (image updates, restarts, rollbacks)
-
Does not scale to multi-runtime environments (Docker + Kubernetes mixed fleets)
Portainer Edge
Operator control plane designed for OT and distributed edge
Portainer Edge governs Docker, Podman, and Kubernetes at the edge from a single self-hosted control plane. The async edge agent operates independently at each site, buffers pending instructions, and syncs when connectivity allows — meaning an air-gapped site or a site experiencing a network outage continues to run and will reconcile when the link restores. Governance — identity, policy, deployment, audit — is maintained centrally regardless of individual site connectivity.
+
Async edge agent: runs independently, syncs when connected, never blocks on uplink
+
Native air-gap support: registry mirroring, offline image distribution
+
ISA-95 zone-compatible: no inbound firewall rules required from OT network
+
Fleet-wide policy propagation and RBAC from a single control plane
+
Full audit trail: every change, every site, centrally logged and queryable
+
Self-hosted by design: no cloud dependency, no data residency risk
+
FIPS-140-3 compliant operation for regulated environments
+
Operable by OT engineers and IT generalists, no Kubernetes expertise required
+
Runtime-agnostic: Docker, Podman, and Kubernetes in a single fleet view
+
Staged rollout controls: deploy to one site, validate, then propagate fleet-wide
Feature matrix
Operational comparison for industrial and OT environments
Scroll horizontally on smaller screens. Columns hidden at narrow widths prioritize Portainer and Azure IoT Edge.
Capability
Portainer Edge
Azure IoT Edge
AWS Greengrass
Balena
k3s / MicroK8s
Connectivity and Air-Gap
Native async agent
Not supported
Not supported
Not supported (SaaS)
Possible, no management plane
Intermittent connectivity resilience
Buffers + syncs on reconnect
Limited, queued commands
Partial
Partial, local agent caching
Workloads run; no management sync
ISA-95 OT network zone compatible
No inbound rules required
Requires outbound to Azure
Requires outbound to AWS
Requires outbound to cloud
Workloads only, no governance
Offline registry / image distribution
Built-in registry mirroring
Partial, manual setup
Partial
Delta updates, cloud-routed
Manual, additional tooling
Self-hosted, no cloud vendor dependency
Always self-hosted
Requires Azure
Requires AWS
openBalena (limited)
Yes
Governance, Identity, and Audit
Centralised RBAC across all sites
Full fleet RBAC
Azure AD-bound, limited fleet RBAC
IAM-bound, per-device scoping
No enterprise RBAC
Per-cluster only, manual
AD / LDAP / OIDC SSO
Native integration
Via Azure AD only
Via AWS IAM only
Not available
Custom integration required
Audit log: who changed what and when
Full action audit, all sites
Azure Monitor, partial
CloudWatch, partial
Limited
Custom build required
Fleet-wide policy propagation
Centralized policy enforcement
Deployment manifests only
Component recipes only
Not available
Per-cluster manual
FIPS-140-3 compliant mode
Native
Not confirmed
Not confirmed
Not available
Not available
Deployment and Operations
Staged rollout (site-by-site deployment control)
Built-in staged groups
Deployment rings, limited
Deployment groups, limited
Release pins, limited
Manual, no native staged rollout
GitOps-based deployment
Centralized GitOps execution
Via Azure DevOps integration
Via AWS CodePipeline
Not natively
Cluster-local (Flux / Argo)
Docker and Podman support
Native, full lifecycle
Docker modules
Docker containers
Docker-based
Not designed for Docker
Kubernetes at the edge (lightweight)
k3s + KubeSolo supported
AKS Edge Essentials (limited)
EKS Anywhere (heavy)
No Kubernetes support
Full Kubernetes API
Requires specialist Kubernetes skills to operate?
No, operable by OT/IT generalists
Cloud skills required
AWS skills required
Moderate, developer-oriented
Yes, Kubernetes expertise required
Cost and Deployment Model
Free tier available
Yes, up to 3 nodes
Limited free messages / month
Limited free tier
Free up to limited devices
Open source, free
Pricing model clarity
Transparent per-node
Complex message/operation-based
Complex, message + device + data
Per-device SaaS
No licensing cost
Data residency control
Full control, self-hosted
Azure region-dependent
AWS region-dependent
Balena cloud-routed
Full control
Looking for Enterprise IT?
Portainer vs OpenShift, Rancher, NKP, Tanzu, and DIY stacks
For enterprise IT teams evaluating Kubernetes management platforms, the comparison set is different. See how Portainer sits against the mainstream enterprise platforms.
Enterprise IT comparison
Ready to govern your industrial edge?
Start free with up to 3 nodes, or talk to our industrial team about your OT deployment.