WebAssembly vs Containers: Stateless Compute Boundary

Two services perform the same small piece of work. One is packaged as a container image and starts as an operating-system process. The other is compiled into a WebAssembly module and instantiated inside an already-running runtime.

The second service can become ready dramatically faster. But the honest comparison is not “two seconds versus one millisecond” as a universal law. Startup time depends on image locality, runtime initialization, language choice, compilation strategy, host configuration, and what is included in the measurement. The architectural difference is real; a single benchmark number is not.

That distinction captures the state of server-side WebAssembly in 2026. Wasm is not replacing Docker, Kubernetes, or Linux containers. It is establishing a narrower—and increasingly credible—execution class for short-lived, stateless, multi-tenant, and edge-oriented code.

In 2019, Docker co-founder Solomon Hykes wrote that if WebAssembly and WASI had existed in 2008, Docker might not have been necessary. The remark was intentionally provocative, but it pointed to a genuine overlap: both technologies package software for portable execution. They simply draw the isolation boundary in different places.¹

The useful question, therefore, is not “Will Wasm kill containers?” It is:

The central mental model: process package versus sandboxed program

A container packages an application so that it can run as an isolated process on a host operating system. A typical image contains the application plus some combination of a language runtime, shared libraries, certificates, configuration, and filesystem content. Containers share the host kernel and rely on mechanisms such as namespaces, cgroups, Linux capabilities, seccomp, and mandatory access controls for isolation.

A container does not necessarily contain an entire operating system, an init system, or a package manager. Minimal and distroless images deliberately exclude much of that. Even so, the container abstraction remains closely tied to an operating-system process and the host kernel.

A WebAssembly module is different. Wasm is a compact, portable instruction format for a virtual machine. Core Wasm defines validated code, linear memory, functions, tables, and imports and exports. It does not include an operating system. The host runtime decides which external capabilities the guest can use.²

The same portable module can, in principle, run across x86-64, Arm, and other architectures—including RISC-V—when a compatible runtime and host interfaces exist. That can remove the need to build a separate guest binary for every CPU architecture. It does not guarantee that every application is automatically portable: native dependencies, target-specific assumptions, and differences in runtime or WASI support can still require separate build or validation work.

A useful analogy is:

• A container is a furnished apartment. It brings much of the environment the application expects.
• A Wasm module is an appliance with a precise power connector. It brings less environment and can use only the interfaces the host provides.

That smaller contract can improve startup time, density, portability, and isolation. It can also reduce compatibility: software that expects unrestricted POSIX behavior, arbitrary native libraries, background daemons, or a conventional Linux filesystem may require changes or may simply be a poor fit.

What changes when the operating-system layer is removed?

Dimension	Linux container	Server-side WebAssembly
Execution unit	Isolated host process	Module or component inside a Wasm runtime
Kernel relationship	Shares and invokes the host kernel	Reaches host services through runtime-provided imports
Packaged environment	Application plus required user-space files and runtimes	Compiled guest code plus declared interfaces and dependencies
Startup profile	Often tens of milliseconds to seconds, depending heavily on image and application initialization	Often microseconds to low milliseconds on optimized or precompiled platforms; workload-dependent
Default host access	Constrained by the container and host security configuration	No ambient filesystem or network access in core Wasm; capabilities must be exposed by the host
Compatibility	Excellent for existing Linux software	Best for code and libraries that support the selected Wasm/WASI target
Natural fit	Long-running services, existing applications, databases, brokers, GPU and OS-integrated workloads	Event handlers, edge functions, extension systems, untrusted plugins, and small stateless services

These are architectural tendencies, not guaranteed measurements. A tiny, cached native container may start quickly. A large Wasm component with expensive initialization may not. Always measure the complete request path on the platform you intend to operate.

Why startup can be so fast

Container startup may involve some combination of pulling an image, unpacking layers, creating namespaces and cgroups, mounting filesystems, starting a process, loading a language runtime, and initializing the application. Not every cold start includes every step: image caching, snapshots, lazy loading, and warm pools can remove much of the overhead.

A Wasm platform can take a shorter path. It can load a compact artifact, validate or use prevalidated code, compile it or restore precompiled state, instantiate memory, connect declared imports, and invoke an exported function. Optimized edge platforms can keep the Wasm runtime warm while creating a fresh sandbox for each request.

