Docker’s co-founder Solomon Hykes once remarked that if WebAssembly and WASI had existed in 2008, Docker might never have been created. The observation was half-provocative — Docker is clearly not going away — but it captures something true about what WebAssembly offers as an execution substrate: a portable, sandboxed binary format with startup characteristics that containers cannot match, and an isolation model that does not depend on a Linux kernel.

At the edge, those properties matter more than they do in a conventional datacenter. When a request arrives at one of hundreds of globally distributed PoPs, the runtime must be ready in microseconds, not seconds. The operational model that works well for long-lived containers in a regional data center is a poor fit for ephemeral, per-request computation that spans the globe. WebAssembly was not designed for this use case — it was designed for the browser — but the same properties that made it attractive there translate, with the right system interface, to the edge. The choice of execution unit is only one layer of a broader placement question — where AI and general compute workloads should physically run is a separate, adjacent decision that Wasm’s startup-latency and density advantages make more practical to resolve in the edge’s favor for a wider set of workloads than containers alone could support.

What WASM Brings That Containers Cannot

The startup latency gap is the most legible difference. A container — even a pre-warmed one — requires a Linux process namespace, a cgroup assignment, and, if cold, image layer fetching and overlay filesystem setup. Cold starts for container-based serverless functions run in the range of 50 to 500 milliseconds, depending on image size and runtime. A WebAssembly module, by contrast, initializes in one to five milliseconds. Cloudflare Workers, which runs Wasm workloads across its network using V8 isolates, has effectively eliminated the cold-start problem for its edge workloads: a new isolate can be provisioned in under a millisecond, at any of its 300-plus locations, on demand.

Memory footprint follows a similar pattern. A minimal container image carrying a language runtime still starts at tens of megabytes. A Wasm module for the same function can operate in under one megabyte. At the edge, where a single physical machine may serve thousands of concurrent tenants, the density difference is material.

The security model is also structurally different. Containers share the host kernel; the isolation boundary is the kernel’s namespace and capability machinery, which has a long history of escape vulnerabilities. Wasm executes in a capabilities-based sandbox: it cannot access memory outside its linear memory space, cannot call host functions it has not been explicitly granted, and cannot perform I/O except through well-defined interface imports. This is not theoretical — it is the design. The module cannot do what the host has not permitted, and that permission is expressed at the API level, not through kernel access controls that can be misconfigured.

WASI and the Component Model: From Browser Toy to Production Runtime

The gap between “runs in a browser” and “runs on a server” was, for years, the reason WebAssembly remained interesting but not deployed outside CDNs. Browser Wasm has no filesystem, no networking, no process model — it operates in whatever the host JavaScript environment provides. For server-side and edge workloads, a standard system interface was needed.

The WebAssembly System Interface (WASI) is that standard. Managed by the Bytecode Alliance, WASI defines a set of capability APIs — filesystem access, sockets, clocks, random number generation — that host runtimes can implement. A Wasm module targeting WASI can be compiled from any language with a WASI target (Rust, C/C++, Go, Python, and a growing list of others) and run on any conformant runtime.

WASI 0.2 (Preview 2), stabilized in January 2024, was the release that moved the project from promising to usable. It introduced the Component Model: a composition system that lets Wasm modules express typed import and export interfaces, enabling multiple components to be composed into a larger application while maintaining per-component sandboxes. This is the architectural feature that matters most for distributed systems: rather than a monolithic process, an application can be built from independently sandboxed components that communicate through defined interfaces, each replaceable and auditable. WASI 0.3 followed with native async I/O support, resolving the last major ergonomic gap for network-heavy workloads.

Production runtimes — Wasmtime (Bytecode Alliance), WasmEdge, Wasmer — now implement WASI 0.2, with WASI 0.3 support shipping through 2026. Cloudflare Workers, Fastly Compute, and Akamai (which acquired Fermyon in 2025 to integrate Spin-based Wasm workloads into its edge network) are running WASI-based workloads in production at global scale.

The Distributed Systems Research Angle

The shift from container to Wasm-based execution at the edge is, at a structural level, a reappearance of problems that distributed-systems research spent decades studying: how do you schedule small, short-lived units of computation across a federation of heterogeneous nodes, with hard latency constraints, while preserving isolation between tenants?

Grid computing and early cluster-management research addressed the scheduling and resource-management parts of this problem with job-centric models. What WebAssembly changes is the unit itself. The container model imports the Unix process abstraction — with its filesystem, environment variables, signals, and full system-call surface — into the scheduling unit. Wasm’s unit is smaller, more constrained, and more portable. The scheduler’s job becomes simpler when the execution unit makes fewer assumptions about the host environment.

