LogoفارسیFA

Building and Running WebAssembly Apps as Docker Containers

WebAssembly (Wasm) is emerging as a lightweight alternative to traditional containers, and Docker now supports building, sharing, and running Wasm apps using familiar tools. This article walks through writing a simple Wasm app with Spin, containerizing it with Docker, and running it as a Wasm container.

WebAssemblyWasm ContainersDocker Desktop

~3 min read · Updated Sep 5, 2026

Introduction

WebAssembly, usually shortened to Wasm, is often described as the third wave of cloud computing, following virtual machines and containers. Wasm apps are smaller, faster, and more portable than traditional Linux containers, and Docker has evolved to support building, sharing, and running them using the same familiar tools.

What Wasm Is

Wasm is a virtual machine architecture that programming languages can compile to, instead of targeting a specific OS and CPU architecture like Linux on ARM or AMD. A Wasm binary can run anywhere a Wasm runtime is available. Docker Desktop ships with several such runtimes, including io.containerd.spin.v2, which allows containerd to deploy and manage Wasm containers — Wasm binaries running inside minimal scratch containers.

Wasm currently excels at workloads like AI inference, serverless functions, plugins, and edge computing, but is less suited to apps with heavy I/O or complex networking requirements — though this is expected to improve as the ecosystem matures.

Setting Up the Environment

Working with Wasm requires Docker Desktop with the Wasm feature enabled, Rust with the Wasm compilation target installed, and Spin, a framework for building and running Wasm apps. The Wasm target for Rust is added with:

rustup target add wasm32-wasip1

Writing a Wasm App

A new Wasm-based web app can be scaffolded with Spin:

spin new hello-world -t http-rust

This generates a simple Rust web app. After editing the response text and compiling it, Spin produces a .wasm binary:

spin build

The resulting binary can be tested locally before containerizing it:

spin up

Containerizing the App

Packaging a Wasm app as a container image still uses a Dockerfile, but based on the empty scratch image, since Wasm apps don't need a Linux OS:

FROM scratch
COPY /target/wasm32-wasip1/release/hello_world.wasm .
COPY spin.toml .

The image is then built with a Wasm-specific platform flag:

docker build --platform wasi/wasm --provenance=false -t nigelpoulton/ddd-book:wasm .

The resulting image looks and behaves like a regular Docker image, just dramatically smaller — often only a few hundred kilobytes. It can be pushed to Docker Hub or any other OCI registry using the standard docker push command.

Running a Wasm Container

Running the containerized app requires specifying the Wasm runtime explicitly:

docker run -d --name wasm-ctr \
  --runtime=io.containerd.spin.v2 \
  --platform=wasi/wasm \
  -p 5556:80 \
  nigelpoulton/ddd-book:wasm /

Once running, the app behaves exactly like any other containerized web service and can be reached through the mapped port.

Conclusion

Docker's support for Wasm means developers can use the exact same tools — docker build, docker push, docker run, and standard OCI registries — to package and distribute Wasm apps as they already do for traditional containers. As the Wasm ecosystem continues to mature, this integration positions Docker to support both models side by side, letting teams choose the right tool for each workload.

Written & researched by Dr. Shahin Siami

Related Articles

How Docker Uses Linux Security Technologies: Namespaces, Cgroups, and More

Docker's security model is built on layered defense, combining well-established Linux kernel technologies with sensible defaults out of the box. This article explains how namespaces, control groups, capabilities, mandatory access control, and seccomp work together to isolate and secure containers.

Continue

Managing Persistent Data in Docker with Volumes

Containers get a temporary writable layer by default, which disappears the moment a container is deleted — fine for scratch data, but risky for anything worth keeping. This article explains how Docker volumes decouple persistent data from container lifecycles, and walks through creating, using, and sharing them safely.

Continue

How Docker Overlay Networks Work: VXLAN Under the Hood

Overlay networks let containers on different hosts communicate as if they shared a single flat network, forming the backbone of most cloud-native microservices apps. This article covers how to build, encrypt, and test a Docker overlay network across a Swarm cluster, and explains the VXLAN tunneling technology powering it behind the scenes.

Continue

Connecting Docker Containers to VLANs and Load Balancing with Swarm

Beyond basic bridge networks, Docker can connect containers directly to existing physical VLANs, resolve service names automatically, and distribute traffic across a Swarm cluster. This article covers the macvlan driver, Docker's built-in service discovery, and Swarm's ingress load balancing mesh.

Continue

Understanding Docker Networking: CNM, Libnetwork, and Bridge Networks

Docker networking is built on an open design called the Container Network Model, implemented through libnetwork and extended by pluggable drivers. This article covers the theory behind Docker networking and walks through creating and testing single-host bridge networks, including name resolution and port mapping.

Continue

Deploying and Managing Multi-Node Clusters with Docker Swarm

Docker Swarm turns a group of Docker nodes into a secure, highly available cluster with built-in application orchestration. This article covers building a multi-node swarm, deploying a microservices app declaratively, and performing rolling updates without losing desired-state consistency.

Continue
Previous ArticleNext Article