WASI: the System Interface Shaping Server-Side Wasm

WebAssembly has a sandbox but no opinion about the world outside it — until you give it one. That opinion is WASI, the WebAssembly System Interface: a group of standards-track API specifications for software compiled to the W3C WebAssembly standard, designed to provide “a secure standard interface for applications that can be compiled to Wasm from any language, and that may run anywhere, from browsers to clouds to embedded devices.” In three short releases — 0.1, 0.2, and 0.3 — WASI has grown from a single-instance CLI shim into a component-native, async-capable system interface governed in the open under the W3C WebAssembly Community Group. This is the standardization story, interface by interface.

Preview 1 (WASI 0.1): the portable sandbox

The first WASI release, usually called Preview 1 or WASI 0.1, took Wasm modules that until then could only be driven by a JavaScript host and gave them a portable way to do the basics of being a program: read command-line arguments and environment variables, touch the filesystem through preopened directories, read clocks, get random bytes, write to stdout, and exit with a status code. Networking was deliberately absent.

Two properties made 0.1 a hit:

• Capability-based security. A module starts with no ambient authority. There is no open("/etc/passwd") unless the embedding host explicitly preopened that directory and passed it to the module. Contrast this with containers, where the default is a shared kernel plus a hardened profile.
• Universal tool support. The same wasm32-wasip1 target compiles from Rust, C/C++ (WASI SDK), Go, Python, and dozens of other languages, and every serious runtime implements 0.1 — Wasmtime, WasmEdge, Wasmer, WAMR, wazero, wasmi, wasm3.

WASI 0.1 describes modules — core Wasm binaries. That worked for single programs but not for composition: two modules couldn’t talk to each other without a bespoke host protocol, usually HTTP.

Preview 2 (WASI 0.2): components change the model

Released at the end of January 2024, WASI 0.2 (Preview 2) rebuilt the interface on top of the Component Model. Instead of modules, you now produce components: Wasm binaries whose imports and exports are described in WIT (Wasm Interface Type) — a language-neutral interface language with real types (records, enums, resources, futures).

The practical consequences:

• Cross-language composition. A Rust component and a Go component can link directly — a function call, not a microservice. WASI exists, in the project’s words, “to compose software written in different languages without costly and clunky interface systems like HTTP-based microservices.”
• Wasmtime became a component runtime. Runtimes began implementing wasi:cli, wasi:filesystem, wasi:sockets, wasi:clocks, wasi:random, wasi:http, and wasi:io as WIT interfaces rather than one monolithic snapshot.
• The phase process hardened. Each API is a proposal moving through numbered stages: Phase 0 (pre-proposal idea sharing), Phase 1 (feature proposal, fork of the spec repo), Phase 2 (prototype + test suite + documented portability criteria + WIT published to an OCI registry), Phase 3 (implementation with semver releases). Phases 4 and 5 — final standardization — are still undefined and no proposal has entered them.

Notably, the six core proposals above (clocks, random, filesystem, sockets, cli, http) all sit at Phase 3 today. The sockets proposal covers TCP and UDP plus DNS resolution; filesystem covers file and directory operations on preopened directories; cli covers environment variables, arguments, stdio, and process exit; http covers incoming and outgoing request/response handling.

Preview 3 (WASI 0.3): native async

WASI 0.3 is the current stable release, and its headline feature is native async support for the Component Model. It refactors the interfaces around async primitives — async func, stream<T>, and future<T> — so that a component can await I/O without blocking the host’s executor. The wasi:io interfaces that 0.2 used for blocking-style operation were removed in 0.3 in favor of the stream/future model.

Toolchain status as of the release notes:

• Wasmtime 46 and later runs 0.3 components by default, and 0.3-capable runtimes also run 0.2 components — starting on 0.2 doesn’t close off 0.3.
• Rust has 0.3 bindings in the wasip3 crate; jco (the JavaScript/TypeScript component toolchain) ships an experimental 0.3 shim for Node.js.
• Most other toolchains still target 0.2.

