Skip to main content
← Back

wasmCloud Runtime Crate: Embedding Wasmtime & the Component Model

The October 15, 2025 wasmCloud community call dives into the Wasm component model through a new wasmCloud runtime crate. Brooks Townsend walks through the crate — an opinionated embedding of Wasmtime that auto-links components via workload resolution, adds host plugins for WASI and custom interfaces, and exposes a much-simplified host API. The conversation widens into how component instances are managed across requests, how that shapes WIT design, and the community's push toward common agentic protocols like MCP and ACP.

Key Takeaways​

  • The new wasmCloud runtime crate is an opinionated embedding of Wasmtime — a thin set of wrapper types for running components in the cloud or on Kubernetes, with an embedding API that needs no network requests (unlike the NATS-driven wasmCloud host)
  • Workload resolution auto-links components: an import of one component is wired to the export of another in the same workload, delivering wasmCloud's runtime-linking feature without composing components together ahead of time
  • Host plugins are a Rust-based replacement for built-in capability providers — implement the generated Wasmtime bindings for a WIT interface (the wasi:logging example was shown) and register it; WASI HTTP, CLI, config, and logging come for free
  • A host struct plus a simplified host API (heartbeat, start/stop/status workload) is essentially all you need to run your own host; a workload consolidates components, config, links, and volumes into one declarative unit
  • Building the crate effectively means building your own host — pluggable, async-first, and component-first; wasmCloud's next-generation operator embeds it while the crate stays a generic layer below wasmCloud
  • wasmCloud instantiates a fresh component per request for isolation and zero cold start, but that's a design choice, not a component model limit — a configurable pool size and (with WASI Preview 3 async/streams) instance reuse are on the way
  • Instance lifecycle shapes WIT design: a request-scoped component can keep singleton state, while a reused one should export resources instead — a point newcomer Ian raised from building the wasmcp project
  • The community is converging on common protocols for agentic AI — a new #MCP Slack channel, Yordis's work on the Agent Client Protocol (ACP) and a native map type for WIT/wasm-tools, and the bet that a component-native framework could be the best way to run MCP servers

Chapters​

Meeting Notes​

A New Runtime Crate: An Opinionated Embedding of Wasmtime​

The main agenda item was a walkthrough of the new wasmCloud runtime crate that Brooks Townsend has been factoring out of wash. He framed it as effectively an opinionated embedding of Wasmtime — a small set of wrapper types for running components in the cloud or on Kubernetes, plus the facilities the current wasmCloud host crate lacks. Where the wasmCloud host depends on NATS for its control interface, the crate's embedding API uses no network requests at all: you build an engine (a direct wrapper around a Wasmtime engine), register plugins, build and start a host, then start a workload — a named, namespaced collection of components that run together as one bundle, analogous to a wadm application. The crate is ideal for the wash dev use case, where everything should run offline with no orchestration processes.

Workload Resolution and Runtime Linking​

Brooks spent time on the workload module, which holds the unresolved and resolved workload structs. The interesting work happens in resolution: components in the same workload can satisfy each other's imports and exports, so an import of one component is automatically linked to the export of another. His example was using a plugin to implement wasi:blobstore — the plugin exports the blob-store interfaces and imports wasi:filesystem (available to all components), letting components in the same workload call each other directly. This is wasmCloud's runtime-linking feature without having to wac-compose components ahead of time. Unlike today's application structure, where ten interlinked components require you to declare every link, workload resolution connects an import to a matching export automatically. All components are bound to WASI 0.2 interfaces, with the wasi:http and wasi:cli worlds available for free.

Host Plugins and the Simplified Host API​

The primary thing you embed is the host struct — responsible for managing the engine, carrying a friendly name and labels for orchestration and scheduling, much like today's host but vastly simpler. What used to be the sprawling control interface is now just a host API: get a heartbeat, and start, stop, or get the status of a workload. The big change is that a workload now carries all its config, links, components, and volumes in one place, replacing a stream of imperative "start this component, start this provider, create this link" commands.

