TL;DR:
- Purpose-built Wasm runtimes can now run WebAssembly on microcontrollers with 256KB of RAM and no operating system
- This enables OTA-updatable application logic on resource-constrained IoT hardware without requiring a full Linux environment
- TinyML models can be packaged as Wasm modules alongside sensor logic, enabling inference on MCU-class chips without cloud round-trips
WebAssembly started in browsers. Then it moved to server-side workloads through Wasmtime and WASI. Then edge compute platforms like Cloudflare Workers and Fastly Compute adopted it as their execution model. The current frontier is further down the stack: microcontrollers with 256 kilobytes of memory, no operating system, and direct hardware register access.
This is not theoretical. Two distinct Wasm runtimes are demonstrably running on MCU-class hardware in production contexts in 2026, and the ecosystem around them is growing quickly.
The Case for Wasm on Microcontrollers
Traditional embedded firmware development has a problem that has never been adequately solved: updating logic on deployed devices is difficult, brittle, and risky. A firmware update on a microcontroller typically replaces the entire program image. The update has to be carefully targeted to the exact hardware revision, compiled for the exact chip architecture, and validated against the exact memory layout. A bad update can brick a device permanently.
Wasm on microcontrollers separates the runtime from the application logic. The runtime — a small, validated, purpose-built interpreter or JIT — lives on the device and does not change. Application logic is compiled to Wasm and delivered as a module. Updating the logic is a module swap, not a full firmware reflash. The runtime validates the module before executing it. Sandboxing prevents a buggy module from corrupting adjacent memory or accessing hardware it was not given permission to use.
For device fleets deployed at scale — sensors in agriculture, meters in utilities, actuators in industrial automation — this changes the operational model fundamentally. You can update inference models, business logic, and data processing pipelines without touching the runtime. Rollback is straightforward. Staged rollouts work the same way they do in web deployments.
Atym and the 256KB Threshold
A company called Atym has built a Wasm runtime specifically targeting constrained embedded devices. Their runtime operates within 256KB of RAM, uses no operating system (bare-metal execution), and distributes Wasm modules via standard OCI container registries — the same infrastructure used for Docker images in cloud environments.
The OCI registry integration is significant. It means embedded device management can use the same tooling, access controls, and distribution infrastructure as cloud container deployments. A module published to a registry is pulled by devices with appropriate credentials, verified against a digest, and executed in the runtime sandbox. The device management stack looks like container orchestration, not firmware provisioning.
Atym also supports TinyML through Wasm. A quantised neural network model — object detection, anomaly classification, keyword spotting — can be packaged as a Wasm module alongside the sensor reading and output logic. The entire pipeline runs in the sandbox. When the model needs updating because accuracy has drifted or the use case has changed, a new Wasm module is pushed through the registry. No firmware reflash required.
WAMR: The Apache Project Option
The WebAssembly Micro Runtime (WAMR) is an Apache-licensed project that provides a more established, community-supported alternative. WAMR targets MCU and RTOS environments and has been integrated into Zephyr RTOS, FreeRTOS configurations, and bare-metal environments on chips from ARM, RISC-V, Xtensa (ESP32), and MIPS architectures.
WAMR supports three execution modes: interpreter mode (smallest footprint, works on any MCU), Fast JIT (trades some memory for execution speed), and LLVM JIT for environments with more resources. The interpreter mode runs in as little as 60KB of RAM on simple workloads, making it deployable on hardware where Atym’s 256KB minimum is still too large.
The tradeoff is ecosystem maturity. Atym’s OCI-native distribution model is more immediately practical for cloud-connected device fleets. WAMR has broader hardware support and a larger open-source community, but the tooling around module distribution and fleet management is less developed.
What You Can Actually Run
The workloads that run well on MCU-class Wasm today are those that fit within the memory constraints and do not require continuous, low-latency hardware interrupt handling:
Sensor data processing: filtering, aggregation, anomaly detection on accelerometer, temperature, gas, or pressure data before transmitting to a gateway. Running this locally reduces transmission volume and avoids cloud dependency for basic classification decisions.
TinyML inference: image classification on OV7670-class cameras, keyword spotting on PDM microphone input, vibration anomaly detection on MEMS accelerometers. Quantised MobileNet V1 and keyword spotting models routinely run within 256KB with appropriate quantisation.
Protocol translation: converting between device-native serial protocols and MQTT or CoAP for cloud transmission. Wasm-based protocol modules update independently of the rest of the firmware.
Configuration and policy logic: business rules that determine when to sample, how often to transmit, and which events trigger an alert. These change frequently in deployed systems and benefit most from the OTA-without-reflash model.
Getting Started
For teams evaluating this approach, the practical starting point depends on the hardware you are targeting and whether you need the OCI distribution model.
For ESP32-based projects or Zephyr RTOS environments, WAMR is the more established path. The Zephyr integration is maintained and has production deployments. The documentation for building Wasm modules targeting WAMR with the Emscripten or WASI-SDK toolchain is reasonably mature.
For cloud-connected fleets where OTA management is the primary concern, Atym’s runtime and its OCI integration addresses the hardest operational problem directly. The 256KB floor limits the hardware range, but for any MCU with 512KB or more, it is within reach.
The broader Wasm component model standardisation work happening through the W3C WebAssembly Community Group is also relevant here. Component model support — which enables composable Wasm modules with typed interfaces — is beginning to appear in WAMR and will eventually make it easier to build complex embedded applications from independently-developed and independently-deployable Wasm components.