Microcontroller development has traditionally been quite different from modern application development. In many embedded projects, the operating system, firmware, drivers, and application logic are tightly bundled together. If the app needs to change, the firmware often needs to be rebuilt, reflashed, and redeployed.

AkiraOS takes a different approach. It separates the embedded operating system from the application layer and allows small WebAssembly applications to run on top of a Zephyr-based system. In simple terms, it brings something that feels a bit like Docker-style application deployment to the microcontroller world.

That comparison is not perfect, of course. Microcontrollers are far more constrained than servers, and WebAssembly apps are not the same as full Linux containers. But the idea is similar enough to be interesting: keep the base system stable, run apps in a controlled environment, and update those apps without having to reflash the whole device.

Why This Is Interesting for Embedded Development

For embedded developers, firmware updates can be painful. A small application change may require rebuilding the firmware image, testing the full device behavior again, and pushing an update that affects the entire system. That is manageable in a lab, but it becomes more complicated when devices are already deployed in the field.

AkiraOS tries to reduce that friction by allowing applications to be packaged as independent .wasm binaries. These apps can be deployed over the air, updated separately from the operating system, and run in a sandboxed environment.

This means the main firmware can remain stable while application logic changes independently. If an app fails, the whole device should not necessarily go down with it. That separation between platform and application is a big part of what makes the project interesting.

For IoT devices, industrial sensors, connected controllers, and small smart devices, this kind of model could make updates safer and more flexible.

Built on Zephyr RTOS

AkiraOS is built on top of Zephyr RTOS, which is already a popular real-time operating system for embedded devices. Zephyr provides the low-level system foundation, including scheduling, networking, drivers, Bluetooth support, file system support, and hardware abstraction across different microcontroller families.

On top of that, AkiraOS adds its WebAssembly-based application layer. This is where the Docker-like comparison comes in. Instead of flashing a different firmware build for every application change, developers can deploy a WebAssembly app into the system.

The platform includes its own custom runtime called Akiraz, along with support for WebAssembly Micro Runtime, commonly known as WAMR. Depending on the use case, apps can run through an interpreter or be compiled ahead of time for much better performance.

That flexibility matters because embedded devices often have strict limits on memory, processing power, and energy usage.

How the Application Model Works

AkiraOS allows multiple WebAssembly applications to be installed on a device, with up to eight apps supported in user space. Out of those, up to two apps can run at the same time.

Each app is relatively small, with a footprint of around 50KB to 200KB per app. That makes sense for microcontroller environments, where storage and RAM are limited compared to regular computers.

The bigger idea is that apps are portable. A single WebAssembly binary can run across supported microcontroller targets such as ESP32-S3, Nordic nRF boards, or STM32 boards without recompilation. That is a major benefit because embedded development often requires board-specific builds and toolchains.

With AkiraOS, the OS handles the hardware layer, while the app runs inside a controlled WebAssembly environment.

Sandboxing and Hardware Access

One of the most important features of this approach is sandboxing. Each app only gets access to the hardware capabilities it explicitly requests. That means an app does not automatically have unrestricted access to the device.

This is useful from both a stability and security perspective. If an app crashes or behaves badly, the system can isolate the problem more effectively. The device itself can stay online instead of failing completely.

This matters a lot for deployed embedded systems. A bad app update should not turn a device into a brick. Keeping the core OS separate from the app layer gives developers more room to recover, update, or replace faulty application logic.

In practical terms, AkiraOS is trying to make embedded devices feel more manageable after deployment, not just during development.

Main Features of AkiraOS

AkiraOS includes quite a few platform-level features beyond simply running WebAssembly apps. It is designed as a complete embedded application environment rather than only a runtime.

Some of the key highlights include:

The UI framework is also worth noting. Embedded platforms often need simple display interfaces, menus, buttons, indicators, and device controls. Having widgets available as part of the environment could make it easier to build interactive applications without starting from scratch.

Performance Options With WAMR

AkiraOS supports WebAssembly Micro Runtime, giving developers two execution options: interpreter mode or Ahead-Of-Time compilation.