Fastly, for example, documents a per-request WebAssembly sandbox model and describes microsecond startup for its optimized Compute runtime. That is strong evidence that extremely fast instantiation is possible—but it is a property of an engineered platform, not a promise attached to every .wasm file.³

This matters most when work is:

• bursty and frequently scales from zero;
• short-lived enough that initialization is a meaningful share of total latency;
• replicated across many tenants or edge locations;
• isolated per request or per plugin invocation;
• small enough that network and backend latency do not dominate the experience.

For a service that runs continuously for weeks, saving 100 milliseconds at process startup may be irrelevant. For a function created for every request, it may define the platform’s economics and responsiveness.

Security: a smaller authority surface, not a magic shield

The strongest argument for Wasm is often not speed. It is the execution contract.

Core WebAssembly code cannot spontaneously open a host file, connect to a network destination, read an environment variable, or call the system clock. It can use only functions and resources imported from its host. WASI and vendor-specific host APIs make useful I/O possible, while the host decides what to expose.²⁴

This supports a capability-oriented model:

1. The guest starts without ambient authority over the host.
2. The host exposes a specific interface or resource.
3. The guest can use that capability only through the interface it received.

That model is attractive for plugin systems and multi-tenant execution. Shopify’s use of Wasm for Functions is a familiar example of the general pattern: merchant-defined logic runs inside a constrained execution environment rather than as an unrestricted process.⁵

However, “sandboxed” does not mean “invulnerable.” The runtime, compiler, host functions, embedding application, and supply chain remain part of the trusted computing base. A poorly designed host function can grant excessive authority. A runtime vulnerability can break isolation. Denial-of-service controls still require limits on CPU, memory, execution time, recursion, and outbound activity.

Containers are also not permissive by definition. A hardened container can drop Linux capabilities, use seccomp and AppArmor or SELinux, run as a non-root user, expose a read-only filesystem, and apply network policy. Wasm changes the default programming and authority model; it does not eliminate the need for defense in depth.

The standards stack that made server-side Wasm practical

“WebAssembly” now refers to several related layers. Keeping them separate prevents a great deal of confusion.

1. Core WebAssembly

Core Wasm is the portable instruction format and execution semantics. WebAssembly 3.0 became the live standard on September 17, 2025. It added major capabilities including 64-bit memories, multiple memories, garbage-collected types, typed references, exception handling, and other long-running proposals.⁶

Garbage collection is important for languages with managed object models, but it does not instantly make every Java, Kotlin, Dart, or Scala application portable. Language toolchains, libraries, runtime conventions, and host interfaces still determine what works in practice.

Core Wasm also has standardized thread support in major engines. The more accurate limitation is that portable server-side threading through WASI and the Component Model is still evolving, and individual platforms may deliberately prohibit threads. The WASI roadmap lists cooperative and later preemptive threads as work following WASI 0.3.⁷

2. WASI

WASI—the WebAssembly System Interface—defines standard interfaces through which components can interact with clocks, files, streams, HTTP, and other host services without assuming a particular operating system.

WASI 0.2, released in January 2024, established a stable component-oriented baseline. WASI 0.3.0 was released on June 11, 2026 and added native asynchronous operations to the Component Model, including async functions, streams, and futures. Runtime and language support will continue to arrive at different speeds, so “the specification exists” and “my toolchain supports it end to end” are separate claims.⁴⁷

3. The Component Model

Core modules exchange low-level Wasm values. Real applications need strings, records, variants, resources, errors, and versioned interfaces. The Component Model adds these higher-level contracts and uses WebAssembly Interface Type (WIT) definitions to describe what a component imports and exports.⁸

This enables components written in different languages to interoperate through generated bindings and a shared canonical ABI. Think of it as a strongly typed, language-neutral plug system.

But “no glue code and no serialization tax” overstates the case. Tooling can generate the glue, and the Canonical ABI can make boundaries efficient, but values still need to be lifted and lowered between language representations and component interfaces. Composition reduces integration friction; it does not make boundaries free.

Language support and runtime choices

The source material correctly highlights that server-side Wasm is an ecosystem, not a single runtime. The major choices optimize for different environments:

