Skip to main content
← Back

wasmCloud v2 Services, the Wasm Component Model & WASI P3

The December 3, 2025 wasmCloud community call digs into how the Wasm component model shapes wasmCloud v2, where a workload is composed of stateless components plus a new stateful primitive called a service. Lucas Fontes demos a service that opens TCP sockets and acts as localhost for the components in a workload — ideal for connection pooling, proxying, and persistent state — and the team explains how it leans on cooperative threads coming in WASI P3. The call also covers the move of WASI to a monorepo, the rename of the wasmCloud operator to the wadm operator, the C++ challenges behind compiling protobuf to WebAssembly, and the progress of the wasi-tls proposal.

Key Takeaways​

  • Services are wasmCloud v2's stateful primitive — where components are stateless and invocation-based, a service runs for the full lifetime of a workload, can listen on TCP sockets, and behaves like localhost for the components alongside it
  • Connection pooling is the headline use case — a service can hold persistent connections (for example, a PgBouncer in front of MySQL) so individual component invocations never open their own database sockets
  • Socket isolation is virtual, not OS-level — when a component connects to 127.0.0.1, wasmCloud intercepts the WASI call and hands back an internal file handle more like a Unix pipe than a real socket, so two workloads can both bind port 8080 with no conflict
  • Cooperative threads in WASI P3 are the bet that makes services scale far better than the old provider model, with a thread-spawn primitive landing at the component-model layer in the canonical ABI and inside Wasmtime
  • WASI moved to a monorepo at WebAssembly/WASI, enabling monotonic, automated cross-proposal releases — the change that made the clocks wall-clock-to-system-clock update stick
  • The wasmCloud operator is being renamed to the wadm operator to disambiguate it from the new v2 runtime operator and keep the door open for wadm-based scheduling in v2
  • wasi-otel reached Phase 1 in the W3C/WASI process, and wasi-tls is being pushed toward Phase 2 and possibly Preview 3, with Rust crypto now mature enough to replace many OpenSSL dependencies
  • Compiling protobuf to WebAssembly is hard because of C++ — abseil's threading and atomics are the "iceberg" under the surface; a Google-backed pure-Rust protobuf crate is in the works and would sidestep the problem

Chapters​

Meeting Notes​

wasmCloud v2 Services: a Stateful Companion to Components​

Lucas Fontes walked through how a wasmCloud v2 workload is composed. The bulk of a workload is a set of components — the WebAssembly component model units that handle things like a payment API, a blob store, or login — wired together through their imports and exports until every interface is fulfilled and the workload starts. Each component is stateless and invocation-based: it can connect out over TCP, but it has no reason to open or listen on a TCP socket because it holds no state between invocations.

Alongside the world of components, a workload can declare a service. A service is essentially the localhost of your workload: a single, long-lived component (a WASI CLI-style run component) that is started when the workload is scheduled and stays up for as long as the workload lives, restarting if it crashes. Crucially, a service can listen on TCP sockets. Components in the workload connect out to those sockets, giving the workload a stable point to hold persistent connections, do connection pooling, proxy traffic, or bridge the component world to the raw TCP world. Calls flow from the service into the components' exported interfaces (the basis for, say, the simplest possible cron implementation), but not the other way around, because the service is stateful while the components are not.

Demo: a TCP Echo Server Running as a Service​

Lucas demoed the idea with a tiny WASI CLI run component that creates a TCP listener on port 7070 and echoes back every byte it receives — an echo server compiled to WebAssembly. Running it through a development branch of wash dev (using a new wash config setting that flags a component as a service rather than an invocation-based component), he connected from his own machine and watched the socket stay alive and stateful across repeated connections, much like a basic HTTP server written in Rust or Go as a regular OS binary.

He was candid that this was a branch, not landing code: how you develop a service with wash is still being figured out, including support for developing multiple components at once. The takeaway use cases were clear — TCP-based workloads, anything needing large amounts of memory, and anything that must keep state across multiple invocations belongs in a service.

Runtime, Concurrency, and the Bet on Cooperative Threads​

Colin Murphy asked how the service runtime actually works, since these components compile to WASI P2. Lucas and Victor Adossi explained that the host wraps a single-threaded Tokio executor — wstd's runtime::spawn encapsulates the Tokio-and-hyper plumbing so guest authors don't have to. On WASI P2 you get concurrency on a single thread this way; on WASI P3, guests get a real choice and will use the native P3 primitives, at which point the wstd shim "melts away."

Bailey Hayes framed the strategic bet: cooperative threads are right around the corner. WASI P3 already exposes, at the component-model layer inside the canonical ABI, an effective thread-spawn call that is implemented in Wasmtime and on the guest side in wasm-tools, with work flowing into wasi-libc on behalf of Fastly. A service that can spawn cooperative threads gets far better isolation and scaling than the old provider model — strong evidence that services and providers are converging. The team also touched on socket isolation: when a component opens a connection to 127.0.0.1, wasmCloud intercepts the WASI call and returns an internal file handle that behaves more like a Unix pipe than an OS socket, so multiple workloads can each bind the same port with full isolation inside a single host.

