As of April 28, 2026, WASI Preview 2 is stable, and Preview 3 targets async and threads for edge Wasm architectures in production. Full breakdown.
What is stable today, and what Preview 3 adds
As of April 28, 2026, WASI Preview 2 is stable. That means component-model interfaces, the standard host capabilities for files, clocks, sockets, and random, and the tooling path to package and compose Wasm components are ready for production use. You can ship edge workers as components with defined imports and exports, compose them without rebuilding everything from source, and reason about sandbox boundaries in a consistent way across hosts.
WASI Preview 3 targets async and threads. Edge workloads often need concurrent I/O—outbound fetches, stream processing, fan-out to multiple backends—without blocking a single core on every wait. Threads matter when a request path includes CPU-heavy work alongside I/O, or when you want to isolate long-running tasks from latency-sensitive handlers. Preview 3 is aimed at making those patterns first-class in the WASI stack rather than host-specific workarounds.
Why components fit edge Wasm
A Wasm component is a unit with a typed interface: it declares what it needs from the host and what it exposes. At the edge that maps cleanly to multi-tenant isolation. Each request (or short-lived session) can run in a sandbox that only sees the capabilities you grant—network to specific destinations, limited memory, no ambient filesystem unless you wire it in. Composition lets you split auth, routing, and business logic into separate components and wire them at deploy time instead of packing everything into one binary.
Compared with monolithic Wasm modules that rely on ad hoc host imports, components reduce coupling between your code and a single runtime. The same component can target different edge platforms if they implement the same WASI surface. That does not remove all portability work—resource limits, timeouts, and cold-start behavior still vary—but it moves the shared contract into a standard ABI instead of proprietary glue.
Async and threads on the edge
Edge runtimes are latency-sensitive and often short-lived. Async I/O lets a single instance handle many concurrent operations without dedicating a thread per wait. That matches request-driven traffic: open a connection, stream a body, call another service, and free the slot when the response is done. Preview 3’s focus on async is about making that model portable across WASI-compliant hosts rather than tying you to one vendor’s async API.
Threads are the other half. Use them when you must keep a core busy on computation while still accepting new work, or when you want strict separation between a compute path and an I/O path. On the edge, threads are constrained by memory budgets and instance lifetime. Prefer async for wait-heavy I/O; reserve threads for parallel CPU work that does not fit a pure cooperative model. Design so thread use is bounded—pool size, stack size, and cancellation—so a spike cannot exhaust the host.
- Model outbound calls and stream handling as async tasks with clear deadlines.
- Keep shared state minimal and immutable where possible so concurrent paths stay safe.
- Expose only the WASI capabilities each component needs; deny the rest by default.
- Test cold start, memory caps, and cancellation paths the same way you test happy-path latency.
Practical path for production edge architectures
Build against the stable Preview 2 component model first: define WIT interfaces, package components, and compose them for your edge entrypoint. Keep host-specific features behind small adapters so you can swap or upgrade later. When Preview 3 async and threads land in your target runtimes, migrate I/O-bound paths to the standard async model and introduce threads only where profiling shows real CPU contention.
Treat Preview 3 as an expansion of the production surface, not a rewrite of the component boundary. The interfaces and isolation model from Preview 2 remain the spine of the architecture; async and threads fill the concurrency gaps that pure sequential edge handlers hit under load. Ship with explicit capability grants, measurable latency and memory limits, and a composition graph you can reason about without reading every line of guest code.