• Wasmtime is the Bytecode Alliance runtime and a leading implementation of WASI and the Component Model. Its documentation covers ahead-of-time compilation, fast instantiation, async host functions, multithreaded embedding, debugging, and resource controls.⁹
• WasmEdge targets cloud-native, edge, embedded, and AI-oriented scenarios. Its footprint depends on the build, enabled features, and target platform, so a universal “under 100 KB” claim is not a useful architecture guarantee.¹⁰
• Wasmer is another general-purpose embeddable runtime with multiple execution modes and language integrations.¹¹
• Spin is an application framework and developer experience for building event-driven Wasm applications; it uses runtimes such as Wasmtime underneath rather than replacing the runtime layer.¹²

Language support is similarly uneven. Rust and C/C++ have mature compilation paths. TinyGo provides a deliberately smaller Go toolchain for constrained Wasm targets. JavaScript, Python, C#, Java, Kotlin, Dart, and other managed languages have credible paths in particular runtimes or frameworks, but support varies by target, component tooling, runtime embedding, library compatibility, and performance expectations.

The practical rule is simple: do not ask only whether a language can compile to Wasm. Ask whether the exact language version, libraries, WASI generation, component tooling, debugger, and production runtime you need work together.

Kubernetes does not disappear

Wasm changes the workload runtime, not necessarily the control plane.

SpinKube combines a Kubernetes operator, a containerd shim for Spin, runtime-class management, and CLI integration. Kubernetes can schedule Wasm applications on appropriately configured nodes while teams continue to use familiar cluster concepts. The shim allows containerd to manage the workload, and a RuntimeClass selects the Wasm execution path.¹³

The practical mental model is:

This is coexistence, not replacement. A cluster may run a conventional containerized database, a containerized API, and Wasm-based request handlers together. Operational parity is not complete, however. Observability, debugging, security scanning, policy enforcement, networking behavior, and managed Kubernetes support can differ from the mature container path.

Docker’s own Desktop documentation now marks its Wasm workloads feature as deprecated and no longer actively maintained.¹⁴ That is evidence about one Docker Desktop integration—not proof that Docker has rejected Wasm or that Wasm has “moved permanently” to Kubernetes. The broader ecosystem continues through native edge platforms, standalone runtimes, component tooling, containerd shims, and Kubernetes projects.

Real adoption, without the vanity metrics

Production use is no longer hypothetical:

• Fastly Compute runs request handlers in Wasm sandboxes and creates a fresh sandbox per request by default.³
• Cloudflare Workers uses V8 isolates and supports WebAssembly modules. This is an important Wasm deployment model, although a V8 isolate platform is not identical to a WASI-native runtime.¹⁵
• Shopify Functions compiles customizable commerce logic to Wasm and defines a purpose-built Wasm API for exchanging function input and output.⁵
• American Express has publicly presented work on an internal function-as-a-service platform built with wasmCloud. It is a useful enterprise architecture example, although public evidence does not justify ranking it by size against other deployments.¹⁶
• Akamai announced its acquisition of Fermyon on December 1, 2025, explicitly linking Fermyon’s serverless Wasm technology with Akamai’s distributed edge platform. Akamai also committed to continued support for the Spin and SpinKube open-source projects.¹⁷

The acquisition is meaningful market validation. Claims such as “75 million requests per second,” “10 million executions per second,” or a precise percentage of Chrome page loads should not be repeated without a current, primary source and a clearly defined measurement. The architecture stands on its own without uncertain scale statistics.

The browser story still matters

Server-side Wasm did not emerge in isolation. The browser remains its largest distribution channel and its most familiar proof that portable, validated bytecode can run safely inside a host.

WebAssembly powers compute-intensive parts of applications such as Figma and Adobe Photoshop on the web, while other products use it behind the scenes for codecs, graphics, media processing, cryptography, and existing native libraries. Chrome telemetry reported by independent analysis placed pages using WebAssembly at roughly 5.5% in 2025, up from about 4.5% a year earlier. That metric means a page invoked the feature; it does not mean Wasm replaced JavaScript on 5.5% of websites.¹⁸

Browser and server deployments also differ. Browser Wasm reaches capabilities through Web APIs and JavaScript integration. Server-side components commonly rely on WASI or platform-specific host interfaces. Success in the browser proves the execution format, but it does not automatically prove that a browser workload can move unchanged to a WASI runtime—or vice versa.

Wasm as a sandbox for AI-agent tools

The source’s AI-agent observation deserves explicit treatment because it has moved beyond speculation. Agents increasingly need to invoke third-party tools or dynamically obtained code. Running those tools as ordinary local processes can give them ambient access to files, environment variables, credentials, and network destinations.

