Skip to main content
← Back

wasmCloud V2: The Wasm Component Model & a Simplified Host

The September 17, 2025 wasmCloud community call is a deep dive into wasmCloud V2 — also called wasmCloud Next — Brooks Townsend's proposal for a "radical simplification" of the platform. He walks through a pull request that introduces a consolidated wasmcloud crate (merging the host, runtime, and core libraries), a simplified Host API focused on scheduling workloads built from WebAssembly components, host plugins that replace built-in capability providers and make the wRPC transport opt-in, and in-process component-to-component calls for components running on the same host. Brooks presents C4-style architecture diagrams for the new model, and Eric Gregory previews a next version of the docs.

Key Takeaways​

  • wasmCloud V2 is a simplification, not a disruption. Brooks framed "V2 / Next" as evolving past the current 1.x line (which has been stable for ~18 months, through 1.9) rather than a wave of breaking changes — the goal is to focus wasmCloud on what it does best: being a great WebAssembly application runtime.
  • A consolidated wasmcloud crate merges the previously separate host, runtime, and core Rust libraries into a single library-plus-binary crate, making it much easier to add features, embed wasmCloud, or extend the host without cloning and patching internals.
  • The simplified Host API is a trait for scheduling workloads — declarative collections of WebAssembly components and configuration, conceptually a wadm application rolled forward with cleaner separation of concerns.
  • Host plugins wholesale replace built-in capability providers. They participate in the Wasmtime linker, can be feature-flagged on or off, and crucially make the wRPC transport itself an opt-in plugin rather than a hard requirement.
  • In-process component-to-component calls let components in the same workload talk directly through a lightweight linker "trampoline," avoiding a round trip over the NATS/wRPC transport for low-latency local calls.
  • Running NATS Jetstream is no longer prescribed at the host level. The host is responsible only for its own workloads; a control plane such as wadm or the Kubernetes operator handles scheduling and distribution.
  • Distribution stays OCI-based and efficient. Components are still pulled from an OCI registry, cached locally, and held as pre-compiled, pre-instantiated instances — with an instance pool planned to drive startup latency down further.
  • The docs are getting a next version built iteratively alongside Wasm Shell (the next generation of wash), using the community Excalidraw library for the new architecture diagrams.

Chapters​

Meeting Notes​

wasmCloud V2 and the Consolidated wasmcloud Crate​

Brooks opened the deep dive on wasmCloud V2 (a.k.a. wasmCloud Next) by walking through a pull request he opened in the wash repository consolidating the libraries used to run wasmCloud. He was careful to defuse any "big breaking change" anxiety: the version label simply reflects that the wasmcloud crate itself was already on 1.9, and this is the next step in its evolution. The change introduces a single library-and-binary crate that consolidates the host, runtime, and core libraries that had previously been maintained as separate internal crates — a separation Brooks said wasn't productive for adding features, embedding wasmCloud, or extending the host.

At the heart of the proposal is a simplified Host API: internally just a trait, implemented on the host, that supports scheduling workloads. A workload is a declarative collection of WebAssembly components plus configuration with a name and namespace — "essentially the idea of a wadm app rolled forward with a better degree of separation." The crate's engine is a loose wrapper around Wasmtime, responsible for linking a workload's components into the Wasmtime linker so they can use WASI interfaces and call each other.

Host Plugins and an Opt-In wRPC Transport​

The biggest architectural shift is host plugins, a near-wholesale replacement for built-in capability providers. Today, baking capabilities into the host means cloning the host repo and modifying internal code; the plugin mechanism instead lets you embed the host and extend it statically. Built-in behaviors like WASI logging become plugins that can be feature-flagged off, and — answering a question from Taylor Thomas — the wRPC layer itself becomes an opt-in transport plugin. Workloads declare, per set of interfaces, whether calls should go over wRPC (and thus over a NATS message bus or TCP socket) or be satisfied locally. That makes wasmCloud deliberate about exactly which interfaces cross the network boundary, and removes the requirement to run NATS for local development.

C4 Architecture Diagrams and the Three Personas​

