Skip to main content
← Back

C++ Wasm Components, gRPC & the Wasm Component Model in wasmCloud v2

The November 26, 2025 wasmCloud community call is a hands-on tour of the Wasm component model maturing across the C/C++ toolchain and into wasmCloud v2. Bailey Hayes demos a Bytecode Alliance example that builds a 67 KB WebAssembly HTTP server using modern, ergonomic C++ bindings on wasi:http, walks through how cooperative threads and exception handling are landing in wasi-libc, and shows protobuf compiling out of the box. The call closes with how gRPC rides over a protocol-agnostic wasi:http, plus a deep discussion of how workload identity works in wasmCloud v2 on Kubernetes — replacing v1's identity delegation with a unique workload ID assigned at scheduling time.

Key Takeaways​

  • Modern C++ is now a first-class WebAssembly component language: as of wit-bindgen 48.1, C++ support is feature-complete for WASI Preview 2, with ergonomic C++ bindings (not just C-style) for wasi:http — Bailey's example compiled to a 67 KB Wasm server
  • The C/C++ toolchain is converging on the component model: a C++20 baseline brings coroutines that line up with the component model's upcoming cooperative threads, while threading and exception handling are landing in Wasmtime and wasi-libc — together they should let "most C++ projects just build"
  • protobuf compiles out of the box now that abseil builds cleanly against wasi-libc, producing native WASI P1 and P2 binaries that serialize and deserialize protobuf without custom build hacks
  • gRPC is decoupled from protobuf and rides over wasi:http: because wasi:http is intentionally protocol-agnostic, passing the right headers (HTTP/2 streaming, the TE header) lets the host's HTTP server implementation negotiate gRPC — the gRPC logic lives in the runtime, not the guest
  • Aditya added gRPC client support to wasmCloud by overriding Tonic's default service to call the wasi:http outgoing handler with an application/grpc header; full gRPC support is targeted before the end of the year
  • Eric's new wasmCloud v2 docs overview covers new types, how plugins, interfaces, and transports work, OCI packaging with wash, and — by popular request — a v1-to-v2 migration guide
  • wasmCloud v2 treats workload identity as an external concern handled by your service mesh; wasmCloud stays agnostic, integrating identity into the scheduling operation rather than baking it into the host
  • Every component now gets a unique workload ID keyed on namespace plus workload name, eliminating v1's identity-takeover problem and enabling RBAC-style ACLs at the scheduling layer

Chapters​

Meeting Notes​

Doc of the Week: The wasmCloud v2 Overview and Migration Guide​

Bailey opened the (deliberately lightweight, pre-Thanksgiving) call with the Doc of the Week — a new wasmCloud v2 overview section written by Eric Gregory, still in pull request form for community feedback. The overview introduces the new v2 types, the goals of v2, how plugins work, what the interfaces and transports are, and how to use wash to publish OCI packages. Most notably, it includes a v1-to-v2 migration guide — a frequent request from the previous community call. Bailey noted the team is currently on RC2 and about to cut RC3, and that v2 docs will live as a single "next" version rather than a separate .x branch.

Demo: Modern C++ Bindings for wasi:http​

Bailey then demoed a Bytecode Alliance example for building with wasi:http using modern C++ bindings — not just C-style, but ergonomic C++ that leans on auto, streams, and clean exports. The server.cpp defines a top-level handle method that parses a query and writes a response; make release produced a 67 KB Wasm binary, and make serve ran it locally (returning a hello world and echoing input). The key point: full C++ support is only available starting in the 48.1 release of wit-bindgen. Building on Christophe Pettit's foundation, Bailey expanded C++ support to cover the previously unhandled WIT use cases, making WASI Preview 2 feature-complete for C++ — the only remaining gap is WASI P3, for which Bailey has a design sketch underway with Pettit and Cy Brand.

wasi-libc, Cooperative Threads, and the C/C++ Toolchain​

Bailey traced how the broader C/C++ story is converging on the Wasm component model. The team standardized on a C++20 baseline — beautiful modern C++ whose coroutines align neatly with the component model's forthcoming cooperative threads, a lightweight green-threading model (think goroutine-style concurrency) layered on top of real threading. He contrasted the WASI SDK path with Emscripten (web-focused, with JavaScript glue, P-thread emulation via web workers, and an in-memory filesystem), and explained that wasi-libc — now bundled in the WASI SDK — is the foundation growing to support these features. The three big items about to land: threading (perhaps a month and a half out), cooperative threads, and exception handling (already in Wasmtime, with producer-toolchain support coming to wasi-libc for C++ exceptions and setjmp/longjmp).

