Skip to main content
← Back

Wasm Component Model vs Capability Providers & the wash Plugin System

The August 27, 2025 wasmCloud community call digs into how the Wasm component model is reshaping wasmCloud's architecture. Brooks Townsend tours the new wash plugin system — hooks, dev register plugins, and top-level commands, all powered by WebAssembly components — and opens a Q3 roadmap discussion with maintainer Aditya on rethinking the application abstraction and increasing provider density. Brooks and Bailey Hayes make the case for leaning into wRPC over the capability-provider SDK and for letting components, with WASI P3 on the horizon, take over many jobs that native providers do today through bin packing, dynamic linking, and Cranelift optimizations.

Key Takeaways​

  • The wash plugin system treats WebAssembly components as the universal plugin model. It has three categories: hooks that run before or after any wash command, dev register plugins that implement interfaces without running providers, and top-level commands that add new wash subcommands running in the secure component sandbox.
  • A dev register plugin can replace a capability provider entirely. The example Blobstore filesystem plugin implements wasi:blobstore in terms of wasi:filesystem, so wash dev can serve blob storage with no provider and no external process — wash itself knows nothing about the interface.
  • The application abstraction is the wrong unit of deployment at scale. Brooks argued that a wasmCloud application as "a collection of components and providers" works for the first deployment, but breaks down once you share one HTTP server provider across many independently managed components.
  • Provider density and multiplexing are the core roadmap problem. Aditya pointed out that most providers assume they serve one component, so increasing density means handling many components' ingress and egress through a single shared provider while preserving availability.
  • The future of capability providers is wRPC, not the SDK. Brooks proposed largely dropping the provider SDK so a provider becomes "just implement this interface" — much like authoring a component — and any language with a wRPC bindgen (e.g. Java) that can reach NATS could implement one.
  • Components are poised to take over many provider use cases. Bailey Hayes argued that with WASI P3 and a service concept in the next host, bin packing components in one Wasm runtime unlocks dynamic linking and Cranelift ahead-of-time optimizations like trampolining composed components — something a separate native process can never match.
  • Go 1.25 currently breaks component builds. Egor flagged the issue; the fix is updating to the latest TinyGo (0.39), and Brooks plans to add a wash doctor-style check for the Go/TinyGo version pairing.
  • A new setup-wash GitHub Action shipped to the Marketplace. Bailey announced the action — which points at the release-candidate next version of wash — plus a companion blog post recapping the plugin system.

Chapters​

Meeting Notes​

The wash Plugin System: Components All the Way Down​

Brooks opened by pointing at a new blog on the wash plugin system landing on the site. While wash already had a way to run components, it lacked comprehensive integration into the CLI flow. The new system leans fully into the idea that WebAssembly components are the last plugin model you'll ever need: wash should drive a great component development and running experience, with everything wasmCloud-specific delivered as Wasm plugins.

There are three categories of plugin. Hooks run before or after any command in the wash lifecycle — inserting a template before wash new, attaching annotations before pushing to an OCI registry, or launching an OpenTelemetry container before wash dev. A special kind of hook, dev register, lets a plugin implement custom interfaces so you don't need to run capability providers or external processes at all. The example Blobstore filesystem plugin lives in the wash tree and implements wasi:blobstore in terms of wasi:filesystem: install it and wash dev can serve blob storage on your local filesystem, even though wash knows nothing about that interface. The third category, top-level commands, registers your own wasi:cli-style subcommands that appear in wash --help and run inside the secure component sandbox. Brooks invited contributors to take on good first issues in the wash repo.

Rethinking the Application Abstraction​

The main discussion item came out of Q3 roadmap planning: the abstraction of a wasmCloud application — a collection of components and providers — isn't quite right. It works for "baby's first wasmCloud" deployment, but as soon as you use one HTTP server provider to serve endpoints for many components, while still wanting to manage those components' lifecycles separately, it stops describing the right unit of deployment. wadm's notion of a shared application or shared provider helps, but Brooks framed the whole topic as an open call: there has to be something better.

Maintainer Aditya picked it up off the cuff. The host today runs a multi-app setup with duplicate providers, so the question is how to increase provider density and handle the multiplexing that comes with it. Most providers assume they serve a single component (the HTTP server is the exception, with path-based routing). For messaging queues, blob stores, and the like — each with their own differentiators such as streams or subjects — the open problem is keeping the number of providers to a minimum while managing many components' ingress and egress, and doing so without changing how providers are written.

From the Provider SDK to wRPC​

Brooks connected Aditya's question to a related roadmap item he and Luke Arch have been brainstorming: transitioning the capability provider from something wasmCloud-specific (built on the provider SDK, making all its own decisions about configuration and lifecycle) toward leaning much more heavily into wRPC. Today, the hard part of writing a provider isn't the business logic — handling a wasi:keyvalue atomic-increment invocation is easy — it's the surrounding work of running the provider, connecting to wasmCloud, and managing the initial list of links.