Topology-aware placement, which was a core concern in grid middleware — where to run a job given network proximity, data locality, and resource availability — reappears in edge Wasm deployments as the question of which PoP to instantiate a module at, given where the user request originated and what data the module needs to access. The vocabulary has changed; the structural problem is continuous with earlier distributed-systems research. That continuity is a useful reminder that a change in execution substrate does not retire the underlying resource-placement research — it just changes which properties of the workload the scheduler has to reason about most closely.

Where the Limits Are

The case for Wasm at the edge is strongest in a specific set of workloads: request-handling functions that are stateless or near-stateless, written in languages with mature Wasm compile targets, that do not require the full surface of POSIX or Linux system calls. For these workloads — API middleware, authentication logic, content transformation, lightweight inference — the startup-latency and memory-density advantages are large, and the sandboxing model provides strong multi-tenant isolation.

The case weakens rapidly outside that envelope. Long-lived stateful services, workloads that depend on mature Linux tooling with no Wasm port, applications that require operating-system-level debuggers and profilers, and anything that needs direct access to hardware — GPUs, custom accelerators, persistent block devices — remain in container or VM territory. Wasm’s sandbox is also, by design, not a general-purpose operating system: the WASI surface is growing but not yet comprehensive. Programs that lean heavily on POSIX semantics often require shim layers that partially undermine the portability argument.

The debugging and observability tooling for Wasm is improving but remains behind the container ecosystem. DTrace, perf, strace, and the full complement of Linux performance analysis tools do not apply inside a Wasm sandbox. For teams that depend on those tools, the operational transition is non-trivial.

The Coexistence Pattern

The emerging deployment pattern is not “Wasm replaces containers” as a categorical statement — it is a differentiated runtime stack where the choice of execution unit is workload-specific. The major cloud providers and CDN platforms now support both. Docker Desktop can run Wasm workloads alongside Linux containers through integration with the containerd runtime and a set of Wasm shims. Kubernetes can be extended with Wasm-capable runtimes through the Container Runtime Interface.

In this pattern, containers handle long-lived services, stateful databases, workloads that require the full Linux environment, and anything that benefits from the container ecosystem’s decade of tooling investment. Wasm handles the edge-facing, latency-sensitive, high-tenancy functions where startup time and isolation density matter. Kubernetes itself can be extended with Wasm-capable runtimes through the Container Runtime Interface — a practical illustration of how far the orchestrator’s extensibility model has come since its own first decade as a container-only substrate.

The displacement thesis — that Wasm will eventually subsume containers in cloud-native architectures — rests on continued progress in WASI coverage, language toolchain support, and debugging infrastructure. That progress is real and ongoing. What Hykes identified in 2019 was not that Docker would be replaced soon, but that the fundamental abstraction — a portable, sandboxed unit of computation — is better served by a design like WebAssembly than by lifting Unix processes into a container. That argument is being tested in production, at scale, at the edge, right now.

Frequently Asked Questions

Is WebAssembly replacing Docker containers?

Not categorically. WebAssembly is displacing containers for specific workloads — stateless, latency-sensitive edge functions — where startup speed and sandbox density matter most. Long-lived services, stateful databases, and workloads needing the full Linux environment remain container or VM territory. The emerging pattern is coexistence on a shared stack, not a wholesale replacement.

What is WASI and why does it matter outside the browser?

WASI (WebAssembly System Interface) is the Bytecode Alliance’s standard set of capability APIs — filesystem, sockets, clocks — that let a Wasm module run outside a browser sandbox. Without WASI, WebAssembly had no server-side system interface. WASI 0.2’s Component Model, stabilized in January 2024, made composable, production-grade server and edge deployments practical for the first time.

Why is WebAssembly faster than containers at the edge?

A Wasm module initializes in one to five milliseconds versus 50-500 milliseconds for a container, because it skips Linux process namespace setup, cgroup assignment, and image-layer fetching entirely. Its memory footprint is also far smaller — under a megabyte versus tens of megabytes for a minimal container — which matters when a single edge machine serves thousands of tenants.

Can a WebAssembly module access the filesystem or make network calls?

Only through WASI’s explicitly granted capability imports — a Wasm module cannot perform I/O, access memory outside its own linear memory space, or call host functions it has not been given permission to call. This capabilities-based sandbox is a structural security property, not a configuration setting, unlike the kernel-namespace isolation containers depend on.

What workloads should NOT move to WebAssembly?

Long-lived stateful services, workloads requiring mature Linux tooling with no Wasm compile target, anything needing direct GPU or hardware-accelerator access, and applications that depend on OS-level debuggers and profilers (strace, perf, DTrace) still belong in containers or VMs — WASI’s system-call surface, while growing, is not yet a general-purpose OS replacement.

Further Reading

Back to Blog