Operator Rename, the WASI Monorepo, and Standards Progress​

Bailey previewed two changes he wanted to clear with the community before merging. First, a plugins registry change so that the GHCR-backed registry wash depends on can load full components, not just .wasm files containing only WIT interface definitions. Second — the bigger one — renaming the wasmCloud operator to the wadm operator. The v2 runtime operator that Lucas built makes scheduling decisions itself inside the Kubernetes API, whereas the older operator was effectively a reflector from wadm to Kubernetes. Renaming it disambiguates the chart and keeps the door open for bringing wadm forward as a v2 scheduling mechanism.

On the upstream side, Bailey reported that WASI was reorganized into a monorepo at WebAssembly/WASI, which made monotonic, automated cross-proposal releases possible and let the wall-clock-to-system-clock clocks change persist cleanly. He also shared that wasi-otel advanced to Phase 1 in the W3C/WASI process — it has a WIT definition and spec and is tracked for collaboration, with Andrew and Caleb calling for more implementers to push it toward Phase 2 and eventually Phase 3.

The C++ Iceberg: Compiling Protobuf to WebAssembly​

Colin and Bailey dug into one of the thorniest problems in expanding WASI's reach: the "C++ icebergs under the ocean." Major projects people rely on without realizing — protobuf, OpenCV, TensorFlow, ONNX Runtime, OpenSSL — are C++ at the core, and Clang's WASI P2 support balks at their threading and memory assumptions. Bailey shared his work getting protobuf building against abseil (the modern Boost-like C++ library protobuf depends on), and after maintainer feedback he pushed a cleaner version that drops many of his hand-written stubs by building both abseil and protobuf from source. The remaining friction is real: protobuf assumes threads and memory arenas that don't map well to a single-threaded, virtualized-memory Wasm world. Victor noted a pure-Rust protobuf implementation — recently taken over by Google and slated to claim the protobuf crate name — that would let wasmCloud sidestep the C++ entirely. The example stubs live in Bailey's ricochet-wasm-protobuf repo for anyone who wants to try building for P1 and P2 side by side.

WebAssembly News and Updates​

This call is a window into the WebAssembly ecosystem's steady march toward WASI Preview 3. The team is now eyeing a Q1 2026 timeframe for P3 (slipped from end of 2025), with the async "color"-like change for functions largely implemented across wasm-tools and Wasmtime. On the JavaScript side, JCO shipped incremental async fixes (around the 1.15.x line) ahead of a larger async PR. Standards-wise, the move of WASI to a monorepo streamlines releases, wasi-otel reached Phase 1, and the wasi-tls proposal is being pushed toward Phase 2. 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#, 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 in v2 a workload composes many stateless components together with optional stateful services that can hold TCP connections and state. 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​

Almost everything in this meeting traces back to the Wasm component model. A wasmCloud v2 workload is, at heart, a composition of components wired together through their typed imports and exports — the host knows how to start the workload precisely because the component model lets it match each export to an import until all interfaces are fulfilled. The new service primitive extends that model rather than breaking it: a service is itself a component (a WASI CLI run component), just one that is stateful and long-lived, and it interacts with the rest of the workload through the same exported interfaces. The component model is also what makes the cooperative-threading story tractable — the thread-spawn primitive lives at the canonical-ABI layer of the component model, so guests in any language can compile to it once WASI P3 lands. And it is why the protobuf and TLS work matters: getting C++ libraries and crypto into components, and exposing capabilities like wasi-tls and wasi-otel through typed WIT interfaces, is how the component model's "write once, run in any host" promise reaches real production workloads. As more capabilities arrive as components and services, wasmCloud's bet is that the component model becomes the universal contract across languages, hosts, and the Kubernetes-native operator that schedules them.

Who Should Watch This​

This call is especially valuable for platform engineers and architects evaluating how to model stateful workloads — connection pools, proxies, and persistent state — on WebAssembly (start with Lucas's services walkthrough at 5:32), Rust and systems developers wrestling with compiling C++ dependencies like protobuf or crypto to Wasm (Bailey and Colin's deep dive at 41:42), and WebAssembly contributors tracking the road to WASI P3, cooperative threads, and the WASI monorepo (the standards update at 37:05).

Up Next​

The team flagged a full docket for the following week, including continued work on services in wash and a hoped-for watermarking demo using WebGPU. Watch for the incoming release candidate, the wadm operator rename landing, more progress on WASI P3 and cooperative threads, and the wasi-tls proposal advancing through the standards process.

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 →