WebAssembly Container Runtimes: crun-wasm vs Spin vs wasmCloud (2026)

WebAssembly (Wasm) has evolved far beyond the browser. Today, it is a viable runtime for server-side workloads — offering near-native performance, instant startup times, and strong sandboxing. The container ecosystem has embraced Wasm through dedicated runtimes that treat WASM modules as first-class container images.

This guide compares three leading approaches to running WebAssembly in containerized environments: crun-wasm (the WASM mode of the lightweight OCI runtime), Spin (Fermyon’s developer-focused Wasm framework), and wasmCloud (CNCF’s polyglot cloud-native Wasm platform).

What Are WebAssembly Container Runtimes?

WebAssembly container runtimes bridge the gap between traditional OCI containers and WASM modules. Instead of running a full Linux userspace, they execute compiled WASM bytecode directly, eliminating the overhead of kernel syscalls, init processes, and unnecessary libraries.

Key advantages over traditional containers:

• Startup in milliseconds — no OS boot, no init process, direct bytecode execution
• Smaller images — WASM modules are typically kilobytes, not megabytes
• Stronger isolation — Wasm’s sandboxed execution model prevents arbitrary system access
• Language agnostic — compile from Rust, Go, TypeScript, C, and more to a universal format
• Lower resource footprint — no kernel namespaces needed; Wasm provides its own security boundary

The OCI ecosystem has formalized support through the runwasi project, which provides a shim layer allowing containerd, Kubernetes, and Docker to treat WASM workloads identically to Linux containers.

Comparison Overview

crun-wasm: Lightweight OCI Runtime with WASM Support

crun is a fast, lightweight OCI container runtime written in C. Its WASM mode (crun-wasm) uses Wasmtime as the underlying execution engine, allowing you to run WASM modules through the standard crun CLI and containerd shim.

How It Works

crun-wasm detects WASM modules by their magic bytes (\0asm) or by the io.container.wasm annotation. When a WASM module is detected, it bypasses the Linux namespace setup and invokes Wasmtime directly.

Installation and Setup

1
2
3
4
5
6
7
8

# Install crun with WASM support
sudo apt-get install -y crun
# Or build from source with WASM enabled
git clone https://github.com/containers/crun.git
cd crun
./autogen.sh
./configure --enable-wasm-wasmtime
make && sudo make install

Running a WASM Module via containerd

1
2
3
4
5

# /etc/containerd/config.toml
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.wasm]
  runtime_type = "io.containerd.wasm.v1"
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.wasm.options]
    BinaryName = "/usr/local/bin/crun"

1
2

# Run a WASM module through containerd
sudo crun run --bundle /path/to/wasm-bundle wasm-container

Docker Compose Configuration

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

version: "3.8"
services:
  wasm-app:
    image: ghcr.io/containerd/runwasi/wasm-example:latest
    runtime: io.containerd.wasm.v1
    ports:
      - "8080:8080"
    deploy:
      resources:
        limits:
          memory: 64M

Strengths and Limitations

Strengths:

• Zero additional overhead — integrates directly with existing container tooling
• Sub-5ms cold start — fastest among all compared runtimes
• Minimal footprint — crun binary is under 500 KB
• Full OCI compliance — works with any registry, any orchestrator

Limitations:

• Developer experience is CLI-focused — no built-in framework for app development
• Limited WASI API surface — not all WASI proposals are fully supported
• Requires containerd configuration — not as simple as docker run

Spin: Developer-First Wasm Application Framework

Spin, created by Fermyon, is a framework for building and running serverless Wasm applications. It provides a complete developer experience including SDKs for multiple languages, a local development server, and deployment tooling.

How It Works

Spin uses the Wasm Component Model and provides language-specific SDKs. Applications are built with spin build and run with spin up. The framework handles HTTP routing, key-value storage, and outbound HTTP requests through WASI interfaces.

Installation

1
2
3
4
5
6
7

# Install Spin CLI
curl -fsSL https://developer.fermyon.com/downloads/install.sh | bash
sudo mv ./spin /usr/local/bin/spin

# Create a new Spin app
spin new http-rust my-wasm-app
cd my-wasm-app

Application Structure

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# spin.toml
spin_manifest_version = 2

[application]
name = "my-wasm-app"
version = "0.1.0"
trigger = { type = "http", base = "/" }

[[trigger.http]]
route = "/..."
component = "my-wasm-app"

[component.my-wasm-app]
source = "target/wasm32-wasi/release/my_wasm_app.wasm"
allowed_outbound_hosts = ["https://api.example.com"]
[component.my-wasm-app.build]
command = "cargo build --target wasm32-wasi --release"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// src/lib.rs
use spin_sdk::http::{IntoResponse, Request, Response};
use spin_sdk::http_component;