Brooks introduced C4-style architecture diagrams (renaming the awkward "container" layer to "application services") to communicate the new model. The system context layer covers three ways people interact with the platform: the developer, who curl-installs wash and uses build/dev commands before pushing to an OCI registry; the edge deployer, who runs wasmCloud as a plain binary (or systemd service) executing multiple workloads; and the platform engineer, who deploys wasmCloud on Kubernetes via an operator and the Kubernetes API server. A key boundary he drew: in Kubernetes, wasmCloud runs as a normal container (the WebAssembly is not executed on containerd), and wRPC extensions run as their own containers or sidecars rather than as host-spawned binaries. The diagrams were built with the community Excalidraw library that Eric Gregory and Aditya have been assembling.

In-Process Component-to-Component Calls​

A roadmap item Brooks demonstrated as working in the new crate is in-process component-to-component calls. Today every invocation travels over the NATS/wRPC transport; in V2, when a workload's components share matching imports and exports, the host resolves those dependencies locally and wires them together with a lightweight linker "trampoline." His example used a component importing wasi:blobstore paired with a blobstore-filesystem component that exports wasi:blobstore (backed by wasi:filesystem): a create-container call is trampolined to a freshly instantiated filesystem component, which is then reused across the workload's lifecycle. For components that end up running remotely, the same call can fall back to the wRPC plugin (over NATS) or to HTTP / message-bus capabilities — Brooks noted teams often already have a service mesh and prefer routing over HTTP.

Efficiency, Footprint, and the next Docs​

Frank Schaffa pressed on whether the new features compromise WebAssembly's fast-start, small-footprint value. Brooks confirmed component handling is essentially unchanged: artifacts are still pulled from OCI, cached on disk, and held as pre-compiled, pre-instantiated instances, with a planned instance pool to trade a little memory for near-zero startup latency. Frank also raised leveraging existing platforms like Kubernetes to accelerate adoption, which Brooks welcomed. Finally, Eric Gregory previewed a next version of the docs, built iteratively alongside Wasm Shell (the next generation of wash), starting from the key developer and operator flows.

WebAssembly News and Updates​

This call is a window into how the wasmCloud project is rethinking its core architecture around the Wasm component model. The headline is the consolidated wasmcloud crate and a simplified Host API that treats a workload — a set of WebAssembly components plus configuration — as the fundamental unit of deployment. The move to host plugins and an opt-in wRPC transport, combined with in-process component-to-component calls, points toward a leaner runtime that can run as a single process with no mandatory NATS dependency for local development. Brooks also flagged that WASI Preview 3 work was actively moving at the time of the call; for the broader picture, see the wasmCloud post on WASI Preview 3 on wasmCloud. For ongoing updates, follow the wasmCloud blog and the Bytecode Alliance.

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#, and more) 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 — as this call shows — it is evolving toward a consolidated, embeddable runtime with host plugins and a simplified Host API. 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​

Nearly every design choice in this meeting traces back to the Wasm component model. The simplified Host API schedules workloads — collections of components — and the engine's main job is to link those components into the Wasmtime linker so they can import and export typed interfaces (WASI and beyond). Host plugins work because they participate in that same linker: a plugin that implements wasi:keyvalue is, from the component's perspective, indistinguishable from any other host function. The in-process component-to-component story is the component model taken to its logical conclusion — when two components in a workload have matching imports and exports, wasmCloud can satisfy the dependency directly, trampolining one component's call into another with no network hop. That same typed-interface contract is what lets a call gracefully fall back to wRPC-over-NATS when the components live on different hosts. As the platform leans harder into the component model, the unit of deployment, linking, and routing all converge on the same primitive: a WebAssembly component with a well-defined interface.

Who Should Watch This​

This call is especially valuable for platform engineers and operators evaluating where wasmCloud is heading — the simplified Host API, host plugins, and the consolidated crate (start with the PR walkthrough at 4:18); architects weighing in-process versus distributed component communication and the move to an opt-in wRPC transport (the trampoline deep dive at 34:29); and runtime and Rust developers interested in embedding or extending the wasmCloud host, including the WASI WebGPU plugin use case (at 22:00).

Up Next​

The next two community calls were set to be hosted by others while Brooks was on vacation, with plans to dive deeper into the Kubernetes story and the moving pieces in WASI Preview 3. Watch for continued iteration on the consolidated wasmcloud crate, the next docs version, and the crate-consolidation PR landing in wash.

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 →