Skip to main content
← Back

wasmCloud Q3 2025 Roadmap: Component Model, wRPC & a Simpler Host

The July 9, 2025 wasmCloud community call was the Q3 2025 community roadmap planning session. Brooks Townsend recapped a Q2 driven largely by community contributors, then walked a slate of proposals that all push toward a simpler, more standards-aligned platform built on the Wasm component model: in-process component-to-component calls, dropping wasmCloud-specific signing for standards like Sigstore, shared platform-level capability providers, reframing providers as wRPC servers, trimming built-in WASI interfaces, reducing host responsibilities so an external scheduler drives the host, and making wasmCloud's distributed networking intentional rather than implicit. WASI Preview 3, expected in August, frames much of the work.

Key Takeaways​

  • Community-driven Q2: the new research / development / good-first-issue split paid off — the vast majority of good-first-issue items were closed by community contributors, and the team will surface a fresh "issue of the week" from that list on each call
  • In-process component-to-component calls: co-located components should be able to skip the wRPC/NATS round trip (microseconds → nanoseconds), but the host should be told explicitly — likely a transport field on links — rather than deciding at call time, which keeps host simplification on track
  • Standards over custom signing: wasmCloud's wascap and nkeys signing are largely vestigial (signing is optional, claims aren't used for routing), so the proposal is to move toward broadly adopted standards like Sigstore while keeping a config interface around
  • Shared, platform-level capability providers: rather than bundling a provider per OAM application, the platform should expose shared providers many components can reuse — so three HTTP components share one server via paths/ports instead of three full server instances
  • Capability providers as wRPC servers: reframe a provider as any binary, container, or component that serves a WIT interface over a wRPC transport (TCP, NATS, QUIC, UDP), building on Luke's virtual components idea so the host stops managing native process lifecycles
  • Fewer built-in interfaces: stop baking draft WASI interfaces into the host; keep only stable WASI P2/P3 plus wasmCloud lifecycle interfaces, and lean on custom interfaces (like the Postgres provider) for the rest — Taylor flagged keeping wasi:config
  • A smaller, embeddable host: the host should wrap the runtime, expose a wRPC server API, and wait for a scheduler — wadm, Kubernetes, or wash — to tell it what to run, with the control API as simple as "here's a component and everything it needs, run it"
  • Intentional distributed networking: let same-host components call each other directly, and require explicitly opting in to distributed calls via wRPC-error-aware interfaces or messaging, instead of implicitly turning every component call into a NATS request — WASI Preview 3 and native async land in August and frame much of this

Chapters​

Meeting Notes​

Q2 Retrospective: A Community-Driven Roadmap​

Brooks Townsend opened by reflecting on the Q2 roadmap and the format change that organized every ticket into research, development, or good first issue rather than feature/bug/docs categories. The split made the roadmap more approachable: experienced contributors could take development items, maintainers could take open-ended research, and newcomers had a clear on-ramp through good-first-issues. It worked. Brooks highlighted that — apart from a couple of items he kept for himself — essentially every good-first-issue was completed by a community member or contributor, naming new contributors who jumped in to fix issues like allow-latest not taking effect, the XDG base directory migration for the .wash directory, and wash dev dashboard work.

On the larger pieces of work, the team made strong progress on wash plugins (WebAssembly component plugins that add subcommands), a reimagined plugin-first wash, the wash dev dashboard and OpenTelemetry debugging story, and workload identity. Two items — deep design exploration of HTTP and a flaky provider/key-value/NATS issue — rolled forward into Q3. All of the planning ran out of the wasmCloud roadmap GitHub project, which remains the place to leave feedback.

wasmCloud Q2 roadmap board with research, development, and good-first-issue columns

Community Wins, NATS, and the Road to WASI Preview 3​

Brooks gave a shout-out to community work that wasn't even on the roadmap — most notably a NATS blob store capability provider, which means a wasmCloud deployment can now get messaging, persistent key-value, and a distributed object store all from the same NATS infrastructure. He framed this as effectively covering the WASI cloud world (config is also stored in NATS JetStream), reinforcing that wasmCloud and NATS are settling in to work better together in the CNCF space with no architectural changes needed.

