WebAssembly on the server: hype or future?

In 2019, Docker co-founder Solomon Hykes posted something that's been quoted ever since: if WebAssembly and WASI had existed in 2008, they wouldn't have needed to create Docker. That's a big claim. Several years later, where does server-side WebAssembly actually stand?

Wasm outside the browser

WebAssembly (Wasm) started as a way to run fast, compiled code in web browsers: games, video editors, design tools. It's a compact binary format that many languages (Rust, C/C++, Go, C#, Zig, and others) can compile to, and that runs in a sandboxed virtual machine.

The properties that make it great in browsers turn out to be interesting on servers too:

• Fast startup: modules start in microseconds to milliseconds, much faster than containers.
• Small: modules are often kilobytes to a few megabytes.
• Secure by default: a Wasm module can't access files, network or anything else unless explicitly granted. A strong sandbox.
• Portable: the same module runs on any OS and CPU architecture with a Wasm runtime.

To work outside the browser, Wasm needs a way to talk to the system: files, clocks, sockets. That's WASI (WebAssembly System Interface). WASI 0.2 introduced the Component Model, which lets Wasm components written in different languages work together through well-defined interfaces. Further versions are adding async support and more.

Containers package an operating system around your app. Wasm packages just your app, and asks permission for everything else.

Running it on Kubernetes

Wasm doesn't have to replace your platform. It can run alongside containers:

• containerd shims (like those from the runwasi project) let Kubernetes run Wasm workloads through a normal RuntimeClass. A pod can run a Wasm module instead of a container image.
• SpinKube runs apps built with Spin (from Fermyon) on Kubernetes, with very high density and fast scaling.
• wasmCloud (a CNCF incubating project) is a platform for distributed Wasm applications across clouds, edge and Kubernetes.
• Wasm modules can be stored in OCI registries, just like container images.

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: wasmtime-spin
handler: spin
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-wasm
spec:
  replicas: 3
  selector:
    matchLabels: { app: hello-wasm }
  template:
    metadata:
      labels: { app: hello-wasm }
    spec:
      runtimeClassName: wasmtime-spin
      containers:
      - name: hello
        image: ghcr.io/acme/hello-wasm:1.0.0
        command: ["/"]

Where it fits

Wasm is already in production in places you might not notice:

• Edge computing: Cloudflare Workers, Fastly Compute and other edge platforms run Wasm (or similar isolates) because of fast startup and strong isolation. Code runs close to users with almost no cold start.
• Plugins and extensions: Envoy proxy filters, database extensions, and tools like Helm 4's plugin system use Wasm to run third-party code safely.
• Serverless functions where cold starts matter.
• Multi-tenant platforms that need to run untrusted user code safely.
• IoT and embedded devices with limited resources.

Where it doesn't, yet

• Ecosystem maturity: many libraries, especially those relying on threads, networking or system calls, don't fully work in WASI yet. It's improving release by release.
• Language support varies: Rust is excellent; other languages are good but with caveats; some popular languages still have rough edges.
• Tooling and debugging are less mature than for containers.
• Existing apps: rewriting or recompiling a large existing application for Wasm rarely makes sense. Containers run any Linux software today.
• Long-running, heavy workloads: containers are still the natural fit.

So, hype or future?

Both, honestly. Wasm won't replace containers for most workloads any time soon. Containers solved a huge problem and they're everywhere. But Wasm is clearly the future for specific areas: edge, plugins, high-density serverless and safe execution of untrusted code. Those areas are growing.

For DevOps engineers, it's worth understanding now: how it runs on Kubernetes, how it's packaged in OCI registries, and where it might show up in your stack.

My take: Wasm isn't the next container. It's the thing you'll reach for when a container is too heavy, too slow or too trusting.

— Desly