Skip to main content
← Back

wasmCloud v2 on Kubernetes: Runtime Operator, wash host & WASI P3

The November 5, 2025 wasmCloud community call is centered on WebAssembly on Kubernetes. Lucas Fontes demos the next generation of wasmCloud — wasmCloud v2 — bringing up a Kubernetes cluster, installing the runtime operator and a new wasmCloud host over NATS via Helm, and scheduling a workload onto one of three host groups using nothing but kubectl get host. The new wash host command turns the single wash binary into a cluster host, with all scheduling intelligence moved into the operator so you can bring your own scheduler — or even your own host. Bailey Hayes frames the road to v2.0.0-rc1, and Victor Adossi closes with an update on JCO standing up as a second reference implementation for WASI Preview 3.

Key Takeaways​

  • wasmCloud v2 runs natively on Kubernetes: a runtime operator watches CRDs and schedules individual workloads onto host groups, communicating with hosts over NATS — so kubectl get host works just like kubectl get node
  • Three host groups ship by default — default (no HTTP ingress), private-ingress (internal HTTP only), and public-ingress (external HTTP) — letting you compose CDN-style, internal-service, and background-job deployment patterns from one Helm chart
  • The new wash host command makes the single wash binary act as a cluster host; because scheduling moved into the operator, the host's own settings are minimal and you can bring your own scheduler by speaking the operator's protobuf API in Go, Rust, Python, or any language
  • Host plugins replace capability providers: WASI interfaces like wasi:http, blobstore, config, logging, and wasmCloud messaging are implemented as native Rust plugins inside the host, with no extra networking hop and direct access to Wasmtime
  • A new service concept gives a workload a place to run long-lived code — connection pools, supervisors, cron-style triggers — acting as a per-workload supervisor and health check for its components
  • Autoscaling of hosts is handled at the Kubernetes layer with Horizontal Pod Autoscalers pointed at host-group deployments; component-level autoscaling is still to come
  • wasmCloud v2.0.0-rc1 is days away — the wash runtime crate and the runtime operator now live in the wasmCloud repo, with a new architecture blog post detailing the design
  • JCO is adding async support for the WASI Preview 3 component model, providing a crucial second reference implementation needed to ratify the P3 standard in the WASI subgroup

Chapters​

Meeting Notes​

Demo: The wasmCloud v2 Next Host on a Kubernetes Runtime Operator​

Lucas Fontes demoed the next version of wasmCloud — now labeled v2.0.0-rc1 — end to end, starting from an empty Kubernetes cluster. A make kind step spun up a local cluster, and a make helm install brought up the wasmcloud-system namespace containing NATS (the message bus), the runtime operator (which reads CRDs and schedules workloads), and three host-group deployments. By default wasmCloud v2 uses Kubernetes for orchestration: running kubectl get host returns wasmCloud hosts the same way kubectl get node returns nodes, and each host reports its architecture, CPU, version, and labels for host selectors.

To deploy code, Lucas applied a simple workload manifest targeting the public-ingress host group with one replica. Critically, the manifest must explicitly declare which host interfaces the workload may use — by default a component gets none of the host's capabilities and must be granted, for example, wasi:http/incoming-handler. With the workload placed, a plain curl localhost reached the running component.

Host Groups, Helm, and Multi-Tenancy​

wasmCloud v2 ships three host groups out of the box, each backed by its own Kubernetes deployment and service: default (no HTTP ingress, for background jobs that subscribe to message buses or make outbound calls), private-ingress (HTTP for internal-only requests), and public-ingress (HTTP for external requests, e.g. a CDN-style use case). Scaling a host group is as simple as increasing the deployment's replica count — it behaves like a Kubernetes node selector. The same Helm chart that runs locally (via a values.local.yaml mapping node ports) deploys to a remote cluster, where the ingress services become load balancers. Workloads land on host groups via selectors, enabling multi-tenant isolation. On autoscaling, Lucas explained that host autoscaling is achieved by pointing a Horizontal Pod Autoscaler at a host-group deployment; component-level autoscaling has not yet been tackled. Frank Schaffa flagged that the namespace field on host interfaces (a WIT namespace) is confusing next to the Kubernetes namespace, which Lucas agreed is easy to rename.

wash host, Bring-Your-Own-Scheduler, and Host Plugins​