WASI 0.3.1 work continues in the open: on August 6, 2026, the WASI Subgroup adopted the map<K, V> type and the implements/external-id annotations, gated behind Component Model features that all runtimes implementing that version must support.

The rest of the proposal pipeline

WASI’s scope extends well beyond the core six. Active proposals reveal where server-side Wasm is heading:

Phase	Proposals
Phase 3 (implementation)	Clocks, Clocks: Timezone (Phase 2), Random, Filesystem, Sockets, CLI, HTTP
Phase 2 (spec text)	Key-value store, Machine Learning (wasi-nn), Runtime Config, WebGPU, Messaging (pub/sub, request/reply), I2C, HTTP 1xx informational responses
Phase 1 (feature proposal)	Crypto, TLS, SQL, SQL Embed, Logging, Observe, OTel, Blob Store, GPIO, SPI, USB, URL, Parallel, Threads, Pattern Match, Distributed Lock Service
Phase 0	proxy-wasm (the Envoy/Istio plugin ABI, to be split into smaller proposals)

The Phase 1 list is worth dwelling on: wasi-nn (inference against pre-trained ML models), wasi-crypto (signatures, hashing, symmetric encryption), wasi-tls, wasi-logging, and an OpenTelemetry proposal mean the “system interface” is growing toward the full surface a cloud service needs — without any of it being ambient by default.

The standardization story

WASI is developed by the WASI Subgroup of the W3C WebAssembly Community Group. Work happens in GitHub issues and pull requests in the WebAssembly/WASI repository and in bi-weekly Zoom meetings whose notes are public. That structure matters for adopters: proposals have documented portability criteria, WIT definitions are published to OCI registries so implementations can be tested against them, and a shared wasi-testsuite exercises interfaces across runtimes (with adapters for Wasmtime, jco, WAMR, and others) as the conformance reference.

Versioning follows semantic versioning in the 0.x range while proposals advance. A WASI 1.0 release would come only after full standardization — once the WASI Subgroup, the WebAssembly Community Group, and the W3C WebAssembly Working Group define what that requires. Until then, “stable” means stable within a milestone: 0.1 is legacy, 0.2 is stable-but-superseded, 0.3 is stable and current.

Choosing a target today

The decision tree the project itself recommends:

1. Building a single CLI-style program or plugin today? Target WASI 0.1 (wasm32-wasip1) if you need maximum runtime support — it runs everywhere, including browsers via Jco-style tooling, and remains widely deployed in production.
2. Building composable, multi-language systems? Target WASI 0.2 components. Rust (wasm32-wasip2), Python, C#, Go (via the component toolchain), and JavaScript all have working paths, and runtimes treat 0.2 as the baseline.
3. Building I/O-heavy services that need async? Target WASI 0.3 with Wasmtime 46+ and the wasip3 crate — the stream/future model is what a high-concurrency HTTP server actually wants.

Whatever you pick, the capability model is non-negotiable: the runtime delegates every permission, and a component that wants a socket, a directory, or a clock must be granted it explicitly. That is the property that makes WASI — not Wasm’s speed, not its small size — the interface shaping server-side WebAssembly.

References

• WASI Introduction — https://wasi.dev/
• WASI Releases (0.1 / 0.2 / 0.3 status table) — https://wasi.dev/releases
• WASI 0.3 release page — https://wasi.dev/releases/wasi-p3
• WASI Subgroup Charter, WebAssembly/WASI — https://github.com/WebAssembly/WASI/blob/main/docs/Charter.md
• WASI proposals list — https://github.com/WebAssembly/WASI/blob/main/docs/Proposals.md
• WebAssembly Component Model documentation — https://component-model.bytecodealliance.org/
• W3C WebAssembly Community Group — https://www.w3.org/community/webassembly/
• wasi-testsuite — https://github.com/WebAssembly/wasi-testsuite