Revolutionizing Embedded with WebAssembly

By Jason Shepherd

Co-Founder and CEO

Atym

May 12, 2025

Story

Revolutionizing Embedded with WebAssembly

What if you could have the agility of software containerization and cloud-native development principles while meeting the resource constraints, performance, and security needs of embedded devices? A growing number of industry leaders have landed on WebAssembly as the solution.

Embedded devices are more capable than ever, but for many years, development has been characterized by tight coupling to hardware and monolithic firmware that’s rigid to innovation and collaboration. There have been incremental improvements over time, but recent macro trends are forcing us to completely rethink our approach.

Macro Trends are Necessitating a New Approach

Streamlining embedded development has been a “nice to have” for a long time.  However, two recent macro trends are necessitating change.

First is the demand for on-device AI to yield faster and more accurate insights, reduce network bandwidth consumption, and improve privacy. This increases the need to update devices in the field as the AI models inevitably evolve over time. It also tends to create a skill gap in the development process because engineers building AI models and integration pipelines are typically familiar with technologies like Docker and Kubernetes, not firmware. 

Then there’s growing cybersecurity regulation. Embedded security is challenging enough due to general resource constraints, lack of Memory Management Units in MCUs, difficulty implementing silicon-based root of trust, and more. A breach of deployed devices can have a major impact on an organization’s customers and brand. When it goes into full effect in 2027, the EU’s Cyber Resilience Act (CRA) will make the repercussions of a security breach even greater as it imposes heavy fines on companies whose products are compromised. 

There are also growing cybersecurity requirements around Software Bill of Materials (SBOM) to prove code provenance, which can be difficult to generate and maintain with tightly-coupled firmware. And finally, there’s increasing pressure to move away from programming languages that aren’t memory safe, including C/C++, which represents 99% of embedded code today.

It’s simply not practical to replace all existing code, but what if there were a way to run legacy code in an isolated environment alongside new code written in memory-safe languages?

Collaboration Further Complicates Things

Traditional embedded development is difficult, requiring specialized skills, lengthy and costly project lifecycles, and care when managing field deployments due to the risk of disrupting operations or bricking a device. Exacerbating the macro trends is the inherent need to collaborate across teams to bring together the right expertise.

Mixing different code bases and tool sets together into firmware (in what I call “source code soup”) is extremely challenging when collaborating with partners and customers because it typically entails sharing source code, which potentially exposes IP. One update to firmware can have a long-tail effect on different stakeholders, spanning an organization to its partners and customers.

Simply acquiring embedded development talent can be daunting for organizations. While the embedded space has many skilled engineers, these resources are getting increasingly difficult to find as the workforce retires faster than new talent comes in.

Roughly 80% of developers don’t have embedded programming experience, focusing instead on solutions for cloud, AI, or IoT, web, and mobile. What if we could make it as easy for these developers to write modular apps for embedded devices as they would for the cloud, without having to learn C/C++ and entirely new tool chains?

Bridging the Gap with WebAssembly

Over the past several years, technologies like Docker and Kubernetes that have brought modularity and agility to the cloud are increasingly being used to extend the same benefits to the edge. However, the applicability of these technologies hits a hard stop at what we at Atym call the “Linux Barrier”. Docker on Linux requires a minimum memory footprint of roughly 256MB, precluding its use for CPU-based devices that have limited memory and a non-starter for MCU-based devices that can’t run Linux.

Here’s where WebAssembly (Wasm) comes in. Originally developed to augment JavaScript in web browsers, Wasm is a binary instruction format that’s increasingly being repurposed to enable portable, secure workloads spanning cloud to edge environments. Its lightweight and secure design makes it a perfect choice to extend containerization and cloud native development principles to resource-constrained devices. 

WebAssembly Helps Extend Containerization Past the “Linux Barrier”

At its core, Wasm provides a sandboxed environment that can execute code compiled from different programming languages, including C, C++, Rust, and Go. These binaries are lightweight, secure, and portable across architectures. Benefits of Wasm for embedded development include:

  • Portability – Developers can write applications in their preferred language once and compile to Wasm container binaries that are portable across different platforms
  • Secure isolation – Wasm modules run in a sandbox, limiting the risk of faulty or malicious code to their assigned memory space 
  • OS flexibility – Unlike container technologies that rely on Linux, Wasm runtimes can be deployed on any OS, including RTOS and Linux environments
  • Fractional updates – Wasm-based containers can be updated fractionally, without affecting other code on the device or requiring a reboot
  • Modern development workflows – Wasm-based containerization enables cloud-native development practices, including CI/CD for embedded devices, including ones powered by MCUs

