Running WebAssembly Outside the Browser: WASI and Serverless Wasm Runtimes

An introduction to WebAssembly, why it matters, and a working example of compiling and running Rust code in the browser.

Wasm Isn’t Just for the Browser Anymore

WebAssembly’s sandboxed, portable execution model turned out to be just as valuable outside the browser as inside it. WASI (WebAssembly System Interface) gives Wasm modules standardized access to filesystems, networking, and other OS-level capabilities, enabling Wasm as a general-purpose server-side runtime.

Why Server-Side Wasm Is Gaining Traction

  • Cold starts measured in microseconds, not the hundreds of milliseconds typical of container-based serverless
  • Strong sandboxing by default — a Wasm module can’t touch the filesystem or network unless explicitly granted capability
  • True portability — the same compiled module runs identically across cloud providers and edge locations

Compiling a WASI Module in Rust

use std::io::{self, Read};

fn main() {
    let mut input = String::new();
    io::stdin().read_to_string(&mut input).unwrap();
    let doubled: i32 = input.trim().parse::<i32>().unwrap() * 2;
    println!("{}", doubled);
}
rustup target add wasm32-wasi
cargo build --target wasm32-wasi --release

Running It with a Wasm Runtime

wasmtime target/wasm32-wasi/release/doubler.wasm

Deploying to a Serverless Wasm Platform

// Fastly Compute (JavaScript SDK, compiled to Wasm)
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  const url = new URL(request.url);
  return new Response(`Handled ${url.pathname} at the edge`, {
    headers: { 'content-type': 'text/plain' },
  });
}

Explicit Capability Granting

# Only grant access to a specific directory, nothing else on the filesystem
wasmtime --dir=/data run process.wasm

This capability-based security model is a meaningful improvement over container isolation, where a misconfigured container can often see far more of the host than intended.

Where This Fits Today

  • Edge compute platforms (Fastly Compute, Cloudflare Workers) run user code as Wasm under the hood for fast, safe multi-tenant execution
  • Plugin systems for SaaS platforms, letting customers run sandboxed custom logic without container-level isolation overhead
  • Lightweight microservices where cold-start latency genuinely matters more than raw throughput

Current Limitations

WASI’s system interface is still maturing — networking support (WASI Preview 2) is newer and less battle-tested than filesystem access, and language/library support varies significantly. Verify your specific runtime’s WASI support level before committing to it for production workloads.

Conclusion

Server-side WebAssembly trades some ecosystem maturity for genuinely faster cold starts and stronger default sandboxing than containers. It’s not a wholesale replacement for container-based deployment yet, but it’s a strong fit for edge compute and plugin-style sandboxed execution today.