Skip to main content
← Back

WebAssembly on Kubernetes: the New wasmCloud Runtime Operator & WASI P3

The September 24, 2025 wasmCloud community call is all about running WebAssembly on Kubernetes. Lucas Fontes walks through a new Kubernetes-native runtime operator for wasmCloud v2 that stores all workload state in Kubernetes via custom resources (CRDs), aligns naming with pods, replica sets, and deployments, and replaces external capability providers with secure in-process host plugins. Bailey Hayes covers a wave of wash and setup-wash-action improvements for the next major version, and shares that Wasmtime has shipped the first WASI P3 release candidate.

Key Takeaways​

  • A new Kubernetes-native runtime operator for wasmCloud v2 no longer relies on wadm or NATS to hold state — every workload lives in Kubernetes as a CRD, so the operator is more stateless, the install footprint is smaller, and there is no separate NATS cluster to back up
  • wasmCloud's CRDs now mirror Kubernetes primitives: a Workload is a group of components on a single host (like a pod), a WorkloadReplicaSet manages replica count, and a Deployment orchestrates rolling, blue-green, and canary rollouts with zero downtime
  • Interfaces must now fully resolve inside a workload — every import is satisfied by a sibling component or a host plugin — eliminating the wadm-era foot-gun of deploying an HTTP component with no provider behind it and turning it into an outage
  • External providers are replaced by in-process host plugins written in Rust and shipped with the host, closing the security hole of the host downloading and executing arbitrary provider binaries at runtime
  • The operator adds production-grade controls: host targeting by label or host ID, exported volumes (empty-dir or host path), version locking on host interfaces, image pull secrets, warm instance pools to cut cold starts, per-component config, and allowed-hosts egress policy
  • Wasmtime cut a release with the first WASI P3 release candidate — an early host-side implementation that flips Wasmtime embeddings from sync to async — putting wasmCloud on track to consume P3 in its next host
  • wash and setup-wash-action gained next-version features including custom OCI metadata/annotations, --release flag support, single-WIT-world inference for Go, --output json for build automation, and cached plugins for reusable, language-agnostic GitHub workflows
  • The new operator is being dogfooded in production with rolling updates and GitOps via Backstage and Argo CD, and the team is actively seeking community feedback ahead of a single combined release into the wasmcloud/wasmcloud repo

Chapters​

Meeting Notes​

A Kubernetes-Native Runtime Operator for wasmCloud v2​

Lucas Fontes presented the headline item: a new runtime operator that rethinks how wasmCloud runs on Kubernetes for the upcoming v2. In v1, the wasmCloud operator was essentially a reflection layer — it shuttled data between the Kubernetes API and wadm, but did not participate in scheduling. All workload state lived in wadm and NATS, so a NATS outage meant recovering every manifest from somewhere else. The new operator stops deploying wadm and NATS entirely and stores all state directly in Kubernetes alongside the CRD definitions, making the operator more stateless, shrinking the install footprint, and removing the question of whether to run and back up a three-node NATS cluster.

A central design goal was aligning wasmCloud's concepts with Kubernetes primitives. A Workload CRD represents a group of components deployed on a single host — the analogue of a pod. A WorkloadReplicaSet manages replica count, just as a Kubernetes ReplicaSet manages pods. And a Deployment sits on top to orchestrate rolling, blue-green, and canary rollouts with zero downtime by spinning replica sets up and down in a controlled way.

Resolved Interfaces and Secure In-Process Host Plugins​

Two changes stood out as significant improvements over v1. First, every interface in a workload must now resolve — each import is satisfied either by a sibling component declared in the same workload or by the host. In the wadm era you could deploy an HTTP component with no provider backing it; the system would accept the manifest and the missing dependency would surface as a production outage. Bundling everything into a Workload makes that "Venn diagram a circle." Components in a workload are also now guaranteed to be co-located on the same host, eliminating the v1 surprise where listed components could be scattered across hosts and pay a NATS round-trip in latency.

Second, the v1 model of external providers — where the host downloaded a provider binary and executed it on the spot, an obvious security risk — is replaced by in-process host plugins written in Rust and shipped as part of the host binary. A single plugin instance is shared across all workloads, but each workload gets its own context and data-access boundary. Hosts now report their available plugins (key-value, blob store, config, HTTP) in their heartbeats, and the operator uses that to make scheduling decisions. For teams building their own capability extensions, the equivalent v2 path is documented under creating host plugins.

Production Controls: Targeting, Volumes, Pools, and Egress Policy​

Lucas demonstrated the operator's richer feature set. Workloads can target hosts by label or by a specific host ID (now a simple UID that can be stapled into the workload definition). Workloads can export volumes — either an empty directory or a host path — with each component claiming its own mount path, enabling patterns like a producer and worker sharing a directory for message passing. Version locking lets a workload pin a specific version of a host interface (for example, requiring blobstore 0.2.0 instead of accepting a newer release). The operator also adds image pull secrets using regular Kubernetes secrets, a warm instance pool to absorb bursts and cut cold starts, layered per-component configuration (secrets → config maps → literals), and an allowed-hosts policy controlling which outbound HTTP hosts a component may call. Operators can now run kubectl get hosts to see registered hosts reporting health, mirroring the experience of wash get inventory.