Interpreter mode is simpler and more flexible, but it is usually slower. Ahead-Of-Time compilation can offer much better performance, with claims of 10 to 50 times higher speed depending on the workload and target device.

That trade-off is familiar in embedded development. Sometimes flexibility matters more. Sometimes performance is critical. Having both options gives developers a way to choose the right balance for their project.

For small logic apps, interpreter mode may be enough. For more demanding workloads, AOT compilation may be the better option.

Over-the-Air App Updates Without Reflashing Firmware

One of the biggest practical advantages of AkiraOS is the ability to update applications over the air without reflashing the entire firmware.

This is a major change for field-deployed devices. Instead of pushing a complete firmware update for every small change, developers can deploy only the updated WebAssembly app. That can reduce risk, simplify maintenance, and speed up iteration.

The benefits are clear:

This is where the Docker comparison becomes easiest to understand. The system stays in place. The apps are swapped, updated, or managed separately.

Supported Hardware Targets

AkiraOS currently focuses on a few hardware families, with different levels of support.

Tier 1 support includes Espressif's ESP32 series, especially the ESP32-S3 and newer RISC-V-based ESP32-H2 and ESP32-C6 devices. The ESP32-S3-DevKitM-1 is listed as a recommended development board. There is also mention of an upcoming open-source hardware device called AkiraConsole V3, expected to appear on Crowd Supply.

Native_sim is also supported for fast development on x86-64 machines, which allows developers to test and iterate without needing microcontroller hardware immediately. This can be very useful during early development.

Tier 2 support includes Nordic and STM32 targets, such as:

That spread of hardware support makes the project more interesting because it is not tied to one vendor or one board family.

Management Tools and Developer Experience

AkiraOS also includes management features beyond the embedded runtime itself. The project has source code and getting-started instructions available on GitHub, along with a separate SDK repository for developing AkiraOS apps.

The documentation also mentions a mobile app being developed to manage connected devices. Based on the available information, the mobile app is expected to support tasks such as viewing device information, checking device status, managing apps, triggering OTA updates, accessing the shell or terminal, and browsing files on the target device.

There is also a management web interface that can be accessed through WiFi or USB. This could make AkiraOS more approachable for development, testing, and field maintenance.

That management layer is important. A modular app model is useful, but it becomes much more practical when developers and users have tools to see what is installed, update apps, inspect files, and troubleshoot devices.

Why WebAssembly Makes Sense Here

WebAssembly is best known for running near-native code in web browsers, but its value goes beyond the browser. It provides a portable binary format, sandboxed execution, and language flexibility. Those qualities make it appealing for embedded systems too.

For microcontrollers, portability is a big deal. Traditionally, the same application logic may need different builds for different chips, boards, or architectures. WebAssembly can reduce that pain by acting as a common application layer.

The sandboxing is also valuable. Embedded systems often interact with real hardware, sensors, radios, storage, and networks. Giving apps only the permissions they need can help reduce damage from bugs or poorly written code.

That said, WebAssembly on microcontrollers is still not magic. Devices still have memory limits, performance constraints, and hardware-specific requirements. But for certain classes of IoT and embedded applications, the model could be very useful.

Final Thoughts

AkiraOS is an interesting attempt to modernize microcontroller application deployment. By combining Zephyr RTOS with sandboxed WebAssembly apps, it creates a cleaner separation between the stable firmware layer and the application layer.

That separation could make embedded devices easier to update, safer to manage, and more portable across hardware platforms. For developers who have dealt with repeated firmware rebuilds and reflashing cycles, the idea of deploying small .wasm apps over the air is naturally appealing.

It is not exactly Docker for microcontrollers, but the comparison helps explain the direction. AkiraOS brings some of the same modular thinking to a much smaller and more constrained environment.

If the project matures well, it could become a useful platform for IoT devices, embedded user interfaces, sensor nodes, and connected hardware projects where field updates and app isolation matter. For now, it is definitely one of the more interesting examples of how WebAssembly is moving beyond the browser and into the embedded world.