For the Kubernetes management platform, visit portainer.io · For AI solutions, visit portainer.ai
Platform comparison

Every platform here works somewhere. The question is whether it works where you operate.

Azure IoT Edge, AWS Greengrass, Balena and lightweight Kubernetes were each designed well for the context they came from, and none of those contexts is an air-gapped plant or an unstaffed substation. This page sets out where each one holds up against OT constraints and where it stops.

Operating models

Cloud-connected device management, or autonomous edge governance.

The distinction that matters is not the feature list; it is whether the governance model assumes an uplink. A platform that routes deployment and update workflows through a cloud control plane is structurally unable to govern an air-gapped site, and no amount of feature parity changes that, so the comparison starts with the operating model rather than the capability matrix.

Azure IoT Edge, AWS Greengrass, Balena
Cloud-connected device management

Designed for managed device fleets with reliable uplinks to a cloud control plane, where deployment and update workflows depend on cloud connectivity.

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
Governance model, pricing and data residency tied to one provider
Not designed for multi-site fleet governance with RBAC, policy propagation or auditability
Portainer
Autonomous edge governance

Designed for environments where connectivity cannot be assumed, so an async edge agent operates independently, buffers instructions, and syncs when connectivity allows.

Async agent, so sites operate independently and 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 the time of change
Self-hosted, with no cloud vendor dependency and no data residency risk
Operable by OT engineers and IT generalists, with no Kubernetes expertise required
Runtime-agnostic across Docker, Podman and Kubernetes
Platform landscape

How each platform fits industrial and OT deployments.

These are structural observations rather than value judgments, because each platform was designed for a different operating context and performs well inside it.

Azure IoT Edge

Deploys containerized modules to edge devices and manages them through the Azure IoT Hub control plane, with strong Azure ecosystem integration, device twin state management, and cloud-native telemetry pipelines. The governance model is fundamentally cloud-dependent, since deployments, updates and monitoring all flow through Azure connectivity.

Deep Azure ecosystem integration, device twins and telemetry routing
Requires Azure connectivity, so air-gapped and ISA-95 isolated environments are not supported
No multi-site RBAC or policy propagation independent of Azure
Lock-in to Azure licensing, data residency and pricing changes
Not designed for Kubernetes workloads or multi-runtime environments

AWS IoT Greengrass

Extends AWS Lambda and container execution to edge devices, with device management and deployment orchestrated through AWS IoT Core, which suits organizations deeply invested in the AWS toolchain. Governance, fleet management and audit all route through AWS.

Native AWS integration, Lambda at the edge, Greengrass components
Air-gapped and OT-isolated environments sit outside the design scope
No RBAC model designed for multi-site industrial governance
Licensing, data residency and regional availability are AWS-dependent
Complex pricing that scales unpredictably against fleet size and data volume

Balena

Provides container-based device fleet management through a SaaS control plane, with a strong focus on developer experience, delta updates and device lifecycle, which suits connected IoT product companies. The SaaS delivery model creates data residency and connectivity constraints that are difficult to accommodate in regulated OT environments.

Good developer experience, delta update efficiency, device lifecycle tooling
SaaS-first model, with the self-hosted option significantly less capable and unsupported
No enterprise RBAC, policy propagation or identity integration
Not designed for regulated OT environments or ISA-95 network segmentation

k3s, MicroK8s, and bare Kubernetes

Lightweight distributions reduce the hardware requirement for running Kubernetes at the edge, which solves the resource constraint but not the governance problem; running k3s on 50 factory nodes produces 50 independent Kubernetes clusters to manage, update, audit and govern individually.

Low resource footprint and full Kubernetes API compatibility
No centralized governance, RBAC or policy across the fleet
Each node or cluster requires individual management, so burden scales with fleet size
Requires Kubernetes expertise that OT teams typically do not have
Air-gap and update workflows require additional tooling such as Flux, Argo or custom scripts

Ansible, Puppet, and Chef for containers

Many OT and industrial IT teams already operate configuration management tooling and extend it to container workloads, which works for simple, uniform deployments; it does not provide centralized container governance, RBAC, GitOps-based deployment standardization, or real-time operational visibility.

Reuses existing operational tooling and team skills
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 such as image updates, restarts and rollbacks

Portainer Edge