He also acknowledged the maintainer time flowing into WASI Preview 3, which the team intentionally keeps off the wasmCloud board because wasmCloud is only a small-but-critical part of the upstream effort. Bailey Hayes stewards the standards at the Bytecode Alliance, Victor Adossi works on JavaScript/JS-runtime component tooling, and Roman (creator of wRPC) has been implementing WASI P3 and component-model async in Wasmtime. Brooks noted that WASI 0.3 previews are expected in August, refactoring P2 interfaces like HTTP and IO and adding native async to the component model — a huge piece of work that frames the entire Q3 roadmap.

Q3 Proposal: In-Process Component-to-Component Calls​

Turning to Q3, Brooks anchored the discussion in his "A Year of wasmCloud 1.0" reflection and its "charting the next steps" feedback. The first development proposal: in-process component-to-component calls. Today every component-to-component call goes over wRPC with NATS as the transport — consistent and predictable, but a couple hundred microseconds of overhead and subject to transport failures. Components composed in the same Wasmtime instance can call each other with a few nanoseconds of overhead, and Brooks wants co-located components to be able to communicate directly when an operator deliberately places them together.

Massoud (ossfellow) pushed back that this needs more intelligence in the host to route in-process vs. out-of-process traffic, which works against the parallel goal of trimming host responsibilities. Brooks agreed and clarified the principle: the host should be told exactly what to do — "you're running these two components and they're going to talk to each other in process" — rather than making a game-time decision when a function is called. A transport field on links (NATS, wRPC/TCP, or in-process) is one way to express it; that item stayed in triage for more design.

Q3 Proposal: Dropping wascap/nkeys for Signing Standards​

A spicier proposal: stop using wascap and nkeys for signing components and providers. wasmCloud no longer uses them for routing or capability claims, signing isn't required to run a component (a 1.0 decision so you can run anything off the shelf), and the extra signing step adds confusion. Brooks argued the project has had more success ditching wasmCloud-specific standards in favor of emerging ones like Sigstore, and asked Massoud — who had researched signing artifacts — to write up findings. Massoud agreed signing is increasingly preferred over not-signing, and a more compliant framework suits corporate users. Taylor Thomas was on board with removing nkeys but flagged that the cryptographically-unique string format was historically useful for routing and worth double-checking with heavier users; he noted SPIFFE and Ed25519 keys could fill the gap.

Q3 Proposal: Shared, Platform-Level Capability Providers​

In the research category, Brooks proposed configuring a wasmCloud host with shared capability providers. Today most users deploy with wadm using the OAM (Open Application Model) manifest, which bundles components and providers into an application — great for a few isolated apps, less optimal at scale because it undermines density. wasmCloud already added a "shared provider mode" after 1.0, but Brooks wants a cleaner story: a set of providers configured at the platform level and reusable by many components, so three HTTP components each get a port, path, or host name on one shared server instead of three full server instances.

Massoud raised the hard question of where link configuration lives when the provider is the source, and Taylor pushed for an end state where the platform is configured with capabilities up front — leaning on WIT imports/exports and Kubernetes-style label targeting — to escape the confusing "source/target" terminology. Brooks captured the consensus that providers should carry minimal configuration and let the component side express most of the routing intent.

Diagram of multiple components sharing capability providers on a wasmCloud host

Q3 Proposal: Capability Providers as wRPC Servers​

Brooks then proposed reframing the capability provider model itself. Providers were invented before WebAssembly had standard interfaces for networking and the file system; today they're distributed as native binaries per architecture in OCI tarballs, launched by the host, and fed configuration over stdin. He'd rather think of a provider as a wRPC server (name pending): any binary, container, component, or application that serves a WIT interface over a transport wRPC already supports — TCP, NATS, QUIC, UDP. This builds on Luke's virtual components proposal, where anything addressable over wRPC is callable.

The payoff is host simplification: the host stops executing and supervising native binaries across Linux/Mac/Windows and stops worrying whether a provider actually started — it just executes components, while providers are orchestrated by Kubernetes, Nomad, or Nix in production and run as simple in-process components for local development. Taylor asked the team to nail down registration/discovery so the platform knows which providers are available across a lattice.

Proposed wasmCloud host architecture with providers as wRPC servers and a control plane

Q3 Proposals: Simpler Interfaces, a Smaller Host, and Intentional Networking​

