Skip to main content
← Back

WebAssembly Composition & the Wasm Component Model in wasmCloud

The March 19, 2025 wasmCloud community call centers on the Wasm component model — both at build time and over the lattice. Brooks Townsend demos how to compose WebAssembly components with the wac plug tool, then shows new wash build functionality (in a PR) that performs the same composition automatically using WAC's Rust library, so developers never have to install or learn the CLI. The call then turns to a community proposal from LUK3ARK: "virtual components," a way for components to route invocations over wRPC to services that live outside the lattice — and the security questions that raises.

Key Takeaways​

  • Composing WebAssembly components is core to the component model: one component's import is wired to another's export so a function call in one becomes a function invocation in the other, with no shared memory and no RPC overhead
  • The open-source WAC tool composes components today; wac plug plugs a component's exports into another component's matching imports, collapsing the import/export pair into an internal function call in a single composed Wasm binary
  • A new wash build capability (in a PR at the time) lets you declare a composition in wasmcloud.toml so composition happens automatically after build, using WAC's Rust library — no WAC CLI install required
  • The community debated terminology: Joonas and Colin argued for leaning on existing ubiquitous language ("components" and "composition") rather than WAC's "plug" and "socket," to avoid adding conceptual overhead for new users
  • LUK3ARK's "virtual components" proposal introduces a set-target-component mechanism so a component can route an invocation over wRPC to a service that the wasmCloud runtime has no knowledge of — useful for external/legacy systems and advanced use cases
  • The discussion surfaced a two-tiered lattice mental model: an inner layer of tightly coupled components linked by interface, and external services that don't obey the same link-name rules and must be addressed explicitly
  • Security was the central concern: letting component code decide where to route invocations must not let users skirt wasmCloud's policy service and access-control model; workload identity was floated as a future enabler for joining the lattice securely
  • The team is moving away from the GitHub stalebot auto-closing issues, and Taylor's wasi-config update was deferred to the next call for feedback

Chapters​

Meeting Notes​

Demo: WebAssembly Composition in wash build​

Brooks opened with a backstory on composing WebAssembly components. There are two ways to wire components together in wasmCloud: linking at runtime over the lattice (a distributed RPC layer built on NATS), and linking at build time — the latter being core to the component model itself and entirely outside of wasmCloud. Build-time composition wires one component's import to another component's export so that calling the function in one component invokes the code in the other, with no shared memory and no runtime dependency.

The open-source WAC (WebAssembly Compositions) tool makes this happen. Brooks showed wac plug, which takes the exports of one or more "plug" components and plugs them into the matching imports ("sockets") of another component, producing a single composed Wasm binary. He demonstrated this with a KubeCon-bound demo: a tiny component that exports a validate function over a WIT interface, and a messaging component that imports that same function and exports a messaging handler. After wac plug, inspecting the composed component shows the import/export pair has collapsed into an internal function call — there's no longer a dependency expected from the runtime.

Brooks then showed new wash functionality (in a PR at the time) that lets you declare a composition in your project's wasmcloud.toml, so that after wash build compiles your component, wasmCloud composes it automatically. This uses WAC's Rust library rather than shelling out, which means a developer never needs the WAC CLI installed. The build also preserves both the original and composed components so either can be pushed to a registry. See the docs on interfaces and build and publish for context.

Discussion: Composition Terminology​

Because this functionality surfaces new terms, Brooks asked the community whether to keep WAC's "plug" and "socket" vocabulary. Joonas Bergius argued for leaning into existing ubiquitous language — "components" and "composition" — instead of tool-specific terms that "make no sense to anybody," since every new term is conceptual overhead for no gain. Colin Murphy suggested staying as close to WAC as possible since wac plug is one of the more intuitive parts of the component workflow. Brooks's takeaway: absorb the terminology burden on the wasmCloud side where possible, ideally by parsing the components' imports and exports to figure out how they should compose.

Discussion: Virtual Components and Routing to External Services​

Longtime community member LUK3ARK walked through his "virtual components" proposal and prototype. He framed the lattice as two layers: an inner layer of tightly coupled components, linked by interface (the runtime decides where to send an invocation based on the interface and link, not the calling component), and external services that sit outside that crystalline structure. Because the wasmCloud runtime has no knowledge of external services, his prototype adds a set-target-component mechanism — inspired by the existing set-link-name in the bus interface — so a component can route an invocation over wRPC to a service external to the lattice.

