kube32 runs Kubernetes-style orchestration on ESP32 boards with WebAssembly pods

An open-source project called kube32 implements a Kubernetes-compatible control plane and a WebAssembly pod runtime on ESP32-S3 microcontrollers. According to the project's GitHub repository, which reached Hacker News' front page, standard cluster tooling such as kubectl and k9s can manage a fleet of the boards over Wi-Fi or USB serial, with pods executed as WebAssembly modules by the wasm3 interpreter.

One firmware, two roles

Every board flashes the same image. A board equipped with PSRAM takes on the control-plane job and also runs its own kubelet, while boards without PSRAM join as workers. The project's hardware spec calls for an ESP32-S3 with 8 MB of flash and at least 2 MB of quad-SPI PSRAM on the control plane, with a generic devkit as the reference. Any ESP32-S3 carrying 8 MB of flash can serve as a worker; the M5Stack Cardputer, with its ST7789 display, keypad, speaker and microSD slot, is the suggested reference device.

A broad API surface

The implemented Kubernetes API covers Pod, Node, Namespace, Service, Endpoints, EndpointSlice, Ingress, Deployment, DaemonSet, Job, ConfigMap, Secret, Lease and Event objects, along with metrics. Support for watch streams, Table output, OpenAPI v3 validation and log tailing is what allows unmodified kubectl and k9s clients to operate against the cluster.

Pods as sandboxed WebAssembly

Applications are built from SDKs and templates for Rust, C and AssemblyScript, targeting either a request-handler ABI (k32_handle) or an entry-point ABI (app_main). Each pod gets configurable memory limits and a per-call gas budget, the project's mechanism for bounding how much computation a single invocation may consume. Lifecycle semantics follow Kubernetes conventions: restartPolicy options of Always, OnFailure or Never, exponential backoff in CrashLoopBackOff, and distinct exit codes for Wasm traps, gas exhaustion and out-of-memory kills.

Hardware access is mediated by a per-pod capability firewall spanning GPIO pins, ADC channels, I2C and UART buses, the ST7789 display, the Cardputer key matrix, the I2S speaker and microSD storage.

Networking, storage and rollouts

The control plane provides service routing plus an HTTP Ingress with host and prefix rules, alongside Server-Sent Events streams, embedded static asset bundles and synchronous pod-to-pod HTTP calls. State persists in an object store journalled with CRC checks to either a raw flash partition or a microSD card, with persistentVolumeClaim-style pod volumes and rotated logs so that kubectl logs --previous behaves as expected. Cluster events propagate through a pub/sub bridge carried over ESP-NOW and UDP port 7400.

Operational details include optional bearer-token authentication, automatic self-signed ECDSA P-256 TLS on port 6443, and staged firmware rollouts that update one node at a time, verify images with SHA-256 and fall back through the bootloader when a node fails to come up healthy.

Simulator and the Tessera demo

The same sources also build kube32-sim, a host simulator for macOS and Linux that runs a multi-node cluster without any hardware, and kube32-cli for building, checking and deploying pods. The project's showcase application, Tessera, is an issue tracker split across four WebAssembly pods behind a single Ingress: the web UI and search API run on the control plane, a database pod appends records to the worker's microSD card, and a display pod drives the Cardputer's screen and keypad. Full documentation is published on the project's site, and the code is Apache 2.0 licensed, with the bundled wasm3 interpreter under MIT.

Why it matters

Microcontrollers offer no operating-system isolation to build containers on, so kube32 leans on WebAssembly as the sandbox instead, with gas metering and the capability firewall standing in for cgroups and seccomp. That substitution is the interesting engineering bet here: if the sandbox holds, the Kubernetes API becomes a management surface that scales all the way down to a handful of hobbyist dev boards.

Two things lift it above a novelty demo. First, unmodified kubectl and k9s working against $10-class hardware suggests the Kubernetes operational model could plausibly extend to fleets of sensors and edge devices, an area where tooling is usually bespoke. Second, the supporting machinery is real rather than cosmetic: journaling storage, TLS, staged rollouts with rollback, and a host simulator for developing without buying boards. Whether anyone orchestrates production hardware this way remains to be seen, but as a proof of how far a familiar API can stretch, it is a compelling experiment.