Skip to main content
← Back

In-Process Component Calls & the Wasm Component Model

The September 3, 2025 wasmCloud community call digs into the Wasm component model as the foundation for a leaner, more modular runtime. Brooks Townsend walks through in-process component-to-component calls — letting two components on the same host talk directly instead of going over wRPC/NATS, dropping latency from hundreds of microseconds to single-digit nanoseconds — and a broader effort to shrink the wasmCloud host's responsibility down to component lifecycle management, with capabilities provided through an optional plugin layer. Bailey Hayes closes with a quick demo of new shell auto-completions in the wash CLI.

Key Takeaways​

  • In-process component-to-component calls let two components linked on the same host invoke each other directly, cutting latency from a few hundred microseconds (the wRPC/NATS loopback) down to single-digit nanoseconds — essentially just the cost of crossing the component boundary
  • Intentional distributed networking is the quarter's theme: local calls stay local by default, and you opt into distributed communication explicitly via wRPC or an interface like WASI HTTP or WASI messaging when you actually want network semantics
  • The work was prototyped in wash dev, where Brooks built a self-contained dev loop that links a component's imports to another component's exports — demonstrated by a blobstore-filesystem component that implements wasi:blobstore by storing data on the local file system, with the runtime needing to know nothing about blob store at all
  • A major roadmap item is reducing the host's responsibility and API surface: the host becomes responsible only for the component lifecycle (download from OCI, start, link, status, stop), exposed through a small Host trait that is trivial to unit test without NATS
  • Capability implementations move out of the runtime core into an optional plugin (built-in) layer — HTTP server, HTTP client, NATS messaging, runtime config, logging — that you can turn on or off, while a wRPC plugin can route specific interfaces over the network
  • At its base the wasmCloud runtime crate is "slightly wrapped Wasmtime": you get WASI 0.2 (plus outgoing HTTP), resource limits, and hooks to extend interfaces consistently across multiple plugins, rather than hand-wiring every capability callback yourself
  • The terms workload (a collection of components that make up one functionality) and service (a long-running component that exports wasi:cli/run) were introduced, opening the door to scale-to-zero, sandboxed capability providers once WASI Preview 3 brings async reentrancy
  • Bailey demoed wash CLI shell completions (built on Clap's auto-complete support) — including completions for installed plugin subcommands — landing in the next wash release as the next-generation CLI moves toward 1.0

Chapters​

Meeting Notes​

In-Process Component-to-Component Calls​

Brooks opened on a frequently requested feature: when two components run on the same host — executing in the same Wasmtime engine — and one exports an interface the other imports, why route that invocation out over wRPC and NATS? wasmCloud had long held the principle that everything goes over the RPC layer for behavioral consistency, accepting a small local loopback penalty in exchange. But for components co-located on a host, calling each other directly drops latency from a few hundred microseconds to the single-digit nanosecond range — essentially just the time to pass a value across the component boundary.

This fits the quarter's theme of intentional distributed networking: components on the same host can call each other in process, and when you want a call to cross the network, you opt into that explicitly via wRPC or an interface like WASI HTTP or WASI messaging that gives you control over the RPC semantics. Brooks credited Roman on the wasmCloud/Wasmtime side for the blueprint on lifting and lowering values between components. The discussion tracked the support in-process component-to-component calls roadmap issue.

Prototyping in wash dev with Plugin Exports​

The work was spiked in wash dev, where Brooks wanted a self-contained local development loop — no need to download NATS, wadm, providers, or remote components, and no process-orchestration headaches on Windows. Rather than pretend-linking every unrecognized import to wRPC (how the production host supports arbitrary custom interfaces today), wash dev explicitly links a known set of interfaces — WASI 0.2, WASI HTTP, plus widely used draft interfaces like WASI logging and WASI runtime config — and then links a component's remaining imports to other components' exports.

He demonstrated the idea with a blobstore-filesystem component that implements wasi:blobstore by storing objects on the local file system (it imports wasi:filesystem to do so). When an application like blobby imports wasi:blobstore, those calls go component-to-component to that implementation — and the runtime layer needs to know nothing about blob store at all. The same pattern could implement wasi:keyvalue against Redis, and so on.

Reducing Host Responsibility and the Plugin Layer​

The second discussion — tracking the reduce host responsibility and API surface roadmap issue — connected directly to the first. Today the wasmCloud runtime crate is, at its core, "slightly wrapped Wasmtime" — give it WASI 0.2 and a wrapped component back — but capability implementations and the wRPC poly-filling are baked into the runtime. Brooks is extracting and evolving this into a runtime crate (prototyped in the wash repository) with a much smaller surface: initialize a component from bytes, apply resource limits, mount volumes, and hand back a workload handle.

A new minimal Host trait boils the host's job down to lifecycle: heartbeat, start a workload, query a workload's status, and stop it — all unit-testable without touching NATS. A workload is a collection of components making up one functionality (an evolution of the wadm application), and a service is a long-running component that exports wasi:cli/run. Capability implementations move into an optional plugin layer: HTTP server, HTTP client, NATS messaging, runtime config, and logging become built-in plugins you turn on or off, each participating in the link lifecycle for a component's imports and exports, while a wRPC plugin can route specific interfaces over the network.

Scale-to-Zero Providers and a wash Completions Demo​

Audience member ossfellow asked whether exposing the Wasmtime store to components could let providers stop being long-running processes — instantiated only on an incoming call. Bailey agreed that's the big idea: a service-type workload is intentionally long-running, while a plain component's lifetime is tied to its store, and with WASI Preview 3's async reentrancy you could have scale-to-zero capability providers that are themselves sandboxed components. Brooks noted stateless capabilities like logging, or stateful-but-simple ones like the file-system blob store, no longer need a dedicated long-running process — even a cron provider could just be an idle component.

Bailey wrapped up with a fast demo of wash CLI shell completions. Clap (the CLI crate wasmCloud uses) supports auto-completion via an add-on crate, so wiring it up took about 10 minutes — most of the effort went into documenting the many ways shells load completions. Typing wash n<tab> completes to wash new, wash b<tab> to build, and wash oci <tab> offers push/pull. Completions even surface installed plugin subcommands, tested live against a plugin that registers a top-level command. It lands in the next wash release as the next-generation CLI closes in on 1.0.

WebAssembly News and Updates​

This call is a snapshot of wasmCloud rethinking its runtime around the strengths of the Wasm component model. The headline architectural shift — in-process component-to-component calls plus a host whose responsibility shrinks to lifecycle management — is made possible because WebAssembly components compose through typed interfaces, so a "blob store" or "key-value" capability can be just another component you link in rather than a network service you stand up. The team also looked ahead to WASI Preview 3 and its async reentrancy as the unlock for scale-to-zero, sandboxed capability providers. For ongoing updates, follow the Bytecode Alliance and the wasmCloud blog.

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 runtime is built on Wasmtime, and — as this call shows — that runtime is evolving toward a small, composable core: the host manages component lifecycle, capabilities are delivered as optional plugins, and co-located components can call each other in process at nanosecond latency. 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 thread in this meeting traces back to the Wasm component model. Because components expose and consume capabilities through typed interfaces (WIT/WASI), a capability like blob storage can be implemented by a component and linked into an application — no special runtime knowledge required. That is exactly what makes in-process component-to-component calls clean: linking one component's export to another's import is the same composition primitive the component model already defines, just resolved locally instead of over the network. It is also what lets the wasmCloud host shed responsibility — built-in capabilities become plugins that satisfy interfaces, custom interfaces can be satisfied by other components, and only truly distributed calls fall back to wRPC. As WASI Preview 3 adds async reentrancy, the component model's promise — compose isolated components through typed contracts without trust escalation — extends all the way to scale-to-zero capability providers running as ordinary sandboxed components.

Who Should Watch This​

This call is especially valuable for platform engineers and runtime builders thinking about latency and topology — the in-process call work and the new minimal host API start at 6:00 — for wasmCloud operators and capability authors weighing built-in plugins versus separate providers (the runtime-evolution and plugin discussion at 28:00), and for wash CLI users who want a smoother developer experience from the new shell completions (53:01).

Up Next​

The next community calls will track this runtime evolution as the component-to-component work moves out of wash and into the wasmCloud runtime crate, the minimal host API and plugin traits stabilize, and the team continues whittling down the Q3 roadmap — including the still-in-triage items of intentional distributed networking and simplifying interface maintenance. Watch for the next-generation wash CLI to keep closing in on 1.0.

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 →