Microsoft’s open-source Wassette project is a concrete example of the alternative. Wassette exposes WebAssembly Components as Model Context Protocol (MCP) tools, retrieves components from OCI registries, runs them on Wasmtime, and applies fine-grained, deny-by-default permissions to host resources.¹⁹

The architectural pattern is:

This is promising for generated code and third-party agent tools because the execution unit is portable and its authority can be bounded. It is not a complete agent-security solution. The host still needs to govern credentials, data disclosure, allowed destinations, execution time, memory, tool provenance, signatures, logging, and user consent. Wasm limits what code can do only to the extent that the embedding host exposes narrow capabilities.

The wall: where Wasm still struggles

Server-side Wasm has crossed the line from experiment to production option, but not to universal substrate.

Compatibility remains the largest constraint

A language may compile to Wasm while its ecosystem does not. Libraries can depend on native extensions, dynamic loading, process spawning, signals, filesystem semantics, or networking behavior that the target platform does not provide.

Toolchain maturity is uneven

Rust has strong support across Wasm runtimes and component tooling. Other languages range from mature for specific platforms to experimental or incomplete. Debugging across generated bindings and component boundaries remains less familiar than debugging a conventional process.

Stateful and parallel workloads need nuance

Wasm can call external databases and state services, and edge platforms increasingly expose key-value stores, object stores, and durable services. The limitation is not “Wasm cannot use state.” It is that ephemeral Wasm instances are usually a poor place to own durable state.

Similarly, core Wasm supports threads, but portable server-side threads and platform support remain inconsistent. Heavy shared-memory parallelism, GPU workloads, databases, and operating-system-intensive software generally remain better served by containers, VMs, or native processes.

Performance is multidimensional

Fast startup does not guarantee faster steady-state execution or lower end-to-end latency. JIT versus AOT compilation, memory copying, host calls, component boundaries, networking, cryptography, and language runtimes all matter. A Wasm workload wrapped inside extra container or shim layers may gain operational consistency while losing some startup advantage.

Benchmark the architecture you will actually deploy—not “Wasm” and “Docker” as abstract brands.

This is particularly important for hybrid paths. Running a Wasm guest through Docker or a containerd shim adds orchestration and integration layers that a native embedded runtime may not have. Some third-party benchmarks have found such paths slower to start than a comparable container in their test environment. Those results should be treated as workload-specific evidence, not as a fixed 65-to-300-millisecond penalty. The sub-millisecond numbers most often cited come from highly optimized native or edge runtimes, not from every Kubernetes or Docker integration.

A practical architecture playbook

The cleanest 2026 architecture is not a territorial map in which Docker owns state and Wasm owns the edge. It is a workload-placement decision.

Prefer Wasm when

• the unit of work is small, stateless, and event-driven;
• scale-to-zero or per-request isolation makes startup latency important;
• many tenants or plugins must run with narrowly delegated capabilities;
• the target edge or serverless platform is already optimized for Wasm;
• portability across host architectures matters;
• the selected language, libraries, and WASI version are genuinely supported.

Prefer containers when

• the software expects a complete Linux user space or mature POSIX behavior;
• it is long-running and startup time is operationally insignificant;
• it depends on native packages, sidecars, process supervision, GPUs, or specialized drivers;
• it needs mature debugging, observability, security tooling, and broad platform support;
• it owns durable local state or performs heavy multithreaded computation.

Use both when

• a containerized core service or database exposes stable APIs;
• latency-sensitive validation, transformation, routing, or customization runs in Wasm;
• untrusted extension code needs a smaller authority surface;
• Kubernetes remains the control plane while different runtime classes serve different workload shapes.

A better first experiment

Do not begin by porting a database or a large service. Choose a narrow function whose boundaries are already clear:

• an HTTP request validator;
• a webhook filter;
• a routing or authorization rule;
• a document or event transformation;
• a customer-supplied plugin;
• a small piece of agent tool logic with tightly scoped host capabilities.

Then measure four things:

1. End-to-end cold latency, including artifact retrieval and application initialization.
2. Warm throughput and tail latency, not only the best startup sample.
3. Memory and density under realistic concurrency.
4. Developer and operational friction, including debugging, tracing, dependency compatibility, policy, and incident response.

The result may not justify migration. That is still a successful experiment: you have discovered the actual boundary of the technology in your environment.

What is likely to happen next