wash, setup-wash-action, and the WASI P3 Release Candidate​

Bailey Hayes opened with a tour of wash improvements landing for the next major version in the out-of-tree wasmcloud/wash repo, many tagged as good first issues: a convention for custom OCI metadata/annotations (version, license, source repo) that tools like GitHub Packages can surface; a --release flag; smarter single-WIT-world inference (especially valuable for Go, which lacks a top-level SDK manifest); and --output json so build steps can pass the artifact path straight to a publish step. On top of that, setup-wash-action gained cached plugins, the ability to enumerate a plugin list, OCI push with digests, and attestations — composing into reusable, language-agnostic GitHub workflows. To close, Bailey shared that Wasmtime cut a release with the first WASI P3 release candidate, an early host-side implementation (flipping embeddings from sync to async) that wasmCloud plans to consume in its next host once its own upstream interface fixes land.

A Wide-Ranging Conversation on WebAssembly, MCP, and AI​

After the formal agenda, Bailey and Justin Janes had an extended discussion about WebAssembly's role in the AI era. Bailey described building MCP (Model Context Protocol) servers as WebAssembly components — taking the off-the-shelf TypeScript MCP SDK, swapping Express for Hono (to use the WinterTC standard), and compiling to Wasm to get a tiny, scale-to-zero, fast-starting server ideal for remote-hosted, serverless tooling. She compared three approaches in the space (wassmcp-style component tools, wasm-mcp/mcp-wasm WIT transcoding, and her own "streamable HTTP all the way down" approach) and argued agents make far more sense as Wasm components than containers. Justin shared his work with small, task-specific local models — including Liquid AI's compact models and techniques like mixture-of-experts routing and Google's "sled" — arguing that we rarely need the largest models and should focus on efficient model selection. Both agreed WebAssembly still has a strong future, especially close to the Bytecode Alliance.

WebAssembly News and Updates​

The biggest ecosystem headline from this call is that Wasmtime shipped a release containing the first WASI P3 release candidate — the first time WASI Preview 3 has been implemented in a production WebAssembly runtime. It is an early, host-focused milestone (with interfaces still being revised and a notable shift from sync to async in Wasmtime embeddings), and language toolchain support is still catching up, but it confirms WASI P3's async, streams, and futures are landing in runtimes "near you." wasmCloud, whose maintainers contributed many of the upstream interface fixes, plans to integrate a stabilized P3 into its next host. On the tooling side, wash is converging on a polyglot, zero-config build experience built on wasm-tools (the same crate used by Wasmtime and most language producer toolchains), and setup-wash-action is maturing into reusable CI building blocks. For broader 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 next version pairs that host with a Kubernetes-native runtime operator that schedules workloads through custom resources. With built-in OpenTelemetry observability and deep Kubernetes integration, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure.

Topic Deep Dive: WebAssembly on Kubernetes​

The new runtime operator is a serious bet on WebAssembly on Kubernetes as a first-class deployment story. Rather than treating Kubernetes as just another place to run a wasmCloud host, the v2 operator makes Kubernetes the source of truth: workloads, replica sets, and deployments are CRDs you manage with kubectl and standard GitOps tooling like Argo CD and Backstage. Because the wasmCloud host runs in a container, every containerized control your platform already enforces applies, while each WebAssembly component on top inherits component-level identity that shows up in logs, traces, and metrics. The deliberate alignment with Kubernetes naming — pods → workloads, replica sets → workload replica sets, deployments → deployments — means platform engineers can carry their existing mental model directly onto Wasm workloads, while gaining Wasm-specific advantages: guaranteed interface resolution, co-located components without a network hop, secure in-process plugins instead of arbitrary provider binaries, and per-component egress policy via allowed-hosts. The decision of whether to extend the host with a plugin or ship a long-running service inside a workload is its own design question — the plugin-or-service recipe walks through the trade-offs. Affinity and anti-affinity are slated for the replica-set/deployment controllers, and a future iteration aims to give each workload its own IP address so it is directly addressable from Kubernetes networking. The result is a Kubernetes integration that leverages the entire ecosystem out of the box while bounding each component's blast radius at the component boundary.

Who Should Watch This​

This call is especially valuable for platform engineers and Kubernetes operators evaluating how to run WebAssembly workloads in production — start with Lucas's operator walkthrough from 20:24 — CI/CD and DevEx engineers building polyglot Wasm build pipelines (Bailey's wash and setup-wash-action updates at 6:01), and WebAssembly toolchain watchers tracking the road to WASI P3 in runtimes (the Wasmtime release candidate at 57:32). The closing conversation on MCP servers and efficient local models (from 1:00:18) will interest anyone exploring WebAssembly at the intersection of AI.

Up Next​

The next community calls will track the combined release of the runtime, the v2 host, and the runtime operator into the wasmcloud/wasmcloud repo, along with documentation for building custom hosts and operating the next version. Watch for the operator's affinity/anti-affinity controls, per-workload IP addressing, and wasmCloud's integration of a stabilized WASI P3 into its next host.

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 →