WebAssembly beyond the browser: what WASI enables
WebAssembly began as a way to run fast code in browsers. With WASI it runs on servers, at the edge and inside plugins: sandboxed, portable and quick to start.
WebAssembly (Wasm) was designed to run code at near native speed inside a web page. The properties that made it safe for browsers turned out to be useful everywhere else too: a compact binary format, a strict sandbox and no dependence on any one operating system or processor.
What it lacked outside the browser was a standard way to reach the system. That is the job of WASI.
What WASI adds
A WebAssembly module on its own can only compute. It cannot open a file, read the clock or make a network request. The WebAssembly System Interface (WASI) defines standard interfaces for exactly those things: files, clocks, random numbers, sockets and HTTP.
The model is based on capabilities. A module has no access by default. The host grants what it needs, such as one directory or outbound HTTP to one domain. Code you did not write runs with only the permissions you chose.
Why run Wasm on a server
It starts fast. A module starts in milliseconds or less. A container often needs a second or more. For functions that scale to zero, that gap is the cold start problem solved.
It is small and portable. One .wasm file runs on Linux, macOS and Windows, on x86 and ARM, wherever a runtime such as Wasmtime or WasmEdge is installed.
It is isolated by default. The sandbox is part of the design and not an extra layer you configure.
It is language neutral. Rust, C, C++, Go and others compile to it, and support for more languages keeps growing.
Where it is used today
- Edge platforms. Several CDN and edge providers run customer code as WebAssembly, because thousands of isolated instances fit on one machine.
- Plugin systems. Proxies, databases and SaaS products let customers extend them with Wasm modules, without trusting those modules with the whole process.
- Serverless functions. Short, CPU-bound jobs such as resizing an image or validating a payload.
A small example
A Rust program compiled for WASI and run with Wasmtime:
rustup target add wasm32-wasip1
cargo build --release --target wasm32-wasip1
wasmtime run target/wasm32-wasip1/release/resize.wasm
The same file runs unchanged on a laptop, a server or an edge node.
The limits
WebAssembly on the server is not a replacement for containers. A large web application with a database driver, background workers and a long list of native libraries is still better served by a container today. Tooling and library support also vary from one language to another.
It fits best where its strengths matter: short-lived, isolated, CPU-bound work that has to start instantly.
What comes next
WASI is built on the Component Model, which lets modules written in different languages call each other through typed interfaces. We cover that in the WebAssembly Component Model, explained.