WebAssembly Beyond the Browser

For a decade WebAssembly meant one thing: compile your game to run in Chrome. Then infrastructure people noticed something interesting about the format — sandboxed by default, starts in microseconds, deterministic, tiny binaries — and started asking whether it could replace containers for some jobs.

Five years in, the honest answer is: yes, for some, and the boundary is finally becoming clear.

Why infra people got excited

A container is a heavyweight promise: a root filesystem, a process tree, a megabyte-scale image, seconds of startup. For long-running services that's fine. For the other workload — run this small function on a request, filter this stream, extend this proxy with custom logic — you're paying container costs for logic that runs for a millisecond.

Wasm flips the economics. A compiled module starts almost instantly, has no ambient authority (it can't touch the filesystem or network unless you grant capabilities), and the whole module often weighs under a megabyte. That's a sandbox you can spawn thousands of, per second, without flinching.

Where it's actually running in production

Edge functions. Cloudflare Workers, Fastly Compute, Fermyon — the edge is the Wasm beachhead. Cold starts measured in single-digit milliseconds mean a module can be instantiated per request and nobody notices. If your function is "transform this payload, call three APIs, return," Wasm edge runtimes beat container-based serverless on both latency and cost.

Plugins without the plugin problem. This one is underrated. Envoy, Httpd, and increasingly databases accept proxy-wasm modules — custom auth, routing, or telemetry logic that runs inside the data plane's sandbox. The plugin can segfault its little heart out and the proxy shrugs. Compare that with native plugins, where one bad free() takes down the gateway.

# the shape of it: build a tiny module, run it in a host runtime
spin build
spin up
# requests land in ~2ms cold; no image pull, no PID 1 drama

Build-once CLI tools. wasm32-wasip1 targets mean a utility compiled once runs on Linux, macOS, Windows, and inside containers — no more "which arch is the build box." wasmtime as a runtime gives you a scriptable sandbox for automation that's safer than bash running with your full user rights.

Where it is not replacing containers

Long-running stateful services with rich ecosystem needs — your Postgres, your JVM monolith, anything with GPUs — aren't Wasm workloads in 2026, and may never be. The component model and WASI preview releases keep expanding capabilities (sockets, filesystems with explicit capability grants), but "explicit capabilities" cuts both ways: everything the app needs must be threaded through the host.

My working boundary:

• Event-driven, short-lived, needs a hard sandbox → Wasm is worth evaluating.
• Long-lived, stateful, deep platform integration → containers, comfortably.
• Unsure → containers until the cold start or density problem is real, not theoretical.

The parts that still hurt

Language support is uneven. Rust and Go (via the component tooling) are first-class. JavaScript runtimes are excellent. Python works but carries a bigger embed. C++ compiles but fights the sandbox's assumptions. If your team's stack is niche, test the toolchain before designing around it.

The ecosystem isn't the container ecosystem. No equivalent of the Docker Hub manifest you blindly pull at 3 AM. Registries exist (warg, OCI-for-wasm), but the muscle memory of the container world doesn't transfer yet.

Debugging is thinner. Profilers, tracers, and introspection tools are improving fast, but they're not at container parity. Plan for that when your first Wasm service pages you.

Orchestration is early. Kubernetes can run Wasm workloads (containerd shims, runtime classes), but it's bolt-on territory. If you need the full scheduling/failover machinery, containers remain the well-trodden path.

How I'd start this year

Don't rewrite anything. Take one genuinely edge-shaped workload — a request transformer, a bot filter, a scheduled API poller — and build it twice: once as a lambda/worker in Wasm, once as a container. Compare cold start, cost per million requests, deploy size, and how the sandboxing felt when you granted network access.

That little experiment answers more than any architecture review. For us, the transformer went Wasm and never came back; the poller stayed a container because it wanted a filesystem and a long-lived connection pool. The boundary, it turns out, isn't ideology — it's what your workload actually touches.