The host in the demo was the standard wash binary running the new wash host subcommand — alongside wash dev and wash build — which makes that binary act as a cluster host. Because all scheduling intelligence moved into the operator, the host's own settings are minimal; it never acts on its own without a scheduler. The operator talks to hosts over NATS using protobuf messages (heartbeats, workload start/stop/status) encoded as JSON, with ready-to-go clients for Go, Rust, and Python — so you can write your own scheduler in any language by reusing those protobufs. The runtime itself is composed of built-in host plugins (config, logging, blobstore, and wasmCloud messaging), each with an ephemeral local-dev variant and a production NATS-backed counterpart. These host plugins replace capability providers: implementing a WASI interface is "exactly the same" as implementing one on Wasmtime with the component macro, plus one extra trait — and gives direct access to Wasmtime, with Mindy's wasi-webgpu PR landing soon as another example.

The Service Concept and Health Checks​

Lucas introduced the new service abstraction. Because WebAssembly is invocation-based with no globals surviving across requests, a service gives a workload a place to run long-running code — an infinite loop, open sockets (inbound and outbound), and communication with sibling components in the same workload. A service can act as a connection-pool aggregator (e.g. a per-workload PgBouncer funneling 1,000 component connections into one database connection) or as a cron-style trigger. When present, the service becomes the supervisor and health check for the whole workload: the runtime checks that the WebAssembly sandbox is still active, and if the service crashes, the workload is restarted (configurable, e.g. max three restarts) or rescheduled to another host. Each workload gets a unique network identity — its own hostname and IP — making the workload a unit of tenancy.

WebAssembly News and Updates​

The headline from this call is WebAssembly running natively on Kubernetes at production scale: wasmCloud v2 reaches v2.0.0-rc1, packaging the wash runtime crate and the runtime operator into the main repo and replacing capability providers with native host plugins. A new architecture blog post by Brooks and Eric details the design. On the standards side, JCO is adding async support for WASI Preview 3, which brings futures, streams, and async component-to-component calls to the component model — and serves as the second reference implementation required to hold a ratification vote in the WASI subgroup. CFPs are open for wasmCon EU and Wasm.io, and wasmCloud heads to KubeCon + CloudNativeCon NA in Atlanta the following week.

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 architecture. wasmCloud's reference host is built on Wasmtime, and as this call shows, the v2 runtime operator schedules WebAssembly workloads onto Kubernetes the same way Kubernetes schedules pods — kubectl get host alongside kubectl get node. With built-in OpenTelemetry observability and first-class 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 WebAssembly on Kubernetes done the native way. Rather than wrapping Wasm in containers, wasmCloud v2 introduces a Kubernetes runtime operator that treats hosts as first-class cluster objects: you kubectl get host, you label hosts, you select host groups, and you scale them with the same Horizontal Pod Autoscalers you already use for pods. Workloads are scheduled by the operator over NATS using a documented protobuf API, which means the scheduler is replaceable and so is the host — anything that speaks the protocol can join a host group. Capability providers give way to host plugins, native Rust implementations of WASI interfaces (wasi:http, blobstore, config, logging) that run in-process with no extra hop. The new service primitive solves WebAssembly's statelessness by giving each workload a supervised place for connection pooling and long-lived resources. The result is a model where Wasm components inherit Kubernetes' networking, ingress, multi-tenancy, and autoscaling — while keeping deny-by-default sandboxing at the component model boundary. The fastest way to try it is the Kubernetes operator docs and the v2.0.0-rc1 release candidate.

Who Should Watch This​

This call is especially valuable for platform engineers and Kubernetes operators evaluating how to run WebAssembly workloads natively on Kubernetes (follow Lucas's full v2 demo from 4:59), infrastructure developers who want to bring their own scheduler or host by speaking the operator's protobuf API (the wash host walkthrough at 13:42), and JavaScript and component-model developers tracking the road to WASI Preview 3 and a second reference implementation in JCO (Victor's update at 55:23).

Up Next​

The next community calls follow the road to wasmCloud v2.0.0: watch for the release candidate tag landing in the wasmCloud repo, new docs and examples for the runtime operator and host groups, and a tutorial on building your own host plugin and custom wash host. Expect a lighter call the following week as the team heads to KubeCon NA in Atlanta, and a fast follow that brings the latest Wasmtime and WASI Preview 3 support into a v2.x release before year's end. The Kubernetes CRDs used by the release candidate are documented in the v2.0.0-rc version of the docs.

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 →