Containers are likely to remain the dominant general-purpose cloud packaging model in the near term because their compatibility, tooling, operational practices, and managed-platform support are difficult to displace. Wasm is better understood as a fast-growing adjacent execution model. Forecasts that predict a precise market split by 2027 should be treated cautiously unless their methodology and definition of a “Wasm workload” are clear.

The more defensible prediction is architectural: cold-start-sensitive, high-density, and security-sensitive functions will increasingly be evaluated for Wasm, while long-running Linux applications will continue to favor containers. The handover, where it occurs, will be workload by workload rather than a platform-wide replacement.

The real shift

Containers won because they made an operating-system process portable enough to become a universal deployment unit. WebAssembly asks whether some workloads need to carry that much environment at all.

For short-lived, capability-constrained code, the answer is increasingly “no.” A compact module, a strongly typed interface, and an optimized runtime can be a better abstraction than a process-shaped package.

That does not make Docker obsolete. It makes the compute landscape more precise:

• virtual machines isolate operating systems;
• containers isolate processes;
• WebAssembly isolates portable programs and components;
• orchestration platforms can place all three where they fit.

The revolution is not that every container will become a Wasm module. It is that architects now have another credible isolation boundary—and for stateless edge, serverless, and plugin workloads, it may be the right one.

References

Footnotes

1. B. Cameron Gain, “Wasm 3.0: No Component Model and No ‘Docker Moment’,” The New Stack, October 6, 2025. https://thenewstack.io/wasm-3-0-no-component-model-and-no-docker-moment/ ↩

2. WebAssembly Community Group, “Introduction — WebAssembly Core Specification 3.0.” https://webassembly.github.io/spec/core/intro/introduction.html ↩ ↩²

3. Fastly, “Sandbox Execution Lifecycle”; Fastly, “Unparalleled Performance: Bring Your C++ Logic to the Edge.” https://www.fastly.com/documentation/guides/compute/developer-guides/sandbox-lifecycle/ and https://www.fastly.com/blog/unparalleled-performance-bring-your-logic-edge ↩ ↩²

4. Bytecode Alliance, “Introduction — The WebAssembly Component Model.” https://component-model.bytecodealliance.org/ ↩ ↩²

5. Shopify, “Shopify Functions.” https://shopify.dev/docs/apps/build/functions ↩ ↩²

6. WebAssembly, “Wasm 3.0 Completed,” September 17, 2025. https://webassembly.org/news/2025-09-17-wasm-3.0/ ↩

7. WASI, “Roadmap.” https://wasi.dev/roadmap ↩ ↩²

8. Bytecode Alliance, “Component Model Concepts.” https://component-model.bytecodealliance.org/design/component-model-concepts.html ↩

9. Wasmtime documentation. https://docs.wasmtime.dev/ ↩

10. WasmEdge documentation. https://wasmedge.org/docs/ ↩

11. Wasmer documentation. https://docs.wasmer.io/ ↩

12. Fermyon, Spin documentation. https://spinframework.dev/ ↩

13. SpinKube, project documentation. https://www.spinkube.dev/ ↩

14. Docker, “Wasm workloads.” https://docs.docker.com/desktop/features/wasm/ ↩

15. Cloudflare, “WebAssembly (Wasm).” https://developers.cloudflare.com/workers/runtime-apis/webassembly/ ↩

16. CNCF, “American Express: Building a Functions-as-a-Service Platform with wasmCloud,” KubeCon + CloudNativeCon presentation materials. https://www.cncf.io/online-programs/american-express-building-a-functions-as-a-service-platform-with-wasmcloud/ ↩

17. Akamai, “Akamai Technologies Announces Acquisition of Function-as-a-Service Company Fermyon,” December 1, 2025. https://www.akamai.com/newsroom/press-release/akamai-announces-acquisition-of-function-as-a-service-company-fermyon ↩

18. Tim Anderson, “WebAssembly gaining adoption ‘behind the scenes’ as technology advances,” DevClass, January 28, 2026. https://www.devclass.com/development/2026/01/28/webassembly-gaining-adoption-behind-the-scenes-as-technology-advances/4079564 ↩

19. Microsoft Open Source Blog, “Introducing Wassette: WebAssembly-based tools for AI agents,” August 6, 2025. https://opensource.microsoft.com/blog/2025/08/06/introducing-wassette-webassembly-based-tools-for-ai-agents/ ↩