WebAssembly Component Model in Production: A 2026 Field Report

Last year, the Component Model was a story about the future — wit-bindgen, an eventual WASI 0.2, the promise of language-agnostic composition. This year, it's a story about who's already shipping. The component model crossed from "spec under active development" to "default packaging format for at least four production serverless platforms" sometime in 2025, and 2026 is when the rest of the industry noticed.

This is a field report, not a tutorial. The Component Model explained post covers the "what" — this one is the "who, what, and how" of production in 2026.

The Production User List

Shopify Functions is the most-publicly-documented case. Shopify runs every Function as a Wasm module under a 256 KB size cap and 5 ms execution budget, supports JavaScript and Rust as first-class languages, and built its dynamic-linking story to be replaceable by the Component Model when runtimes caught up.

Cloudflare Workers exposes WASI 0.2 components through Jco. The Workers runtime (workerd) consumes a component like a host-side Wasmtime embed; the same .wasm is testable in Node and deployable to the edge.

Fastly Compute has been Wasm-first since 2017. The current line uses StarlingMonkey (Mozilla's standalone SpiderMonkey-based engine) as the JS host and Wasmtime for components — an incremental migration from raw modules.

Fermyon Spin, now an Akamai product line after the 2025 acquisition, treats components as the default packaging format. Spin 4.0.1 (2026-06-09) ships WASI 0.3 as an opt-in executor and uses components as the only first-class application shape — no "classic Wasm module" path for a Spin app.

wasmCloud, CNCF Incubating since 2024-11-08, runs distributed applications as graphs of components linked through WIT. The homepage lists American Express, Adobe, Akamai, and Machine Metrics as production users. Cosmonic (the original creator) still ships a commercial distribution.

Microsoft Hyperlight is the newest entrant: hyperlight-wasm runs Wasm components inside micro-VMs for security-isolated serverless — Wasm speed, VM isolation, function deployability, on the same component primitives as everything else here.

Adobe appears in both wasmCloud's customer lineup and Wasmtime's adopters list. The presence in both is a useful signal that the component model has crossed from "edge startups" to "platform engineering at incumbent software companies."

The Toolchain: Rust → Component → Jco → Browser or Node

The canonical 2026 component-build pipeline is short enough to fit on a Post-it. Author in Rust against a WIT interface, build with cargo component, transpile with jco for the JS/Node world.

// wit/world.wit
package wasmhub:greet@0.1.0;
 
world greeter {
    export greet: func(name: string) -> string;
}

// src/lib.rs
use crate::wasmhub::greet::greet;
 
wasmtime::component::bindgen!({
    world: "greeter",
});
 
struct Greet;
 
impl greet::Guest for Greet {
    fn greet(name: String) -> String {
        format!("Hello from a component, {name}!")
    }
}
 
wasmtime::component::export!(Greet);

The build is two commands:

# Build the component (pulls wasi-preview1/2 adapters from crates.io as of cargo-component v0.15.0)
cargo component build --release
 
# Transpile for Node or the browser (jco v1.24.1, 2026-06-16)
jco transpile target/wasm32-wasip2/release/greet.wasm -o dist/

The output of jco transpile is a self-contained JavaScript module plus a .wasm blob. Drop it in a Vite or esbuild project, import it like a normal JS module, and you get a typed, language-agnostic component running in the browser — no Wasmtime embed, no FFI glue. The same .wasm runs unchanged in Node 26, in Deno, in Wasmtime on a server, and in any of the edge runtimes above. That's not a future story — that's a 2026 fact.

What the Component Model Actually Solved

Three things mattered for production, and the rest is convenience.

Language interoperability. A Rust component exports a function. A Python host imports it. A JavaScript host imports it. Another Wasm component imports it. None write a binding by hand — wit-bindgen generates the language glue from the WIT contract. This unlocks the "use the right language for the job" pattern inside a single application: Rust for image processing, Python for ML inference, JavaScript for orchestration, all running in the same host with typed interfaces.

ABI stability. Before the Component Model, two Wasm modules couldn't reliably link because every language had its own string-encoding, memory-ownership, and error-handling convention. The Component Model fixes the ABI: lists, strings, records, variants, and result types are all standard. A component built today will be consumable by a host built five years from now, because the contract is the WIT, not the implementation.

Security boundaries. A component can only call what its WIT imports declare — no reading the host filesystem, no opening arbitrary sockets. Same isolation model as POSIX capabilities, but expressed in a way that works the same in Node, in a browser, in a server, and in an edge function. For the 2026 production wave — Shopify, Cloudflare, Fastly — this is the property that makes running untrusted user code a tractable problem.

WASI 0.3: Native Async, Five Days Ago

WASI 0.3 was ratified on 2026-06-11 — five days before this post. The headline change is native async in the component ABI: stream<T>, future<T>, and async func are part of the spec now. The old WASI 0.2 dance — start-foo / finish-foo / subscribe / poll — is gone. A component exports an async func and the runtime handles the rest.

The WASI 0.3 announcement calls out the wasi:http service-chaining win: most microservice calls drop from "milliseconds (network hop)" to "nanoseconds (in-process async)" — six orders of magnitude. Wasmtime 45.0.0 (2026-05-21) shipped the first piece — initial async for component functions in the C API — and Wasmtime 46 will default-enable WASI 0.3. Jco v1.24.1 already supports the full WASI 0.3 surface.

For production, the wasi:http service world plus native async is what makes the in-process microservice-chaining pattern work — the architecture Spin, wasmCloud, and Cosmonic have been building toward.

The Registry Shift: From warg to OCI

warg, the original Wasm-component registry, was archived on 2025-07-28. The Bytecode Alliance moved to OCI-based packaging via wasm-pkg-tools — a Wasm component now publishes to any OCI-compliant registry (Docker Hub, GHCR, AWS ECR, Azure ACR, Google Artifact Registry, Harbor).

This is the right call. Operations teams already have OCI registries; security scanning exists; policy engines already understand image digests. A wasm-pkg push my-component.wasm lands in the same registry as the rest of your container images.

What's Next

The Component Model 1.0 roadmap landed on 2026-06-08, three days before WASI 0.3. Remaining work is stability and the features that didn't make 0.3 — shared-everything linking, wasi:gpu, wasi:sql. None of it is blocking production adoption.

The pattern across every name on this list: the Component Model stopped being a "build something for the future" bet and became "this is just how Wasm is packaged now." Vendors that pivoted early (Shopify, Fermyon, wasmCloud) have a multi-year head start; vendors that didn't (Microsoft, via Hyperlight) are now building on the same primitives. The 2027 story is unlikely to be "who's shipping components?" — it's going to be "what's the next spec milestone, and which vendor ships it first."

If you've been holding off because the Component Model felt pre-1.0, 2026 is the year to stop waiting. The users are real, the toolchain is stable, and the same .wasm artifact deploys to a server, a browser, and an edge function without modification.