The vision: a provider should be little more than the contract. You implement the interface, declare the configuration you need (which database to connect to, for example), and that's it — much like authoring a component that exports interfaces. Dropping the SDK also frees the implementation language: in a world with a wRPC bindgen for Java, you could write a small Java process that implements an interface, and if it can connect to NATS, wasmCloud can connect to it. The concrete next step Brooks named was simply leaning a little more into wRPC.

Availability, Component Density, and WASI P3​

Aditya raised availability: if you merge two applications' separate Redis providers into one shared Redis provider, availability becomes more predictable — but you need to update a single provider's config without tearing it down and starting a new one, so you don't disrupt other components' workloads. Brooks argued that's the most important capability for availability in a multi-tenant mode, and didn't see it being harder than today.

Bailey Hayes widened the lens to WASI P3 and the component model. Providers have always been the escape hatch for "this doesn't compile to Wasm, so let's extend the host with native code." With WASI P3 and a service concept in the next host (something long-running and stateful, like a provider, but a component), components will take over many use cases that previously required providers. Bailey explained why this is a game changer: components are blocks you can bin pack into a single WebAssembly host, stacking their memories into one allocation slab — whereas a native process has to run in a container or alongside the host. Bin packing enables co-location of tightly coupled workloads and dynamic linking within the runtime, which in turn unlocks Cranelift ahead-of-time optimizations like trampolining composed components together. Brooks summed up the provider model's biggest problem: components are far denser than separate processes opening ports, so they're hard to scale at the same rate — and the roadmap issue's title may be a little misleading now that components can fill so much of the provider role.

Closing Items: Go 1.25, TinyGo, and a New GitHub Action​

In wrap-up, Egor reported that components fail to build on the latest Go (1.25). Bailey and Brooks traced it to needing the latest TinyGo release (0.39), and Brooks said he'd add a wash doctor-style check to flag the Go/TinyGo version pairing. Bailey then shared a new setup-wash action now in the GitHub Marketplace: it makes it easy to get going with the next version of wash, pointing by default at the release candidates Brooks has been cutting. She also published a companion blog post recapping the plugin system, and noted she'd like to add plugin enumeration to the action.

WebAssembly News and Updates​

This call is a snapshot of WebAssembly's component model maturing from a packaging format into an architectural foundation. The thesis that WebAssembly components are the last plugin model you'll ever need now drives wash's plugin system, while the roadmap conversation shows the component model reaching deep into how wasmCloud runs capabilities — replacing native capability providers with bin-packable components and a thinner wRPC-based contract. On the runtime side, the discussion previews how WASI P3 and a long-running service concept will let components do work that used to demand a separate process, with Wasmtime and Cranelift handling dynamic linking and ahead-of-time optimization. On the toolchain front, Go 1.25 compatibility now depends on the latest TinyGo. 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#) 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 connects components, providers, and hosts over NATS. With the new wash plugin system and an evolving model where components increasingly do the work of native providers, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure.

Topic Deep Dive: The Wasm Component Model​

Nearly every thread in this meeting traces back to the Wasm component model. The wash plugin system exists because components can implement standard WIT interfaces and run in a secure sandbox — a dev register plugin like the Blobstore filesystem example is a component satisfying wasi:blobstore, which is exactly why it can stand in for a capability provider. The provider-density discussion is the same idea at platform scale: as components, via the component model and WASI P3, take over what capability providers do today, wasmCloud can bin pack them into one Wasm runtime instead of running a separate native process per capability. That density is what makes dynamic linking and Cranelift's trampolining optimizations possible — composing two components so the runtime can call between them ahead-of-time-compiled and efficient. And the move from the capability-provider SDK to wRPC is the component model's typed-interface philosophy applied to providers: implement the contract, declare your config, and let any language with a wRPC bindgen participate. The bet is that the component model becomes the universal contract across components, providers, plugins, and the languages that target them.

Who Should Watch This​

This call is especially valuable for wasmCloud platform engineers and operators weighing how shared providers and provider density will change at scale (Aditya's roadmap discussion from 11:24), capability provider authors curious about the move from the provider SDK to wRPC and what it means for writing providers in new languages (Brooks at 15:37), and component and CLI developers who want to extend wash with hooks, dev register plugins, or top-level commands (the wash plugin system tour at 3:17). Go developers building components should note the Go 1.25 / TinyGo fix at 29:52.

Up Next​

The next community calls continue the Q3 roadmap thread: more research on shared capability providers and provider density, concrete steps toward leaning into wRPC for providers, and progress on the path that lets components — with WASI P3 and a long-running service concept — take over more of what native providers do today. Watch also for the Go 1.25 / TinyGo guidance to land in wash and for feedback on the new setup-wash GitHub Action.

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 →