WASI preview 3: adoption and real cases

Actualizado: 2026-05-03

WASI preview 3 was officially stabilized in late 2025, after more than two years of work on the foundations preview 2 left in 2024. Getting here has cost more than the community expected, and for a time it seemed the project was stuck in debates about async and component model. Starting 2026 with a published standard and several runtimes with solid support, time to evaluate what has changed in practice and what real cases have started moving.

Key takeaways

• Preview 3 adds what was missing from preview 2: native async, well-defined bidirectional streams, and inter-component concurrency with specified semantics.
• You no longer have to choose between portability and async: a component using async runs on wasmtime, WasmEdge, JCO, and the main commercial runtimes without changes.
• Production cases that work best: API gateways with complex logic and extension plugins for SaaS applications.
• WASI Cloud stabilized its first official version: the same Wasm component speaks over AWS, Azure, Google Cloud, or self-hosted backend by changing only the adapter.
• Remaining friction: uneven support in commercial runtimes beyond wasmtime, WasmEdge and Spin; cold-start times still above native binaries; debugging still clumsy.

What preview 3 brings that preview 2 missed

Preview 2 was already a perfectly usable standard for many cases. It provided interfaces for filesystem, networking, randomness, clock, and environment, all over the component model introduced in 2024. But three gaps limited adoption in advanced scenarios:

1. Absence of native async — cases needing serious concurrency ended up either outside WASI with proprietary runtimes, or with ad-hoc solutions breaking compatibility.
2. Lack of well-defined bidirectional streams — limited portable implementation of protocols like WebSocket or gRPC.
3. Limitations in interaction between concurrent components — not enough specification to build real architectures where several components collaborate via async messages.

Preview 3 resolves these three gaps in coordinated fashion. The async model is now part of the standard itself. A component using async runs on wasmtime, WasmEdge, JCO (for browser), and main commercial runtimes without changes.

Mature runtimes and production cases

Wasmtime (Bytecode Alliance) achieved full preview 3 support with version 26 in November 2025. WasmEdge followed in January 2026 with version 0.15. Spin from Fermyon incorporated preview 3 in version 3.5. These three bases cover most real cases in production today.

Practical case 1: API gateway with Spin 3.5 — A company that needed complex routing logic, request transformation, and specific authorization policies has replaced their prior NGINX-with-Lua-scripts gateway with a set of Wasm components in Spin. The main reason wasn’t performance but maintainability: Wasm components can be written in Rust, TypeScript or Go, tested in isolation, versioned independently, and deployed without restarting the main process. Preview 3 was needed because complex policies required async calls to external services during authorization evaluation.

Practical case 2: extension plugins for SaaS applications — Several products historically allowing JavaScript sandbox extensions have moved to WebAssembly components. Wasm plugins are faster, safer (native runtime sandbox), and portable between languages. Preview 3 was key because many plugins need to make HTTP calls or access internal product APIs with async patterns, and preview 2 forced clumsy workarounds.

The component and library ecosystem

Beyond the standard, the precompiled component ecosystem has enriched notably. WASI Cloud — standardized interfaces for cloud services: queues, blobs, KV, pub/sub, LLM — stabilized its first official version with preview 3 integrated. The same Wasm component speaking WASI Cloud works over AWS, Azure, Google Cloud, or a self-hosted backend, just by changing the adapter.

Build tools have also improved: Cargo component (for Rust), jco (for JavaScript and TypeScript), and the Go ecosystem with tinygo or the official WebAssembly compiler all produce preview 3 components with mature tooling, decent errors, and documentation that’s no longer just the repo README.

This model allows reusing logic between languages naturally: a component compiled from Rust is consumed without friction by a component written in TypeScript, no FFI.

A minimal example with Spin and async

A common pattern is a small web API consuming external services with concurrency. The Rust fragment shown above would have been impossible in preview 2 without tricks outside the spec. In preview 3 it’s natural syntax, with real concurrency between HTTP requests, running on any compatible runtime without specific code. This ergonomics is what has unlocked cases that had been waiting two years.

Where there’s still friction

• Preview 3 support in commercial runtimes beyond those mentioned remains uneven. Some edge-computing providers that adopted preview 2 early are taking longer than expected to migrate. Most will stabilize during H1 2026.
• Cold-start times remain worse than native binaries. For loads requiring very low latency on pointwise invocations, Wasm still adds a few milliseconds. For long-running loads this doesn’t matter, but for microservices with aggressive latency SLOs, you have to measure.
• Debugging remains clumsy compared to native binaries. Wasm component stack traces are less readable, visual debuggers are more limited, and low-level instrumentation requires more effort.

When adopting now pays

For a team considering Wasm in production, distinguish three scenarios:

1. Cases where Wasm brings clear, non-urgent value: plugins for SaaS products, edge-computing functions, logic embedded in larger applications. Start now with preview 3, knowing the initial curve is notable but mid-term return is solid.

2. Cases of replacing working existing architectures: if you have Docker containers with healthy microservices, replacing them with Wasm components rarely pays. Migration cost and retraining usually exceeds density or startup-time gains.

3. Cases where Wasm’s promise solves a real problem you have: deploying the same logic on server, edge, and browser without rewriting; running third-party code with isolation guarantees; operating at scales where per-machine density matters. Here Wasm with preview 3 is the most solid technical option of 2026 and adopting is a sound strategic decision.

Conclusion

The honest reading of preview 3 is that WebAssembly has finally reached the maturity it promised since 2019. Preview 2 already allowed interesting cases, but preview 3 closes the circle with async, streams, and concurrent composition. The ecosystem is starting to really bloom, with mature runtimes, reusable libraries, and demonstrable production cases. It’s not a universal replacement for containers or proprietary serverless functions. But for the niches where its advantages are real — extreme portability, strong isolation, density — 2026 is the year to stop waiting and start using it, with the expectation that the standard is stable, runtimes are compatible, and tooling allows genuine productivity.