#[http_component]
fn handle_my_wasm_app(req: Request) -> anyhow::Result<impl IntoResponse> {
    Ok(Response::builder()
        .status(200)
        .header("content-type", "text/plain")
        .body("Hello from Spin!")
        .build())
}

Docker Compose with Spin

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

version: "3.8"
services:
  spin-app:
    image: ghcr.io/fermyon/spin:latest
    volumes:
      - ./spin.toml:/app/spin.toml:ro
      - ./target:/app/target:ro
    ports:
      - "3000:3000"
    command: ["spin", "up", "--listen", "0.0.0.0:3000"]
    deploy:
      resources:
        limits:
          memory: 128M

Kubernetes Deployment with Kwasm

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

apiVersion: apps/v1
kind: Deployment
metadata:
  name: spin-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: spin-app
  template:
    metadata:
      labels:
        app: spin-app
      annotations:
        io.kubernetes.cri.untrusted-workload: "true"
    spec:
      runtimeClassName: wasmtime
      containers:
      - name: spin-app
        image: ghcr.io/fermyon/spin-app:latest
        ports:
        - containerPort: 3000
        resources:
          limits:
            memory: "128Mi"
            cpu: "100m"

Strengths and Limitations

Strengths:

• Excellent developer experience — SDKs for Rust, Go, Python, TypeScript, C#
• Built-in HTTP routing and key-value storage
• Local dev server with hot reload via spin watch
• Strong community and Fermyon Cloud integration
• Wasm Component Model support for interoperability

Limitations:

• Tied to the Spin SDK — apps must use Spin’s trigger model
• Less flexible for non-HTTP workloads (though background tasks are supported)
• Smaller ecosystem compared to traditional container frameworks

wasmCloud: Cloud-Native Polyglot Wasm Platform

wasmCloud is a CNCF project that provides a host runtime for Wasm actors with a capability-based security model. It uses a “lattice” architecture for distributed communication between Wasm components.

How It Works

wasmCloud actors are Wasm modules that declare their required capabilities (HTTP server, key-value store, message broker). The wasmCloud host provides these capabilities at runtime, enabling actors to be portable across environments without code changes.

Installation

1
2
3
4
5
6
7
8

# Install wasmCloud CLI (wash)
curl -sSf https://raw.githubusercontent.com/wasmCloud/wasmcloud/main/install.sh | bash

# Start a wasmCloud host
wash up &

# Create a new actor
wash new actor hello-world

Actor Definition

1
2
3
4
5
6
7
8

# wasmcloud.toml
name = "hello-world"
language = "rust"
type = "actor"
version = "0.1.0"

[actor]
claims = ["wasmcloud:httpserver", "wasmcloud:keyvalue"]

1
2
3
4
5
6
7
8
9

// src/lib.rs
use wasmcloud_actor_httpserver::{HandleRequest, HttpServer, HttpRequest, HttpResponse};
use wasmcloud_actor_core::Core;

impl HandleRequest for HelloActor {
    fn handle_request(&self, _req: HttpRequest) -> anyhow::Result<HttpResponse> {
        Ok(HttpResponse::ok("Hello from wasmCloud!", "text/plain"))
    }
}

Docker Compose Setup

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

version: "3.8"
services:
  wasmcloud-host:
    image: ghcr.io/wasmcloud/wasmcloud:latest
    ports:
      - "4000:4000"  # HTTP server
      - "4222:4222"  # NATS lattice
    environment:
      - WASMCLOUD_RPC_TIMEOUT_MS=5000
      - WASMCLOUD_CLUSTER_SEEDS
    deploy:
      resources:
        limits:
          memory: 256M

  nats:
    image: nats:latest
    ports:
      - "4222:4222"
      - "8222:8222"
    command: ["-js", "-m", "8222"]

Lattice Architecture

wasmCloud’s lattice is built on NATS messaging. Actors communicate through capability providers:

1
2

# Link an actor to the HTTP server provider
wash ctl link   --source MBSWASMCLOUDACTOR123   --target HTTPSERVER456   wasmcloud:httpserver   ADDRESS=0.0.0.0:4000

Strengths and Limitations

Strengths:

• Capability-based security — actors only access what they declare
• Lattice architecture enables distributed Wasm workloads
• Polyglot actors — any language that compiles to WASI
• CNCF graduation ensures long-term viability
• NATS-based messaging for async communication

Limitations:

• More complex architecture — requires NATS for the lattice
• Steeper learning curve than Spin
• Smaller community and fewer ready-made components
• Capability provider ecosystem is still growing

Deployment Architecture Comparison

Each runtime targets a different deployment scenario:

Why Self-Host WebAssembly Container Runtimes?

