Skip to main content
← Back

WebAssembly on Kubernetes: v2 Helm Operator, wash HTTP & WASI P3

The November 19, 2025 wasmCloud community call is a deep dive into running WebAssembly on Kubernetes with the new wasmCloud v2 runtime. Eric Gregory demos a fresh end-to-end install of the v2.0 release-candidate Kubernetes operator using Helm and kind, then Lucas Fontes walks through a major rework of HTTP in the wash runtime that pulls HTTP, gRPC, and HTTP/2 handling close to the runtime instead of routing it over the network. Bailey Hayes closes with the road to WASI P3 — why P3 components will align on Wasmtime 40 in December — and the group untangles how wasmCloud actually relates to Kubernetes, wRPC, and the schedulers that place workloads.

Key Takeaways​

  • The v2 Kubernetes operator install is now documented end-to-end — Eric demoed standing up a local cluster with kind, installing the operator from an OCI Helm chart, deploying a Hello World Wasm component via a workload manifest, and curling it back, all in three or four commands
  • wasmCloud uses the Kubernetes API as a scheduler, not a requirement — the operator leans on the Kubernetes API server to store and reconcile workload state, but wasmCloud also runs on a bare k3s API server at the edge, or on a fully custom scheduler built from the published protobuf and Go code
  • HTTP moved into the wash runtime — the v1 wRPC HTTP provider added an extra NATS network hop per call; v2 binds HTTP directly to the Wasmtime context, eliminating the hop and supporting HTTP/1, HTTP/2, and gRPC without forcing users to write custom WASI plugins
  • Two integration points for HTTP — implement a lightweight router if you only need to allow/deny and direct requests (great for plugging into an external gateway or XDS), or a full host handler if you want to own the entire HTTP transport, TLS included; outbound HTTP is deny-by-default
  • wRPC is no longer a core feature of v2 — HTTP and event-bus messaging cover the ~99% use case with transparent errors and standard libraries; wRPC remains available as a nice-to-have for typed component-to-component remoting
  • WASI P3 components will align on Wasmtime 40 — a design change discovered during implementation (driven partly by Mozilla's Firefox component-model work) makes current P3 builds incompatible with Wasmtime 38/39, so the ecosystem is targeting Wasmtime 40 in December, with a full async-components release aimed at late January
  • Upgrading P2 to P3 will be easy — wasmCloud runs whatever Wasmtime supports, so the host is transparent to P2 vs P3; the real win of P3 is ergonomic async in language bindings, not new capability (async already works in P2 via callbacks)
  • A second reference implementation is in progress — Victor Adossi continues advancing a Node.js-based reference implementation of the component model interfaces, a prerequisite for advancing P3 as a standard

Chapters​

Meeting Notes​

Demo: Installing the wasmCloud v2 Kubernetes Operator​

Eric Gregory walked through brand-new documentation for installing the v2.0 release-candidate runtime operator on Kubernetes. The docs break down the pieces that constitute the wasmCloud platform on Kubernetes — the operator and its custom resource definitions, wasmCloud hosts, and NATS with JetStream — then provide a getting-started path. In the live demo, Eric spun up a local cluster with kind (a one-liner that downloads a kind config tuned for ingress and local development), used Helm to install the operator from an OCI chart image with local values, and brought up three named host groups: public ingress (node port), private ingress (cluster IP for intra-cluster traffic), and a default host group. He then applied a workload deployment manifest for a Hello World image over the HTTP interface and curled localhost to get back Hello from wasmCloud — a complete end-to-end loop in three or four commands. Bailey Hayes noted the docs were already on RC3 (mostly small patch fixes plus new WebGPU support shown by Mindy and Colin at WasmCon) and suggested the docs reference a rolling "RC latest" rather than a pinned version.

The New HTTP Implementation in the wash Runtime​

Lucas Fontes explained why HTTP moved into the wash runtime that powers wasmCloud v2. In v1, exposing anything over HTTP meant standing up a wRPC HTTP provider that held the routing logic and proxied every WebAssembly call over NATS — an extra network hop per request that capped performance. The v2 design choice was to bring HTTP as close to the runtime as possible. An early attempt to ship HTTP as an ordinary wash plugin ran aground on a heavy dependency on the Wasmtime wasi-http crate, which funneled all calls through a single interface when the team needed to fan out to both an HTTP plane and a gRPC plane (surfaced by Aditya's HTTP client / gRPC client work). The resolution: keep building on Wasmtime's wasi-http and tightly couple HTTP to the Wasmtime context so it is always present in the runtime but can be enabled or disabled per use case.

Routers vs. Host Handlers: Two Ways to Integrate HTTP​

Lucas walked the wash runtime README to show the two integration traits. A router is for when you only care about allowing or denying and directing requests — you implement callbacks for when a workload is resolved or unbound, plus callbacks to allow outgoing requests and to map an incoming request to a workload ID (the shipped dynamic router keeps a host-to-workload hash map for clustered environments; the wash dev router always targets the last workload). A host handler is for when you want to own the whole HTTP transport — binding sockets, bringing up the server, and handling TLS — and ships in two flavors: a no-op server that blocks everything, and a canonical implementation matching what the old plugin did. Crucially, you pass exactly one HTTP handler for the entire runtime, and if you pass none, all outbound HTTP is blocked by default. Because gRPC detection now lives at a known point in this implementation, gRPC becomes a per-component configuration flag rather than a specialized plugin.

Where wRPC Fits, and the Performance Trade-Off​

Responding to ossfellow, Bailey and Lucas were direct: wRPC is no longer a core feature of v2. Bailey framed each host as "its own world" and argued that hosts communicating in a ring leads to the kind of distributed-systems "magic" that caused trouble in the CORBA era. For the ~99% use case, components talk over HTTP or event-bus messaging — wasmCloud messaging supplies publish/subscribe, request/response, and handlers — giving transparent errors and standard-library ergonomics. wRPC remains available for typed, with-style remoting when you explicitly want it, but Lucas detailed the cost: wRPC buffers every lift/lower operation and ships it over the network, which is the difference between roughly 5,000 and 30,000 requests per second for some protocols. So v2 trades wRPC's automatic linking and component wiring for performance, and wRPC is "demoted" to opt-in rather than the default transport.

Wasmtime, WASI P3, and the Road to Wasmtime 40​

Picking up an HTTP/2 question from Frank Schaffa, Bailey explained that wasi-http is intentionally protocol-agnostic and virtualizable across HTTP/1, /2, and /3 — a patch already allows the gRPC te trailer header to pass through — and the remaining HTTP/2 work is server configuration, not standards work. He then previewed WASI P3: Mozilla's Firefox team (Ryan Hunt) showed off using the component model for the browser at a W3C meeting, and the browser's scoping requirements surfaced a design change in P3 implementation. As a result, P3 components built off main today are incompatible with Wasmtime 38 and 39, so the ecosystem will align on Wasmtime 40, expected in December (Wasmtime ships monthly). Roman's upgrade to Wasmtime 38 had just landed for both v1 and v2; Bailey planned a v1 patch that week and the next v2 release candidate.

Upgrading P2 to P3, and a Second Reference Implementation​

Bailey emphasized that you can build on wasmCloud v2 today with WASI P2 components and upgrade to P3 later via an adapter technique, similar to the P1-to-P2 path. The real benefit of P3 is ergonomic async in guest language bindings — async already works in P2 via the callback technique built into wasi:io, but P3 exposes primitives that language bindings can bind to directly, so guest code reads much more naturally. wasmCloud itself is agnostic to P2 vs P3 (it runs whatever Wasmtime is configured for), so the plan is to build Wasmtime 40 into wash once it ships, gate P3 behind a flag until the standardization vote, and target a full async-components release around late January. Victor Adossi continues work on a second reference implementation — getting the component-model interfaces working in a Node.js environment — which is a gating requirement for advancing P3 as a standard.

How wasmCloud Relates to Kubernetes​

Closing a long-running question, Lucas laid out the wasmCloud-and-Kubernetes relationship. Kubernetes is used as a ready-made scheduler and state store via its API server — not because Kubernetes is mandatory, but because it is the incumbent the project chose to align on. That unlocks three deployment shapes: run anywhere Kubernetes runs (EKS, AKS, GKE); point the operator and hosts at a bare k3s API server (just the API server) to manage a fleet of edge hosts over NATS from one kubectl; or skip Kubernetes entirely and build a custom scheduler on the published protobuf and the Go code inside the runtime operator, storing workload definitions in Redis, static files, or anything else. Lucas framed the next wave as mini schedulers tied to existing platforms, plus a future wash serve command for build-pack environments like Heroku. Bailey reframed the "scheduler" as more of a reconciler — declaring desired state and telling hosts to converge on it — a substantial simplification versus v1. The agenda also flagged a wash#156 v2 HTTP pull request and a forthcoming v1 patch.

WebAssembly News and Updates​

This call captures the WebAssembly ecosystem coordinating around a single release train. The headline news is WASI Preview 3: a design change uncovered during implementation — and informed by Mozilla's Firefox component-model work shown at the W3C — means P3 components will align on Wasmtime 40 in December rather than the current 38/39 releases, with a second reference implementation in a Node.js environment advancing the standard in parallel. On the runtime side, WebGPU support (demoed at WasmCon) landed in the v2 release candidates, and the wasi-http spec gained a patch to pass the gRPC te trailer header — a small but real step toward transparent HTTP/2 and gRPC. 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, the v2 runtime can be scheduled by the Kubernetes API server, a bare k3s API server at the edge, or a fully custom scheduler built on its published protobuf interfaces. With built-in OpenTelemetry observability and Kubernetes integration, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure.

Topic Deep Dive: WebAssembly on Kubernetes​

The throughline of this meeting is what it actually means to run WebAssembly on Kubernetes with wasmCloud v2. Rather than scheduling Wasm by mapping every component to a pod with its own IP address — the cardinality explosion that makes naive Wasm-on-Kubernetes painful — wasmCloud uses the Kubernetes API server purely as a scheduler and reconciliation store. The operator stores desired workload state, and wasmCloud hosts (talking NATS) converge on it. That design is what lets the same model stretch from a managed cloud cluster down to a single k3s API server driving edge hosts, or out to an entirely non-Kubernetes scheduler reading from Redis or flat files. The HTTP rework reinforces the same philosophy: by binding HTTP to the Wasmtime context and exposing a router trait, wasmCloud can plug directly into a Kubernetes gateway or XDS control plane instead of standing up its own networking. The bet is that WebAssembly on Kubernetes succeeds not by reinventing the scheduler, but by treating Kubernetes as one reconciler among many over a portable component model workload.

Who Should Watch This​

This call is especially valuable for platform and Kubernetes engineers evaluating how wasmCloud v2 installs and schedules on a cluster (start with Eric's Helm/kind demo at 5:34 and the Kubernetes-relationship discussion at 51:11), runtime and networking developers who want to understand the new HTTP/gRPC integration points in the wash runtime (Lucas's router-vs-host-handler walkthrough at 17:31), and component authors tracking when WASI P3 and ergonomic async land (Bailey's Wasmtime 40 update at 39:23).

Up Next​

The next community calls follow the v2 release train toward general availability: expect another v2 release candidate to stabilize the new HTTP runtime, a v1 patch and the Wasmtime 38-to-39 upgrade landing first, then Wasmtime 40 in December enabling WASI P3 alignment, with the full async-components release targeted for late January. Bailey also teased a C++ demo for an upcoming call.

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 →