Ultra-lightweight, OCI-compliant Kubernetes built for constrained environments, with Portainer D2K embedded so the same device accepts Helm charts, Kubernetes manifests, Docker Compose files and Docker CLI commands. No clustering, no etcd, just what is needed to run real workloads on the hardware that industrial sites actually deploy.
Most Kubernetes distributions are trimmed-down versions of cloud platforms, and none of them were purpose-built for a device with 512MB of RAM and a CF card for storage; KubeSolo is a hardened, single-node fork of k3s with clustering removed, ingress simplified, and defaults retuned for the real constraints of industrial hardware. The reason that matters in an industrial context is that Kubernetes has become the expected packaging target for industrial software, so an operator running constrained hardware would otherwise be forced onto Docker regardless of what the vendor ships.
Designed from the ground up for devices that cannot spare resources for clustering logic, multi-node orchestration, or etcd, and it manages its own cache release under memory pressure.
Unlike a worker node architecture, KubeSolo keeps the control plane on the device itself, so scheduling, updates and reconciliation continue to function even when the site is offline or intermittently connected.
OCI-compliant, Helm-ready and CRD-friendly, which gives access to the Kubernetes operator and tooling ecosystem including off-the-shelf industrial software packages that require Kubernetes.
Works on any modern Linux distribution across x86_64, ARM and ARM64, and is distribution-agnostic by design, having been tested on Ubuntu, Arch, Armbian, and Siemens Industrial OS.
KubeSolo ships with built-in Portainer Edge Agent integration flags, so passing the Edge ID and Edge Key at install time registers the node automatically with your control plane.
A local path provisioner is bundled by default for static and dynamic persistent volume provisioning, with full CSI driver support available; NodePort is recommended over ingress to minimize footprint.
KubeSolo is Kubernetes, so it accepts Helm charts and Kubernetes manifests natively. Since v1.1.7 it also ships with D2K, Portainer's Docker-to-Kubernetes API translator, which exposes the Docker Engine API on the device and translates every Docker call into Kubernetes operations scoped to a single namespace; that means the same device also accepts Docker Compose files and instructions from the Docker CLI, without a Docker daemon running anywhere on it.
The consequence for an industrial fleet is that the runtime decision stops being a packaging decision. An ISV shipping a Compose file and an ISV shipping a Helm chart can both land on the same KubeSolo device, and an OT engineer who knows docker ps and docker logs can work on a Kubernetes device using the commands they already use. Enable it with the --d2k flag at install time, specifying the target namespace; it is embedded in the binary rather than a separate install, but it is opt-in rather than on by default.
depends_on is ignored, because Kubernetes does not guarantee pod start order; use readiness probes in the application insteadbuild directives are ignored, so images must be built and pushed to a registry before deploymentdocker swarm init and docker swarm leave return 501, since the device is not a real Swarm nodeKubeSolo is not trying to replace k3s or MicroK8s; it exists specifically for the hardware they cannot run on, and the decision should be made on the memory available on the device rather than on preference.
| Distribution | Typical RAM usage | Best for |
|---|---|---|
| KubeSolo | ~200MB | 512MB devices and below: IoT sensors, PLCs, embedded gateways |
| k3s | ~400MB | 1GB and above: general edge, Raspberry Pi 4 and later |
| k0s | ~400MB | 1GB and above: lean servers, developer workstations |
| MicroK8s | ~2GB | Well-resourced edge or developer machines |
| Standard distributions | Variable | Cloud VMs, on-premises servers, multi-node clusters |
If your devices have 1GB or more of RAM, standard lightweight distributions are a better choice, because they are CNCF-certified, more widely adopted, and have larger ecosystems. KubeSolo does not currently meet CNCF certification criteria, due to the memory-footprint optimizations required to reach the sub-200MB target, and we plan to engage with CNCF on this.
KubeSolo is purpose-built for industrial IoT hardware including factory gateways, embedded PLCs, retail kiosks and single-board computers, and the platforms below have been tested on real hardware in the field.
ARM64 AI edge compute, with verified KubeSolo deployment for containerized inference workloads.
Industrial IoT gateway running Siemens Industrial OS, as a factory-floor deployment target.
ARM IoT single-board computer, verified on RPi CS5, suited to sensor-adjacent edge deployments.
x86_64 single-board server in a compact NAS and edge form factor with low power draw.
Low-power x86 embedded platform, typical of industrial panel PCs and kiosk hardware.
Compatible with Linux-capable PLCs and edge compute from major industrial automation vendors, including Beckhoff CX7000, PLCnext AXC F 1152, and the Advantech compact edge series.
KubeSolo is fully open source at kubesolo.io, and Portainer offers a commercially supported edition for organizations that need fleet management, governance and a support SLA across the estate.
Free and open source, installed with a single curl command, with full access to all features and community support.
The same open-source runtime paired with Portainer's operator control plane for centralized fleet management, commercial support, and governance across every edge node.
The standard install adds or upgrades KubeSolo and starts the control plane with a default configuration, and the admin kubeconfig is written to /var/lib/kubesolo/pki/admin/admin.kubeconfig.
It requires Linux with sudo access, curl, iptables and libsqlite3-dev, and no existing container engine should be installed on the device before running it, so a host already running Docker, Podman or containerd needs to be cleared first.
KubeSolo is a hardened, single-node fork of k3s with clustering and HA logic removed, ingress simplified, and defaults retuned for resource-constrained environments. It is not a CNCF-certified distribution, because the memory-footprint optimizations required to reach the sub-200MB target mean it does not fully meet the current CNCF criteria, and Portainer intends to engage with CNCF to address this.
Yes, through embedded D2K. KubeSolo is Kubernetes and accepts Helm charts and manifests natively, and D2K exposes the Docker Engine API on the device and translates those calls into Kubernetes operations, so Compose files and Docker CLI commands work against the same device. Enable it with the --d2k flag at install time.
Docker and Podman are lighter and remain the right choice when absolute minimal resource use is the priority. Kubernetes has nonetheless become the standard packaging target in industrial IoT and Industry 4.0, and many off-the-shelf industrial software packages now require it, so KubeSolo provides Kubernetes compatibility on hardware where Docker would otherwise be the only option.
Worker nodes depend on a remote control plane, so when an edge location experiences intermittent or intentional loss of connectivity the kubelet can restart containers but scheduling, updates and reconciliation all stop. KubeSolo keeps the control plane on-device, which is why automation continues to function while the site is offline.
KubeEdge requires edge devices to act as worker nodes within a centrally managed cluster, which is not suitable for environments with unreliable connectivity. KubeSolo provides fully autonomous, self-contained single-node clusters designed explicitly for offline or standalone deployment.
KubeSolo is single-node by design, so managing hundreds of edge devices requires a multi-cluster management solution; Portainer provides centralized visibility, configuration and control over each instance through a single interface, with the async edge agent handling offline-safe operations.
KubeSolo exposes a standard Kubernetes API, so kubectl, VSCode, OpenLens, Headlamp, K9s and Portainer all work, and ArgoCD can be connected remotely via the Kubernetes API. For fleet-scale management across many devices, Portainer is the recommended approach.
Start free with up to 3 nodes, or talk to our industrial team about your OT deployment.