Releases
Modules and components
WebAssembly binaries may be components built according to the Component Model or modules built to the core WebAssembly specification.
As you begin writing a Wasm application using WASI APIs, one of your first decisions will be which type of binary you want to produce. This decision is typically guided by your use case and the runtime you wish to use. Check to see which WASI releases your runtime supports.
-
Components can use WASI P2 or P3 and the Component Model for composability and interoperability, meaning that a WebAssembly component compiled from one language (Rust, for example) can communicate or be combined with a component compiled from another language (such as Go). WASI P3 adds native async support, building on the foundation established in WASI P2.
-
Modules can use APIs from WASI P1, an earlier stage of WASI's development. Since WASI P2 was released end of January 2024, WASI P1 support is more widespread among Wasm runtimes, and it is widely used in production today.
WASI releases
| Release | Status | Description |
|---|---|---|
| WASI P3 | Stable | Native async support with async func, stream<T>, and future<T> |
| WASI P2 | Stable | Component Model foundation with WIT interfaces, composability, and cross-language interoperability |
| WASI P1 | Legacy | POSIX-inspired module API with broad runtime support |
For more information on release timelines and plans, see the Roadmap.
Proposals for the standard
All WASI APIs are proposals for standardization by the WASI Subgroup. The API proposals in WASI P1 and P2 met implementation and portability criteria for inclusion at the time of those releases. A proposal advances through the following stages as defined in the WASI Subgroup's Phase Process:
- Phase 0 - Pre-proposal: The pre-proposal phase serves as a way to share ideas. At this phase, the WASI subgroup has not yet decided that the pre-proposal is in scope for WASI, and there may be overlap between pre-proposals.
- Phase 1 - Feature proposal: In this phase, the proposal is added to the proposal list and a new fork of the spec repo is created.
- Phase 2 - Feature description available: During this phase, one or more implementations prototype the feature and a test suite is added.
- Phase 3 - Implementation phase: At this phase, project champions create releases following the conventions of semantic versioning (semver).
- Phase 4 - Standardize the feature: At this point, the feature is fully handed off to the Working Group, where edge cases are considered and only minor changes occur.
- Phase 5 - The feature is standardized: Once the Working Group reaches consensus that the feature is complete, editors perform final editorial tweaks and merge the feature into the main branch of the primary spec repo.
Proposals are first made to the WASI Subgroup of the WebAssembly Community Group. (See the WASI Subgroup's meeting schedule.)
All active WASI proposals can be found on the WASI GitHub repository. See the Contributing to WASI page for information about submitting a new proposal.
WASI test suite
WASI runtimes are tested against a shared test suite, wasi-testsuite, which exercises interfaces from WASI P1 and WASI P3 across runtime implementations. The repository includes a test runner with adapters for the major runtimes (Wasmtime, jco, WAMR, and others), and is the shared reference for verifying runtime conformance.
Active proposals
Phase 5 - The Feature is Standardized (WG)
| API Proposal | Description | Repository |
|---|
Phase 4 - Standardize the Feature (WG)
| API Proposal | Description | Repository |
|---|
Phase 3 - Implementation Phase (SG)
| API Proposal | Description | Repository |
|---|---|---|
| I/O | Streams, pollables, and async wait primitives; removed in WASI P3 | https://github.com/WebAssembly/WASI/tree/main/proposals/io |
| Clocks | Wall-clock and monotonic-clock access | https://github.com/WebAssembly/WASI/tree/main/proposals/clocks |
| Random | Cryptographically secure and insecure random byte generation | https://github.com/WebAssembly/WASI/tree/main/proposals/random |
| Filesystem | File and directory operations on preopened directories | https://github.com/WebAssembly/WASI/tree/main/proposals/filesystem |
| Sockets | TCP and UDP networking, plus DNS resolution | https://github.com/WebAssembly/WASI/tree/main/proposals/sockets |
| CLI | Environment variables, command-line arguments, stdio, and process exit | https://github.com/WebAssembly/WASI/tree/main/proposals/cli |
| HTTP | Incoming and outgoing HTTP request and response handling | https://github.com/WebAssembly/WASI/tree/main/proposals/http |
Phase 2 - Proposed Spec Text Available (CG + WG)
| API Proposal | Description | Repository |
|---|---|---|
| Clocks: Timezone | Timezone-aware datetime conversions and UTC offsets | https://github.com/WebAssembly/WASI/tree/main/proposals/clocks |
| HTTP: Informational Outbound Response | 1xx informational response support for outbound HTTP | https://github.com/WebAssembly/WASI/tree/main/proposals/http |
| I2C | Inter-Integrated Circuit bus access for embedded peripherals | https://github.com/WebAssembly/wasi-i2c |
| Key-value Store | CRUD operations against a key-value backend | https://github.com/WebAssembly/wasi-kv-store |
| Machine Learning (wasi-nn) | Inference against pre-trained ML models | https://github.com/WebAssembly/wasi-nn |
| Runtime Config | Read-only access to host-provided configuration values | https://github.com/WebAssembly/wasi-runtime-config |
| GFX | Cross-platform graphics primitives for surfaces and frames | https://github.com/WebAssembly/wasi-gfx |
| Messaging | Publish/subscribe and request/reply messaging primitives | https://github.com/WebAssembly/wasi-messaging |
Phase 1 - Feature Proposal (CG)
| API Proposal | Description | Repository |
|---|---|---|
| Blob Store | Object-storage operations on containers and blobs | https://github.com/WebAssembly/wasi-blob-store |
| Crypto | Signatures, hashing, and symmetric encryption primitives | https://github.com/WebAssembly/wasi-crypto |
| GPIO | General-purpose digital I/O pin control for embedded devices | https://github.com/WebAssembly/wasi-gpio |
| Distributed Lock Service | Distributed locking primitives for coordinating across nodes | https://github.com/WebAssembly/wasi-distributed-lock-service |
| Logging | Structured logging with severity levels | https://github.com/WebAssembly/wasi-logging |
| Observe | Application telemetry plumbing for observability tooling | https://github.com/dylibso/wasi-observe |
| OTel | OpenTelemetry traces, metrics, and logs | https://github.com/calebschoepp/wasi-otel |
| Parallel | Parallel computation primitives such as map and reduce | https://github.com/WebAssembly/wasi-parallel |
| Pattern Match | Pattern matching against strings using regex-style expressions | https://github.com/WebAssembly/wasi-pattern-match |
| SPI | Serial Peripheral Interface bus access for embedded peripherals | https://github.com/WebAssembly/wasi-spi |
| SQL | Connection-oriented SQL database operations | https://github.com/WebAssembly/wasi-sql |
| SQL Embed | Embedded SQL execution against in-process databases | https://github.com/WebAssembly/wasi-sql-embed |
| Threads | Native thread spawning and synchronization for components | https://github.com/WebAssembly/wasi-native-threads |
| TLS | Transport Layer Security for sockets and other byte streams | https://github.com/WebAssembly/wasi-tls |
| URL | URL parsing, construction, and manipulation | https://github.com/WebAssembly/wasi-url |
| USB | USB device enumeration and host communication | https://github.com/WebAssembly/wasi-usb |
Phase 0 - Pre-Proposal (CG)
| Proposal | Description | Repository |
|---|---|---|
| proxy-wasm/spec | Plugin interface for proxies and gateways; will advance as multiple smaller proposals | https://github.com/proxy-wasm/spec |
Versioning
Proposals remain in the 0.x semver range until they reach Phase 5 and are fully standardized. At that point, a 1.0 release should be made available.