Compiling protobuf, and gRPC over a Protocol-Agnostic wasi:http​

After getting abseil (modern-boost-style C++ libraries) building out of the box, Bailey was able to compile protobuf fully for both WASI P1 and P2 — serializing and deserializing types with no custom build hacks. He was careful to decouple gRPC from protobuf: protobuf handles the wire types via protoc-generated stubs, while gRPC is a separate networking protocol. The crucial design insight is that wasi:http is intentionally protocol-agnostic — by passing the right headers (HTTP/2 streaming, the TE header), the host's HTTP server implementation can negotiate gRPC, so the gRPC machinery lives in the runtime rather than the guest. Aditya then described his complementary work: gRPC client support in wasmCloud, achieved by overriding Tonic's default service with a tower service that calls the wasi:http outgoing handler and adds the application/grpc header. Bailey expects robust gRPC support landed in wasmCloud before the end of the year, crediting Aditya and Lucas Fontes.

Workload Identity, Scheduling, and the Unique Workload ID in v2​

The call closed with a question from ossfellow about how workload identity works in wasmCloud v2 now that Kubernetes is the default scheduler. Bailey framed identity as an external feature handled by your service mesh — wasmCloud stays agnostic rather than building an isolated NATS-based island like the v1 POC, which had been incompatible with mTLS and service meshes teams already ran. Lucas Fontes explained the v2 model: every workload is keyed on namespace plus name and carries a unique workload ID, so identity becomes part of the scheduling operation — the scheduler primes the target hosts before sending the workload, and identity is assigned to components, not the host. Frank Schaffa pressed on RBAC and identity takeover; Lucas explained that v1's host-delegated identity allowed a same-named component to take over another's identity, whereas v2's unique ID per component (resolved at the ingress/proxy layer, e.g. SPIFFE/SPIRE) prevents that and enables Kubernetes-RBAC-style ACLs at the scheduling layer. Frank suggested calling it a unique identifier rather than "identity" to avoid the loaded term — and Bailey agreed.

WebAssembly News and Updates​

This call captures the C and C++ corner of the WebAssembly ecosystem racing toward full component model support. The WASI SDK and wasi-libc are growing fast to support cooperative threads, real threading, and exception handling — with wit-bindgen 48.1 making modern C++ a feature-complete WASI Preview 2 language — another step in the toolchain story that arrived alongside wasmCloud v2. Bailey also flagged a large documentation migration in the WebAssembly WASI repo: WASI Preview 3 proposals (including the wasi-sockets P3 draft used as a reference for wasi-tls) now live there. On the toolchain side, abseil and protobuf now build cleanly against wasi-libc, clearing a long-standing pain point for anyone targeting WebAssembly from C++. 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 — as this call shows — modern 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 v2 leans into a Kubernetes-native scheduling model where each workload carries a namespace and a unique workload ID. 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 C++ demo matters precisely because the component model gives modern C++ ergonomic, typed bindings on wasi:http — letting a 67 KB Wasm server interoperate with any other component through standard interfaces. The cooperative threads work is a component-model feature: it defines how a component exposes a lightweight async boundary to callers while using real threads internally, so a component can call out and have callers call back in. gRPC over wasi:http is the same story at the protocol layer — the component model keeps the guest code protocol-agnostic, pushing the gRPC negotiation into the host. And in wasmCloud v2, the workload — the unit the scheduler primes, assigns identity to, and applies RBAC against — is fundamentally a component (or a composed world of components) defined by its WIT interfaces. As the C/C++ toolchain, wasi-libc, and abseil/protobuf all reach component-model maturity, the promise of "write business logic in any language, compose it through typed interfaces, and schedule it anywhere" moves closer to reality.

Who Should Watch This​

This call is especially valuable for C and C++ engineers evaluating WebAssembly as a compilation target — start with the modern-C++ wasi:http demo and the wasi-libc/cooperative-threads walkthrough from 9:00; API and networking developers who want to run gRPC and protobuf workloads on WebAssembly (the wasi:http decoupling discussion at 18:18); and platform engineers and Kubernetes operators thinking through workload identity, scheduling, and RBAC in wasmCloud v2 (the workload-identity discussion at 25:01).

Up Next​

Watch for gRPC support landing in wasmCloud before the end of the year, the wasmCloud v2 docs (including the v1-to-v2 migration guide) being merged after the holiday, cooperative threads and exception handling arriving in the C/C++ toolchain, and continued work on the wasi-tls interface toward a WASI P3 version.

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 →