Running Wasm container runtimes on your own infrastructure provides significant advantages over managed cloud services.

Complete control over execution environment. When you self-host Wasm runtimes, you control the WASI API surface, capability grants, and network policies. Cloud-hosted Wasm platforms often restrict which WASI interfaces are available. Self-hosting means you can enable experimental features like WASI-NN (neural networks) or WASI-Crypto without waiting for cloud provider support.

Zero vendor lock-in. Wasm modules are inherently portable — the same .wasm file runs on crun, Spin, or wasmCloud. By self-hosting, you avoid proprietary extensions that tie you to a specific cloud provider. You can migrate from Fermyon Cloud to a self-hosted Spin instance, or from wasmCloud Cloud to your own lattice, with zero code changes.

Cost efficiency at scale. Wasm workloads consume dramatically less memory and CPU than equivalent containers. A Rust HTTP service in a Wasm runtime uses ~10 MB of memory compared to ~200 MB in a traditional container. Self-hosting multiplies these savings — no per-millisecond compute charges, no minimum instance sizes, no egress fees.

Security isolation without containers. Wasm provides sandboxed execution without requiring kernel namespaces, cgroups, or seccomp filters. Each Wasm module runs in its own sandbox with explicit capability grants. For multi-tenant environments, this means stronger isolation with less attack surface.

For related reading on container runtimes, see our OCI Container Runtimes comparison and WebAssembly Runtimes deep dive. If you are interested in container security, our Container Sandboxing guide covers gVisor, Kata Containers, and Firecracker.

Choosing the Right Wasm Container Runtime

Your choice depends on your primary use case:

• Choose crun-wasm if you want to run WASM workloads in existing Kubernetes clusters with minimal changes. It integrates with containerd and provides the fastest cold start times. Best for infrastructure teams managing mixed Linux+WASM workloads.

• Choose Spin if you are a developer building HTTP APIs, microservices, or serverless functions. The SDK experience is unmatched, and the local development workflow (spin new, spin build, spin up) is the most polished. Best for application teams shipping Wasm-based services.

• Choose wasmCloud if you need distributed Wasm workloads across multiple hosts with capability-based security. The lattice architecture and NATS-based messaging make it ideal for complex, multi-component systems. Best for platform teams building Wasm-based microservice architectures.

FAQ

Can I run WASM modules alongside Linux containers in the same Kubernetes cluster?

Yes. Both crun-wasm and Spin (via Kwasm) support running Wasm and Linux containers side by side. crun-wasm uses a separate containerd runtime class (wasm), while Kwasm adds a wasmtime RuntimeClass. You select the runtime per-pod using runtimeClassName. wasmCloud actors run on dedicated wasmCloud hosts, which can coexist with Kubernetes nodes.

How do Wasm container runtimes compare to Docker containers in terms of security?

Wasm provides stronger default isolation than Docker containers. While Docker relies on kernel namespaces, cgroups, and seccomp (which can be bypassed via kernel vulnerabilities), Wasm modules execute in a sandboxed virtual machine with no direct system call access. All I/O goes through WASI interfaces, which are explicitly granted. However, Wasm’s security depends on the correctness of the Wasm engine (Wasmtime, wasmer, etc.).

What programming languages can I use with these Wasm runtimes?

Any language that compiles to WebAssembly with WASI support. Rust has the best tooling via wasm32-wasi and wasm32-wasip1 targets. Go supports WASI via GOOS=wasip1 GOARCH=wasm. Python works via Pyodide or WASI-compatible interpreters. TypeScript/JavaScript compiles via Javy or AssemblyScript. C/C++ compile via Emscripten or Clang’s WASI target.

Can Wasm container runtimes replace Docker containers entirely?

Not yet. Wasm excels at compute-heavy, stateless workloads (HTTP APIs, data processing, serverless functions). But Wasm does not support arbitrary Linux binaries, GPU passthrough, or full system emulation. For workloads requiring a full Linux userspace, traditional containers remain necessary. The future is likely hybrid: Wasm for lightweight workloads, containers for everything else.

How does the Wasm Component Model affect these runtimes?

The Wasm Component Model (WIT/WASM) enables interoperability between Wasm modules from different languages and frameworks. Spin has early Component Model support, wasmCloud uses a component-based actor model, and crun-wasm relies on Wasmtime which implements the Component Model. Over time, this will enable mixing and matching Wasm components regardless of source language or framework.

What is the performance overhead of Wasm compared to native binaries?

Wasm typically runs at 80-95% of native performance for compute-heavy workloads. The overhead comes from bounds checking, register allocation, and the Wasm-to-native JIT compilation. For I/O-bound workloads (HTTP, database queries), the difference is negligible because the bottleneck is external. Cold start times are dramatically faster than containers — milliseconds versus seconds.