Skip to content
Blog

Can WebAssembly Replace Containers? An Industry Analysis

Six industry leaders weigh in on the Wasm vs. containers debate: where WebAssembly clearly wins — edge, plugins, serverless — and where containers remain unbeatable for the next decade.

Published on • November 15, 2026

AI Assistant

The question “Will WebAssembly replace containers?” has become the most asked — and least precisely answered — question in cloud-native computing. It was ignited by a single 2019 tweet from Solomon Hykes, co-founder of Docker: “If WASM+WASI existed in 2008, we wouldn’t have needed to have created Docker.” Six years later, InfoWorld gathered six practitioners — Matt Butcher (Fermyon), Michael J. Yuan (Second State), Bailey Hayes (Cosmonic), Luke Wagner (Fastly), Solomon Hykes (Dagger), and Colin Murphy (Adobe) — and found the industry split: Wasm wins some battles decisively, but wholesale replacement of the container ecosystem remains, in Hykes’ own revised words, something that “will never happen.” This analysis breaks down where each technology wins, and why the two are converging rather than competing.

The Hykes tweet, corrected

The famous tweet is regularly misread as a prediction that Wasm would kill Docker. Hykes himself has walked it back publicly: the tweet was widely misunderstood, Docker now exists as a standard, and Wasm plus WASI has “a very different shape. It’s not at all a replacement.”

His reasoning is structural: “If you’re talking about replacing containers, you have to talk about replacing Linux.” Containers are a core feature of Linux — not just the kernel, but the operating system layer, the standard stack around it, and the standard way you run Linux in the data center. The only open question, Hykes argues, is whether you add a layer on top. That framing — Wasm as a layer, not a successor — is where most of the industry has landed.

Where Wasm beats containers

Edge and constrained devices

Michael J. Yuan puts it plainly: “We need software isolation on the edge, but containers consume too many resources.” Containers take megabytes or gigabytes; a .wasm file is kilobytes to a few megabytes and is agnostic to the runtime and CPU architecture. Bailey Hayes notes that a single Wasm binary runs across cloud, edge, and resource-constrained devices without per-architecture builds — a real advantage over multi-arch container images.

Concrete deployments exist. MachineMetrics runs wasmCloud on factory floors to process high-velocity machine data from CNC machines, isolating untrusted plugin code where a full container runtime is impractical. LlamaEdge, built on WasmEdge, serves large language model inference across heterogeneous GPUs — something containers handle poorly because images don’t port across accelerator hardware.

Serverless functions and cold starts

Luke Wagner, who co-designed the original WASI proposal at Fastly, argues Wasm brings cost savings and cold-start improvements to serverless-style workloads, and that “we do expect many workloads to be migrated from containers to Wasm” — especially greenfield ones. Because a Wasm module starts in milliseconds without an init system, package manager, or image layers, it fits the ephemeral, scale-to-zero profile of functions far better than a container image does. Enterprises wanting to avoid lock-in to proprietary serverless platforms are an explicit target.

Sandboxed plugins

Perhaps Wasm’s least-hyped but most mature server-side win is plugin systems. Containers are “generally not considered the right choice for safe sandboxing and isolation of arbitrary user code,” as Hayes notes — a container shares the host kernel, and root-in-container escapes are a recurring CVE class. Wasm’s capability-based sandbox grants nothing by default.

That’s why Istio WasmPlugin, Envoy’s Wasm extension mechanism, and Shopify Functions all chose Wasm for third-party code: the platform can run community-supplied logic without trusting it. Hykes sees the same for server-side applications generally — highly sandboxed plugins are a natural fit.

Component-based architectures

The WebAssembly Component Model lets modules compiled from Rust, Go, C#, and JavaScript link to each other directly through WIT interfaces, without HTTP in between. Butcher frames the promise as assembling applications from isolated components, with “potential for Wasm to supersede containers simply because containers won’t add value to component-based applications.” Whether that paradigm becomes dominant is the real long-term wager.

Where containers beat Wasm

Stateful, long-running processes

“Stateful, long-running compute and appliances like databases are unlikely to be replaced with Wasm,” says Hayes. Butcher is blunter: “Wasm is not great for long-running server processes… The sweet spot for containers is packaging and executing existing long-running servers (like Postgres or WordPress or your company’s enterprise Java app). I don’t foresee Wasm challenging that space in the next decade.”

The blockers are concrete: historically weak thread support, limited socket support, and languages whose runtimes assume OS primitives the Wasm sandbox doesn’t expose. Butcher adds that “the vast majority of large code bases can’t simply be compiled to WebAssembly. Code must be rewritten” — a cost many organizations won’t pay.

Linux and the installed base

Containers are intrinsic to Linux and to the surrounding standard stack. Hykes is explicit: “They will always be there.” Even Cloudflare — the poster child of post-container platforms — runs containers at the core of Workers: GPU inference, headless browser rendering, and build jobs all run as containers under the hood. If the edge-native leader can’t eliminate containers, a general-purpose replacement looks remote.

There’s also a performance floor: Wagner notes “there will usually be a modest runtime overhead executing Wasm versus native code, and for some workloads, any overhead at all may be unacceptable.” And Yuan, whose project WasmEdge is a CNCF runtime, still says “in most of today’s cloud-native applications, Linux containers are the right tools, and they should not be replaced.”

The convergence: Wasm and containers together

The most credible near-term future is hybrid, and the plumbing already exists:

  • Wasm inside containers: build a Wasm module into a lightweight OCI image and run it with Podman, OpenShift, or Docker’s containerd Wasm shims — reusing existing registries, admission controllers, and policy engines.
  • Wasm beside containers on Kubernetes: SpinKube, runwasi, and RuntimeClass-based scheduling let a cluster run Spin apps and Postgres pods side by side, with the same Services, probes, and autoscaling.
  • Containers hosting Wasm plugins: Envoy, Istio, and application frameworks keep containers as the unit of deployment while Wasm sandboxes the extension code.

Some have predicted Wasm runtimes will replace container runtimes by 2030; the experts consulted here disagree. Butcher’s summary of the trajectory is the most balanced: “Wasm may not replace containers feature for feature, but there’s certainly potential for Wasm to supersede containers simply because containers won’t add value to component-based applications.”

The verdict

Expect smaller, faster Wasm to elbow out containers for an increasing number of greenfield workloads — edge functions, plugin systems, event-driven jobs, AI inference endpoints. Expect containers to keep running the long-lived, stateful, Linux-bound majority of production for at least another decade. The honest industry answer to “Can Wasm replace containers?” is: for some workloads it already has, for most it won’t need to, and for the rest the two will run in the same cluster, scheduled by the same control plane.

References

webassembly containers kubernetes cloud-native serverless