Containerization Without Compromise - Atym Now Supports Both Wasm and Linux Containers!

Docker, and soon after Kubernetes, fundamentally changed how we build software in the cloud. Over the past ten years, these technologies have been increasingly used to power edge deployments. However, there's a practical limit to how far down they can scale. In the case of Docker on Linux, the floor is roughly 256 MB of memory.  This makes it difficult to support the billions of embedded Linux devices that have less than 1GB of memory, and is a non-starter for microcontrollers.   

But what if we could build software for resource-constrained edge devices with the same agility as we do in the cloud? Atym is making this a reality by offering tiny, WebAssembly-based containers that behave like Docker, but are portable across any hardware architecture and can scale down to microcontrollers with as little as 256 KB of memory.   

We also understand that most developers aren't starting from scratch. You have existing applications, established workflows, and devices in the field that you need to keep running. I'm happy to announce that we're expanding Atym’s capabilities to reflect that reality. We now concurrently support both Wasm and Linux containers. This gives you all the benefits of a runtime built for constrained hardware to the workloads you're already running, without a rewrite and without compromise. 

Read on to learn more about this exciting new capability! 

Embedded has been left behind... until now. 

Developing and managing software on resource-constrained embedded devices has always required discipline.  Programming is predominantly limited to C/C++.  Any single change requires recompilation and retest. Updates often mean full firmware flashes and can be risky. Rollback paths are limited. Devices run for years and often on unmanaged networks. 

Meanwhile, further up the edge-to-cloud continuum, containerization has brought agility and flexibility to development and deployment. Instead of tightly coupling applications to the underlying operating system, containers package applications with their dependencies into isolated, reproducible units. Updates become fractional and predictable. Rollbacks become manageable. Operational risk decreases. 

In most environments, containers are implemented using platforms like Docker or Podman. These tools provide a container runtime, image management, networking model, and developer workflow. They’re mature, capable, and extremely effective — on hardware that has sufficient resources.   

These technologies aren’t suitable for most embedded use cases. A runtime footprint measured in hundreds of megabytes, background daemons competing for CPU and memory, and fleet management that depends on an external orchestration stack are acceptable tradeoffs on hardware with gigabytes of memory, but on a resource-constrained embedded SoC running a critical workload, they become architectural liabilities. 

Atym was built from the ground up to solve this problem. Our runtime leverages WebAssembly (Wasm) as its core virtualization technology.  This provides sandboxed isolation and a hardware-agnostic execution environment that delivers true containerization in a fraction of the footprint.  

Wasm containers support choice of programming language, start in milliseconds, and consistently execute across heterogeneous hardware: from microcontrollers such as Arm’s Cortex-M, to RISC-V cores, and embedded Linux boards.  All of this in a tiny footprint without a Linux dependency. Just your application, isolated and portable. 

Atym follows the Open Container Initiative (OCI) image specification, so standard workflows — registries, versioned images, declarative deployments — work as expected. What changes is the on-device overhead. And the fact that remote fleet management is built in with our centralized orchestration Hub. 

In order to meet developers where they are today and offer even more flexibility, the Atym Runtime now supports Linux containers alongside our native Wasm containers. Deployed on the same device, managed through the same interface, with the same remote fleet management capabilities that have always set Atym apart. It’s worth noting that the Atym Linux runtime is required for deploying Linux-based containers together with Wasm containers.  MCU-based devices will continue to only support Wasm containers on top of the Zephyr Runtime. 

What can you do with a few hundred megabytes of extra memory? 

The Atym Runtime is deliberately minimal. Unlike Docker or Podman which bundle a broad feature set regardless of whether your device needs it, Atym is sized for resource-constrained hardware. Its on-device memory and storage footprint are about 10 times lower than what a traditional Linux container platform requires. Importantly, this is the runtime overhead, not the container itself. The resources your application containers consume are determined by the workloads they run, and that does not change whether you're running on Atym, Docker, or Podman.   

Under the hood, Atym uses crun as its OCI runtime engine, the same low-level container executor used by Podman and CRI-O, and is built for minimal footprint. Atym implements the core OCI runtime operations that container workloads rely on day to day. Above that layer, Atym handles image management, deployment, lifecycle orchestration, remote logging, and the rest of the management plane that Docker simply does not provide. 

For image distribution, Atym works with standard OCI-compatible container registries. You can connect your existing registry, or use Atym’s built-in registry. 

With Atym, Wasm and Linux containers can now operate side by side within a single, consistent runtime environment. They use the same OCI image format, the same deployment semantics, and have the same remote management and orchestration capabilities through the centralized Atym Hub. 

The execution mechanisms differ by necessity: Wasm workloads run inside a WebAssembly virtual machine, while Linux containers leverage the Linux kernel and and crun. Beyond that boundary, the operational model is identical. Images are distributed through OCI-compatible registries. Deployments follow the same pull, verify, and run sequence. Updates and rollbacks are handled uniformly across the fleet. 

This means teams don't need separate tooling, separate pipelines, or separate operational models. Whether a device is running Wasm containers, Linux containers, or both, the management experience remains consistent.  For organizations managing diverse hardware platforms, that consistency reduces operational complexity significantly.  Further, they can manage fleets that also include devices based on microcontrollers.  

Have your container and eat it too. 

Adding support for Linux containers is a natural evolution of the Atym platform. It's a recognition that migrations happen incrementally, and that choice is a feature.  Some teams will run Linux containers on Atym indefinitely, and that's a perfectly valid outcome. A runtime overhead that’s a few hundred megabytes lower can justify the switch to deploying your existing Linux containers with Atym. 

Other teams will use Linux container support as a bridge by starting with their existing application images. Over time, they can incrementally port workloads that make sense for Wasm containers due to tighter sandboxing, even lower total overhead, faster startup times, and true portability across CPUs and MCUs. New functionality can be written as Wasm containers from day one while existing services remain the same. 

"Cloudifying" the embedded space.  

The embedded and edge computing space is converging on cloud-native patterns. OCI images, declarative deployments, and centralized fleet management. These aren't cloud concepts anymore, they're universal infrastructure concepts that benefit all developers in terms of agility and flexibility.  But what the edge doesn't need is the full weight of the cloud-native stack running on hardware that was never designed for it. 

Atym doesn’t force a choice between pragmatism and a better long-term architecture. In supporting both Wasm and Linux containers with a built-in remote management console, we relieve that tension without sacrificing compatibility or performance.  

If you're running containerized workloads on Linux-based embedded hardware, or evaluating how to bring containerization to devices that can't support Docker at all, come talk to us at Embedded World and see a demo of our hybrid container support in action.  We’re in the startup zone in Hall 2 - booth number 2-412E.