WASI: What the WebAssembly System Interface Is and How to Use It

What problem WASI solves and who it is for

WebAssembly on its own is a portable instruction set with no way to talk to the outside world. A module cannot open a file, read the clock, or accept a network connection unless the host explicitly provides those capabilities. Before WASI, every runtime invented its own host bindings, so a module compiled for one runtime would not run on another without changes. WASI defines a shared set of APIs for those capabilities, so the same module can run on any runtime that implements the interface. The README states that WASI is a set of APIs for WASI being developed for eventual standardization by the WASI Subgroup, which is a subgroup of the WebAssembly Community Group. The README also notes that WASI started with what is now called Preview 1, an API using the witx IDL, and that its major influences are POSIX and CloudABI. The audience is anyone running WebAssembly outside the browser: server-side workloads, plugin systems, edge functions, and embedded runtimes that need a sandboxed way to reach system resources without giving the module unrestricted access to the host.

How the previews differ and what changed in each

WASI has gone through three previews, and they are not compatible with each other. Preview 1 is the original API, defined with the witx IDL, and the README says it is now widely used. Preview 2, referred to as WASI 0.2, is a modular collection of APIs defined with the Wit IDL. The README says it incorporates many of the lessons learned from WASI 0.1, including support for a wider range of source languages, modularity, a more expressive type system, and virtualizability. Preview 3, WASI 0.3, is the current preview. It builds on WASI 0.2 and replaces the earlier explicit streams and polling interfaces with the component model's native, composable async functionality via the future and stream types. The practical consequence is that a module built against Preview 1 will not run on a runtime that only implements Preview 2 or 3, and the reverse is also true. The move from witx to Wit is a change in the interface definition language itself, not just a version bump.

How to install WASI and run a first module

This repository is for general discussion, as well as documenting how the project works and its high-level goals. It does not contain a runtime you install. The README says development of each API happens in its own repo, which you can access from the proposals list in docs/Proposals.md. To actually run a WASI module you need a runtime that implements the preview you are targeting. The README gives no install steps for a runtime, so the steps below are limited to what the repository documents.

To find the API you need, start from the proposals list:

git clone https://github.com/WebAssembly/WASI.git
cd WASI
cat docs/Proposals.md

The proposals list points to the individual repository for each API. If you want to propose a new API, the README directs you to the Contributing guide in CONTRIBUTING.md, and says all new API proposals should use the new format and the new repo structure shown in the proposal template at https://github.com/WebAssembly/wasi-proposal-template. For information about using Wit for WASI proposals, the README points to docs/WitInWasi.md. The repository layout includes proposals/ and specifications/ directories alongside docs/, which reflects the split between proposal work and specification text. If you are looking for a tutorial that walks through compiling and running a module, this repository does not provide one.

Where WASI is the wrong tool

WASI is not a runtime and not a compiler. If you want to run a WebAssembly module today, you need a runtime that implements the interface, and this repository will not give you one. The README is explicit that this repo is for general discussion and for documenting how the project works and its high-level goals, and that development of each API happens in its own repo. That means the specification text you need may live in a separate repository rather than here. A second limitation is stability. The README describes the APIs as being developed for eventual standardization, which means they are not standardized yet. Preview 1, Preview 2 and Preview 3 are distinct, and a module compiled against one preview will not run on a runtime that implements a different one. If your project needs a fixed ABI that will not change under you, WASI is a poor fit at this stage. A third issue is that the interfaces are split across many repositories, so understanding the full surface area requires following the proposals list rather than reading a single document.

WASI compared with plain WebAssembly

Plain WebAssembly, sometimes written as Wasm, defines the instruction set and the module format. It says nothing about how a module reaches the file system, the network, or the clock. WASI is the layer that defines those APIs. The distinction matters because Wasm alone is a computation format: you can run a pure function, but you cannot write a server that reads from disk or listens on a socket without host-specific bindings. WASI provides the shared interface so that the same module can run on any runtime that implements it. The README frames WASI as a set of APIs being developed for eventual standardization, with POSIX and CloudABI as its major influences. That heritage is visible in the kind of capabilities it covers, but WASI is not POSIX and does not aim to be. It is a capability-oriented interface, which means the host decides what a module can access rather than the module assuming it can access everything. If you only need to run computation in a browser, you do not need WASI. If you need to run WebAssembly outside the browser with controlled access to system resources, that is the problem WASI exists to solve.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-08. The most recent release listed is v0.3.1 on 2026-08-11, following v0.3.0 on 2026-06-11 and v0.2.12 on 2026-06-02. The release cadence shows that the 0.3 line is current and that 0.2 is still receiving releases. The licence field is NOASSERTION, which means the repository's licence could not be automatically classified. The top-level entries include LICENSE.md, so a licence file is present, but the README does not state which licence it contains. If you plan to depend on WASI, read LICENSE.md directly rather than assuming a licence from the NOASSERTION field. This is not legal advice. On upgrade cost: because Preview 1, Preview 2 and Preview 3 are separate interfaces, moving between them is not a drop-in change. The README describes Preview 3 as replacing the earlier explicit streams and polling interfaces with the component model's future and stream types, which is a change in how asynchronous work is expressed, not just a version number. Budget for recompilation and interface changes when a preview advances.

Editorial conclusion

WASI is the right choice if you need to run WebAssembly outside the browser with controlled access to system resources, and if you are willing to track a moving target across previews. It is the wrong choice if you need a stable ABI today, because the interfaces are still being developed for eventual standardization and the previews are not interchangeable. Before adopting it, verify which preview your runtime and toolchain target, and check whether the specific API you need is still in a proposal repo rather than in the main specification.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. WebAssembly/WASI on GitHub