WASI — WebAssembly System Interface
WASI (WebAssembly System Interface) — the syscall standard for WASM modules running outside the browser (server, CLI, edge). Lets WASM read files, open sockets, use clocks — but only via capability-based access (the caller passes in a handle, the module cannot gethostname-allocate on its own). WASI 0.2 (2024) is built on Component Model. Runtimes: Wasmtime, WasmEdge, Spin.
Below: details, example, related terms, FAQ.
Details
- Capability-based security: WASM modules have no ambient authority
- Sandboxed by default: no fs, network, env without explicit grant
- WASI Preview 2 (0.2) = Component Model + API split into interfaces
- Preview 1 — legacy (wasi_snapshot_preview1), still works in Wasmtime
- Typical use: serverless (Fermyon Spin), CDN compute (Fastly), plugins (Shopify Functions)
Example
// Rust → WASI binary
$ cargo build --target wasm32-wasi --release
$ wasmtime --dir=. target/wasm32-wasi/release/app.wasm
// Fermyon Spin app.toml
[[component.trigger]]
route = "/"
[component.source]
path = "target/wasm32-wasi/release/hello.wasm"Related
Learn more
Frequently Asked Questions
WASI vs Docker?
Docker = linux kernel + container runtime. WASI = capability API, kernel-less isolation, cold-start ~1 ms vs ~100 ms for Docker.
Production-ready?
For CLI, plugins, serverless — yes (Fastly, Shopify). Full web-server on WASI — still experimental (no async sockets in preview2).
Async support?
WASI 0.2 adds async (poll_oneoff). Tokio for WASI — integration in progress.