Governs Docker, Podman and Kubernetes at the edge from a single self-hosted control plane, with the async edge agent operating independently at each site, buffering pending instructions, and syncing when connectivity allows.

Async edge agent that runs independently and never blocks on an uplink
Native air-gap support through registry mirroring and offline image distribution
ISA-95 zone-compatible, with no inbound firewall rules required from the OT network
Full audit trail across every change and every site, centrally logged and queryable
FIPS-140-3 compliant operation for regulated environments
Runtime-agnostic across Docker, Podman and Kubernetes in a single fleet view, with KubeSolo devices accepting both Kubernetes and Docker API calls
Feature matrix

Operational comparison for industrial and OT environments.

Scroll horizontally on smaller screens. Entries marked as not confirmed are ones we have been unable to verify from vendor documentation, and they are left unresolved rather than assumed.

CapabilityPortainer EdgeAzure IoT EdgeAWS GreengrassBalenak3s / MicroK8s
Connectivity and air-gap
Air-gapped and fully offline operationNative async agentNot supportedNot supportedNot supported (SaaS)Possible, no management plane
Intermittent connectivity resilienceBuffers and syncs on reconnectLimited, queued commandsPartialPartial, local agent cachingWorkloads run, no management sync
ISA-95 OT network zone compatibleNo inbound rules requiredRequires outbound to AzureRequires outbound to AWSRequires outbound to cloudWorkloads only, no governance
Offline registry and image distributionBuilt-in registry mirroringPartial, manual setupPartialDelta updates, cloud-routedManual, additional tooling
Self-hosted, no cloud vendor dependencyAlways self-hostedRequires AzureRequires AWSSelf-hosted option, limitedYes
Governance, identity, and audit
Centralized RBAC across all sitesFull fleet RBACEntra ID-bound, limited fleet RBACIAM-bound, per-device scopingNo enterprise RBACPer-cluster only, manual
AD, LDAP and OIDC single sign-onNative integrationVia Entra ID onlyVia AWS IAM onlyNot availableCustom integration required
Audit log of who changed what and whenFull action audit, all sitesAzure Monitor, partialCloudWatch, partialLimitedCustom build required
Fleet-wide policy propagationCentralized policy enforcementDeployment manifests onlyComponent recipes onlyNot availablePer-cluster, manual
FIPS-140-3 compliant modeNativeNot confirmedNot confirmedNot availableNot available
Deployment and operations
Staged rollout, site by siteBuilt-in staged groupsDeployment rings, limitedDeployment groups, limitedRelease pins, limitedManual, no native staged rollout
GitOps-based deploymentCentralized GitOps executionVia Azure DevOps integrationVia AWS CodePipelineNot nativelyCluster-local, Flux or Argo
Docker and Podman supportNative, full lifecycleDocker modulesDocker containersDocker-basedNot designed for Docker
Lightweight Kubernetes at the edgek3s and KubeSolo; KubeSolo also accepts Compose via embedded D2KAKS Edge Essentials, limitedEKS Anywhere, heavyNo Kubernetes supportFull Kubernetes API
Requires specialist Kubernetes skillsNo, operable by OT and IT generalistsCloud skills requiredAWS skills requiredModerate, developer-orientedYes, Kubernetes expertise required
Cost and deployment model
Free tier availableYes, up to 3 nodesLimited free messages per monthLimited free tierFree up to limited devicesOpen source, free
Pricing model clarityTransparent per-nodeComplex, message and operation basedComplex, message, device and dataPer-device SaaSNo licensing cost
Data residency controlFull control, self-hostedAzure region-dependentAWS region-dependentCloud-routedFull control
Competitor capability statements are drawn from vendor documentation at the time of writing and third-party platforms change frequently, so verify against current vendor documentation before relying on any single row in a procurement decision. Where a capability could not be confirmed it is marked as not confirmed rather than inferred.
Looking for enterprise IT?

Portainer against OpenShift, Rancher, NKP, Tanzu, and DIY stacks.

For enterprise IT teams evaluating Kubernetes management platforms the comparison set is different, and that comparison lives on portainer.io alongside the enterprise Kubernetes governance material.

Ready to govern your industrial edge?

Start free with up to 3 nodes, or talk to our industrial team about your OT deployment.