The proposal sparked a wide discussion:

  • Masood (ossfellow) observed that this resembles the future where upstream projects natively speak wRPC and the WebAssembly component model, potentially reducing the need for purpose-built providers — providers today bridge the gap to "legacy" systems like Redis that don't understand wRPC.
  • Colin noted that even if Redis natively integrated wRPC, you'd still need something in wasmCloud declaring "this component can talk to Redis, this one can't."
  • Brooks pointed to wasmCloud's policy service, invoked when a component calls a specific interface, as the place to enforce those rules — and observed that "virtual components" feel a lot like providers, raising the question of whether to fold the idea into the provider model. He floated workload identity as a future enabler for joining the lattice securely.
  • The central concern: component-authored code deciding where to route invocations must not let users skirt the access-control model. Brooks also noted you can fetch the target component from runtime configuration, keeping routing flexible. Follow-up continues in the virtual components PR (#4228).

Administrivia: Stalebot and wasi-config​

The team is trending toward disabling the GitHub stalebot that auto-closes long-open issues, since it can make contributors feel unwelcome when their issue is closed for going stale. Taylor's update on wasi-config — the upstream interface used for component, provider, and link configuration — was deferred to the next call to gather feedback from the contributors who'd already left.

WebAssembly News and Updates​

This call is a tour of where the Wasm component model meets real developer ergonomics — the same composition model that wasmCloud 1.0 brought to enterprise teams (see wasmCloud 1 brings components to the enterprise). Build-time composition with the WAC tool is maturing from a CLI you run by hand into something a build tool like wash can do for you transparently — the same trajectory the broader ecosystem is on with wit-bindgen and Wasmtime. Meanwhile, the "virtual components" conversation previews a future where services across the network speak wRPC and the component model directly, blurring the line between a wasmCloud provider and any wRPC-capable endpoint. Upstream, the wasi-config interface continues to evolve. For ongoing updates, follow the Bytecode Alliance and the WASI subgroup.

What is wasmCloud?​

wasmCloud is a CNCF project that lets you build applications using WebAssembly components and deploy them anywhere — cloud, edge, or Kubernetes clusters. It uses the WebAssembly component model to let you write business logic in any supported language (Rust, Go, Python, TypeScript, C#) while the platform handles capabilities like HTTP, messaging, and key-value storage through a pluggable provider architecture. wasmCloud's reference host is built on Wasmtime, and components communicate over the lattice — a distributed transport layer built on NATS — using the same interface-driven linking that the component model uses at build time. With built-in OpenTelemetry observability and Kubernetes integration, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure.

Topic Deep Dive: The Wasm Component Model​

Both halves of this meeting trace back to the Wasm component model. Build-time composition — the wac plug demo — is the component model in its purest form: two components, each with its own memory and tables, linked on a typed interface so that one component's import becomes a call into another's export, then collapsed into a single portable binary. This is the "write a component once, compose it anywhere" promise made concrete, and bringing it into wash build removes the last bit of friction (installing and learning a separate tool).

The "virtual components" proposal extends the same idea across the network. wasmCloud already does runtime composition over the lattice — linking at runtime lets two distributed components communicate over a single interface as if they were composed together. LUK3ARK's proposal asks: what if one end of that link is a service the runtime doesn't manage and has never heard of? The answer leans on the same interface-driven model plus wRPC as the transport, with wasmCloud's policy service and (eventually) workload identity providing the guardrails. As more of the ecosystem speaks the component model and wRPC natively, the boundary between "component," "provider," and "external service" keeps getting thinner — which is exactly why getting the security model right matters.

Who Should Watch This​

This call is especially valuable for component developers who want to compose WebAssembly components without leaving wash (start with the wac plug demo at 14:14), platform engineers evaluating how wasmCloud links distributed components and where the access-control boundaries sit (the virtual components discussion at 33:52), and contributors thinking about the future of the provider model and how wRPC-native services might join the lattice (Masood and Brooks at 49:31).

Up Next​

Follow-up on the virtual components proposal continues in PR #4228, where the community is gathering feedback on terminology, security, and whether the idea should fold into the provider model. The deferred wasi-config update is slated for the front of the next community call. Expect more on the wash build composition PR and the stalebot decision as well.

Get Involved​

wasmCloud is a CNCF project and contributions are welcome. Join the community:

Full Transcript​

Read the complete transcript with speaker labels and timestamps:

Read the full transcript →