For extension, the crate introduces host plugins, a wholesale replacement for wasmCloud's built-in capability providers. They are written in Rust (no wRPC layer yet), and Brooks walked through the wasi:logging implementation as an easy example: you generate component bindings with Wasmtime against your own custom world, implement the bindings Host trait for the wasmCloud context struct, and register which interfaces and versions you implement. wasmCloud turns on wasi:config, wasi:http, and wasi:logging for free; anything else is a host plugin or is satisfied by another component in the workload. Brooks noted built-ins were painful in the current host — adding one meant touching three crates — whereas a singleton host plugin is far easier to extend when you run the host yourself.

wasmCloud vs. the Crate, and the Component-Instance Question​

Bailey Hayes asked for the "explain it like I'm five" version: why not just use wasmCloud? Brooks and Bailey explained that the crate is the level below wasmCloud — a general-purpose, async-enabled, component-first embedding that owns the async runtime and can run multiple workloads with plugins, which straight Wasmtime makes hard (dynamically linking one component's export to another's import requires real lifting and lowering of values across a shared store). wasmCloud's next-generation operator embeds this host; the crate itself, the wash runtime, stays generic. Newcomer Ian then asked why wasmCloud doesn't reuse component instances across requests. Brooks explained that wasmCloud pre-instantiates a component and then spins up a fresh instance per request for isolation and near-zero cold start — but stressed this is a design choice, not a component model limitation. The crate will expose a configurable pool size to keep instances ready, and Victor Adossi added that reuse is possible today (just not recommended), and will become more common with WASI Preview 3's async, streams, futures, and eventual threads. Ian closed the technical thread by observing that this assumption fundamentally shapes WIT design — a request-scoped component can hold singleton state, while a reused one should export resources instead.

WebAssembly News and Updates​

This call is a snapshot of the WebAssembly ecosystem maturing its embedding and composition story. The new wasmCloud runtime crate builds directly on Wasmtime and the Wasm component model, turning runtime linking and host extension into a clean library API. On the standards side, the discussion touched on the churn in draft WASI interfaces (the wasi:config/wasi:runtime-config naming confusion), the road to WASI Preview 3 with native async and streams, and Yordis Prieto's work to add a native map type to WIT and wasm-tools. The AI thread highlighted the Model Context Protocol (MCP) and the Agent Client Protocol (ACP) — newer JSON-RPC-based standards that the community sees as a natural fit for WebAssembly components. 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 as this call shows, that embedding is being refactored into a reusable runtime crate that auto-links components, exposes host plugins, and offers a simple host API for anyone who wants to run their own host. 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. The runtime crate's headline feature — workload resolution — is component-model machinery: it wires a component's typed import to another component's matching export, lifting and lowering values across a shared store so two independently authored components interoperate without trusting each other's internals. Host plugins are the same idea from the host side: a Rust implementation of a WIT interface that components bind to, all governed by the component model's typed contracts. The instance-lifecycle discussion is component-model-shaped too — because components are sandboxed, single-threaded instances, whether you reuse them across requests determines how you design your WIT (singleton state vs. exported resources), and WASI Preview 3's async and streams will change those tradeoffs again. Even the AI thread lands here: Ian observed that an MCP server is "a bag of capabilities, just like a component is," making a component-native framework a natural way to compose tools. As the component model becomes the universal contract across hosts, languages, and the wasmCloud operator that schedules them, libraries like this runtime crate are what make it practical to use.

Who Should Watch This​

This call is especially valuable for Rust developers and platform engineers evaluating how to embed WebAssembly in their own host or runtime (start with Brooks's runtime-crate walkthrough at 8:21), component authors weighing how instance lifecycle should shape their WIT and interface design (the reuse discussion at 33:41), and AI/agent developers building MCP servers who want to understand why WebAssembly components and the Model Context Protocol fit together (the MCP and ACP discussion at 47:31).

Up Next​

The next community calls follow the runtime crate toward publication on crates.io and pick up Ian's promised wasmcp demo running on wasmCloud. Watch for the configurable instance pool, the road to WASI Preview 3 support, Yordis's native map type landing in WIT and wasm-tools, and continued discussion in the new #MCP Slack channel.

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 →