Ocre:  A Wasm Runtime for Embedded

Wasm is an amazing technology, but it isn’t a full solution for deploying, managing, and securing containers on devices. The Linux Foundation’s Ocre project is addressing this by providing a full, open-source Wasm runtime optimized for resource-constrained hardware. The Ocre runtime combines the WebAssembly System Interface (WASI) and Wasm Virtual Machine Runtime with “glue code” that facilitates interfacing with hardware resources and provides an API for orchestrating functions like starting, stopping, and updating application containers deployed above. Ocre containers follow the OCI spec and can live in the same repositories as traditional Docker containers to support existing CI/CD workflows. 

Ocre Runtime Architecture

The initial implementation of Ocre leverages the Zephyr RTOS due to its broad board support and active community. With a footprint of just 128KB, it can support containerized workloads on MCU-based devices that have as little as 256KB of total memory available. 

However, Ocre is agnostic to operating system and could just as well be powered by FreeRTOS, ThreadX, or even a proprietary RTOS like VxWorks while still providing the same universal and consistent abstraction for containerized apps above. There’s also a Linux version in development to support constrained CPU-based devices. Technically, Ocre can even be used to deploy lightweight functions in the cloud, but the sweet spot is MCU, MPU, and CPU-based devices with between 256KB and 2GB of memory.

Another standardization effort is the WebAssembly Embedded Special Interest Group (eSIG) in the ByteCode Alliance. With technical leadership from the likes of Amazon, Bosch, Schneider Electric, Siemens, Sony Midokura and Atym, the group is defining standards and looking at ways to provide long term support for the WASI core which is important for embedded systems that have long deployment lifecycles and often operate in mission critical environments. 

The Ocre community aims to codify the eSIG’s ongoing output and establish stable APIs with a predictable roadmap to buffer developers from the standard's evolution over time. At Atym, we’re taking this a step even further by creating a fully supported device edge orchestration solution that leverages Ocre.

Ecosystem Collaboration to Standardize Wasm for Embedded Use Cases

The Path Forward for Embedded Systems

Once brought up on a device, the Ocre runtime is effectively now the firmware, and containerized applications written in a choice of programming languages are then deployed above. Developers can “lift and shift” existing C/C++ code into isolated containers and deploy new apps alongside them that are written in languages like Rust and Go. Containers on a device can be fractionally updated without rebooting.

Ocre Containerization vs. Traditional Firmware

With Wasm-based containerization, security regulations like the CRA can be addressed more programmatically, SBOMs can be tracked more effectively, and legacy C/C++ code can be isolated in containers while new apps are programmed alongside them using memory-safe languages. 

In Conclusion

Macro trends, including edge AI and security regulations, are forcing many organizations to rethink their traditional approach to embedded development. WebAssembly is increasingly being recognized as a solution that can address these trends for resource-constrained embedded devices while providing the agility of cloud-native development practices.

Wasm-based containerization enables embedded developers to decouple software from hardware so code is portable across different architectures, write in their preferred programming language, and update apps fractionally in the field. Open-source Wasm runtimes like Ocre are key enablers for orchestrating apps and devices in the real world.  

For traditional embedded teams, Wasm-based containerization can reduce engineering friction, streamline security, and simplify ecosystem collaboration while protecting IP. Meanwhile, Cloud, AI/ML, and IoT engineers familiar with Linux, Docker, and modern CI/CD workflows don’t need to learn new programming languages and processes to take advantage of an entirely new footprint for software-defined innovation - the billions of embedded devices that are pervasive in the physical world.

If you want to streamline the development and deployment of resource-constrained edge devices while making it easier to integrate new technologies and meet growing cybersecurity requirements, it’s time to take a closer look at Wasm.

For more information, visit: www.atym.io


Jason Shepherd is co-founder and CEO at Atym, a startup building an open device edge orchestration solution powered by WebAssembly. He has close to 30 years of R&D experience in the IT, IoT, and edge space and holds over 40 granted and pending US patents. 

Jason Shepherd is co-founder and CEO at Atym, a startup building an open device edge orchestration solution powered by WebAssembly. He has close to 30 years of R&D experience in the IT, IoT, and edge space and holds over 40 granted and pending US patents.

More from Jason

OSZAR »