WASI 0.2 Preview 2 reached GA in January 2024, and with it the WebAssembly Component Model arrived in production. This is a decisive milestone: server-side WebAssembly moves from experiment to a platform capable of running composable polyglot code. This article covers what practically changes, when server-side Wasm makes sense, and what cases are viable today.

Key takeaways

  • The Component Model resolves the cross-language portability that was blocking Wasm adoption outside the browser.

  • For edge functions with critical cold start, secure plugins, and untrusted-code sandboxing, Wasm is already viable today.

  • For traditional apps, Wasm does not replace containers: it complements them.

  • Rust is the lowest-friction language for Wasm components; others are closing the gap.

  • Sub-1 ms cold start vs. 100–1000 ms for a container is the differential advantage on the edge.

What the Component Model is

Before WASI 0.2, server-side WebAssembly was Preview 1: Unix-like syscalls and isolated modules. Every integration was manual and a module’s code could not compose with another’s without ad-hoc glue code.

Preview 2 Component Model adds:

  • WIT (WebAssembly Interface Types): cross-language interface definitions with static types.

  • Components: reusable composition unit, like Rust crates or npm packages but multi-language.

  • Dependency injection: components consume interfaces, pluggable at load time.

  • Type safety across language boundaries.

The result: write one component in Rust, another in Go, another in JavaScript, and compose them without manual glue code. Each compiles to .wasm; the host assembles them.

WIT interface example

package example:greeter@1.0.0;

interface greeter {
    greet: func(name: string) -> string;
}

world host {
    export greeter;
}

Any language compiling to a Wasm component can implement or consume this interface. The toolchain validates types at compile time; integration errors are caught before deployment.

Viable real cases today

Edge serverless

Fastly Compute[1], Cloudflare Workers[2] with Wasm, and Fermyon Spin[3] use server-side Wasm for:

  • Sub-1 ms cold start versus 100–1000 ms for a cold container.

  • Strict sandboxing without OS privileges.

  • Multi-runtime portability without recompiling.

  • Massive scaling without persistent state.

Secure plugins for host applications

A host application can load Wasm components as plugins without privileged access:

Plugins are portable between runtimes without recompiling and without host system access.

IoT and embedded

Wasm runs on devices with kilobytes of memory:

  • wasm-micro-runtime[7] (WAMR): for highly resource-constrained IoT.

  • Customisable firmware without reflashing.

  • Sandbox for third-party code on industrial devices.

Main runtimes

[8]

[9]

[10]

[3]

Runtime Focus Notes
Wasmtime Bytecode Alliance reference Safest default
Wasmer Commercial + OSS Broad ecosystem
WasmEdge Cloud-native CNCF, K8s focus
Fermyon Spin Serverless Wasm Complete framework

Language support

Maturity varies by language:

  • Rust: first-class citizen. cargo-component generates components with minimal friction.

  • C/C++: via wasi-sdk, mature.

  • Go: TinyGo supports Wasm with some limitations vs. full Go.

  • JavaScript: via Javy (for edge) and Componentize-JS.

  • Python: experimental via componentize-py.

  • .NET: emerging support.

Rust is the lowest-friction path today. For greenfield, start there.

Wasm versus containers

Not a replacement; a complement for specific cases:

Aspect Wasm component Container
Cold start <1 ms 100 ms–1 s
Size KB–MB MB–GB
Isolation Very strong Good
Ecosystem Emerging Massive
OS access Limited (safer) Full

For edge functions, plugins and sandboxing, Wasm wins on cold start and isolation. For traditional apps with OS dependencies, containers remain the correct default.

Kubernetes and Wasm

K8s integration matures through:

  • runwasi[11]: containerd runtime to run Wasm components directly.

  • kwasm[12]: operator to enable Wasm on K8s nodes without changing the base runtime.

Running Wasm on K8s without containers is possible today, especially for edge-adjacent workloads like Fastly Compute.

Current limitations

  • Ecosystem still emerging: the catalogue of third-party libraries with Wasm bindings is still small.

  • Debugging: harder than native or container.

  • Async: improving with WASI 0.3 on the roadmap, but not complete.

  • GC languages: Java, C#, Python are less efficient when compiling to Wasm.

When to use Wasm today versus when to wait

Use today:

  • Edge functions where cold start is critical for UX.

  • Secure plugins for platforms where code is third-party.

  • Untrusted-code sandboxing (AI, user scripting).

  • Cross-platform portability (same binary on Mac, Linux, Windows, ARM, x86).

Wait:

  • Traditional web apps with no clear advantage over containers.

  • Disk- or network-intensive stateful workloads.

  • Heavy computation where native or GPU remain better.

Conclusion

WASI 0.2 GA is the inflection point where server-side WebAssembly stops being a promise. The Component Model resolves the cross-language portability that was blocking adoption. For teams building edge functions, platforms with plugins, or systems sandboxing third-party code, Wasm is already a technically solid choice. For the rest, it is a technology to follow closely.

Convergence with Kubernetes through runwasi and adoption by Cloudflare Workers are clear signals the ecosystem is consolidating.

Frequently asked questions

Does WebAssembly with WASI 0.2 replace containers in production?

No: it complements them in specific cases. A Wasm component cold-starts in under 1 ms versus 100 ms-1 s for a container, weighs KB-MB instead of MB-GB, and offers stronger isolation with limited OS access. That makes it the winner for edge functions, plugins and untrusted-code sandboxing. For traditional apps with OS dependencies, disk- or network-intensive stateful workloads and heavy computation, containers remain the correct default.

Which language should I start writing Wasm components in?

Rust, which is the lowest-friction path today: cargo-component generates components as a first-class citizen. C/C++ is mature via wasi-sdk and Go works through TinyGo, with some limitations versus full Go. JavaScript goes through Javy for the edge and Componentize-JS; Python is experimental via componentize-py and .NET support is emerging. GC languages such as Java, C# or Python are also less efficient when compiled to Wasm.

Can I run Wasm components on Kubernetes without containers?

Yes, it is possible today: runwasi is a containerd runtime that runs Wasm components directly, and kwasm is an operator that enables Wasm on cluster nodes without changing the base runtime. It fits edge-adjacent workloads best. Keep the current limitations in mind: the catalogue of third-party libraries with Wasm bindings is still small, and debugging is harder than native or container. Async support will not be complete until WASI 0.3.

Sources

  1. Fastly Compute
  2. Cloudflare Workers
  3. Fermyon Spin
  4. Envoy Wasm filters
  5. Proxy-Wasm
  6. Istio WebAssembly plugins
  7. wasm-micro-runtime
  8. https://wasmtime.dev/
  9. https://wasmer.io/
  10. https://wasmedge.org/
  11. runwasi
  12. kwasm