Three closely related proposals closed the session. First, simplifying interface maintenance: the host currently builds in bindings for wasi:logging, wasi:keyvalue, wasi:blobstore, wasi:messaging (0.2 and 0.3), and config interfaces, which is costly to maintain as drafts evolve. The plan is to build in only stable WASI (P2, then P3) plus wasmCloud lifecycle interfaces, and lean on custom interfaces — like the Postgres provider, indistinguishable from a built-in — for everything else. Taylor argued wasi:config should stay; Brooks agreed config is a reasonable exception.

Second, reducing host responsibilities: today the host manages OS processes, reconciles state with a global NATS JetStream bucket, fetches secrets, checks policy, and publishes events. Brooks wants a smaller core that wraps the runtime, exposes a wRPC server API, and waits for a scheduler — wadm, Kubernetes, or wash locally — to issue a simple "run this component, here's everything it needs" instruction via a control API. Lucas Fontes agreed much of the current behavior is vestigial from a pre-wadm era when hosts were driven directly.

Third, intentional distributed networking: wasmCloud's seamless distributed model implicitly turns every component call (even wasi:keyvalue or wasi:blobstore) into a wRPC-over-NATS request, which is powerful but a little scary in production. wasmCloud introduced wRPC error support so custom interfaces can return a result and handle transport failures instead of panicking when no provider answers. Brooks wants distributed calls to be opt-in — via wRPC-error-aware interfaces or an explicit messaging interface — and in-process calls to be the default for co-located components, making deployments more predictable for platform engineers.

WebAssembly News and Updates​

The dominant news thread on this call was WASI Preview 3, with 0.3 previews expected in August. WASI P3 refactors P2 interfaces such as HTTP and IO and brings native async to the Wasm component model — a substantial undertaking led upstream at the Bytecode Alliance, with wasmCloud maintainers Bailey Hayes (standards), Victor Adossi (JavaScript component tooling), and Roman (Wasmtime implementation and component-model async) all contributing. On the ecosystem side, the new community-contributed NATS blob store provider rounds out wasmCloud's NATS-backed capability set (messaging, key-value, blob store, and config), and wash continues its evolution toward a plugin-first developer experience. For ongoing updates, follow the wasmCloud blog and the WASI subgroup. (For background on the previous milestone, see WASI Preview 2 officially launches.)

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, connects hosts over NATS via wRPC, and distributes components and providers using OCI. 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 proposal on this call traces back to the Wasm component model. In-process component-to-component calls are only thinkable because components composed in the same runtime can invoke each other's typed functions at near-zero cost; the question is just whether the call crosses a wRPC transport. Reframing capability providers as wRPC servers works because a provider is, at bottom, something that serves a WIT interface — the same contract a component exports — so a provider, a binary, a container, and a component become interchangeable behind that interface. Simplifying interface maintenance is a bet that the component model's stable, versioned interfaces (WASI P2, then P3) are durable enough to build in, while drafts belong in user-space custom interfaces. And WASI Preview 3 is the component model gaining native async, streams, and futures — the upstream work that makes interfaces like HTTP cleaner and unblocks much of wasmCloud's Q3 plan. The throughline: as the component model matures, the host can do less — execute components, route over wRPC when needed, and let a scheduler drive — while the platform does more. Learn more in the docs on components and interfaces.

Who Should Watch This​

This call is especially valuable for wasmCloud operators and platform engineers weighing how the platform should evolve — shared providers, a smaller host driven by a scheduler, and predictable component placement all land squarely in their world (start with the shared-providers discussion at 40:10). Distributed-systems and runtime engineers will want Brooks' deep dives on in-process calls and intentional networking (27:00 and 1:23:37). And prospective contributors should watch the Q2 retrospective (6:22) to see how the good-first-issue list turns into merged PRs — then claim one from the roadmap project.

Up Next​

Q3 work flows directly from these proposals, framed by WASI Preview 3 arriving in August. Expect design RFCs and spikes on in-process component-to-component calls (and a transport field on links), research into Sigstore-based signing, platform-level shared providers, the wRPC-server reframing of capability providers, a trimmed set of built-in interfaces, and a smaller host driven by an external scheduler. Brooks also teased sharing more of the plugin-first wash redesign on an upcoming call. Leave your thoughts on any of these in the wasmCloud roadmap GitHub project.

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 →