Skip to main content
← Back

WebAssembly on Kubernetes: Volume Mounts, Services & HTTP Ingress

The December 10, 2025 wasmCloud community call is all about running WebAssembly on Kubernetes in production. Eric Gregory walks through a new doc and demo for mounting Kubernetes volumes into a Rust component in wasmCloud v2, then shares a fresh overview of workload services as the stateful companions to stateless components. Lucas Fontes lays out the project's biggest remaining deficiency — HTTP ingress across many hosts — and proposes an intelligent ingress gateway that routes by ephemeral workload ID for zero-downtime deployments, all without tying wasmCloud to Kubernetes.

Key Takeaways​

  • Volume mounts in wasmCloud v2 let a component read external files via WASI filesystem pre-opens backed by a Kubernetes volume — Eric demoed a Rust component serving a sample.txt file mounted from the host through a local kind cluster, with deployment docs landing soon
  • Workload services are stateful companions to stateless components — a new overview doc diagrams the communication flow, use cases, and code examples for using services as the local-host provider of stateful and TCP functionality for a workload
  • wash is getting full-workload development — today wash dev targets a single component or service, and Bailey is filing an issue to let you define and iterate on an entire workload (multiple components plus a service) locally, e.g. a cron service triggering a component every second
  • HTTP ingress is the project's key deficiency — with multiple hosts in a cluster there is no clear answer for which host should receive a request, and redeploys can move a workload to a new host or cause two apps to collide on the same TCP port
  • The proposal: an intelligent HTTP ingress gateway that sits in front of all wasmCloud hosts, reads workload-to-host placement from the Kubernetes API, and routes by the ephemeral workload ID so rollouts are transparent and never serve a 404/500 mid-deployment
  • Ingress stays optional and Kubernetes-agnostic — the gateway is a two-way door (movable to contrib if it doesn't pan out), can be a target behind existing controllers like Contour or NGINX, and keeps hosts free to run at the edge or on IoT rather than boxing wasmCloud into Kubernetes
  • eBPF + WebAssembly came up for low-level routing — Bailey pointed to research projects running Wasm in what would otherwise be kernel space, including work out of Beijing, a Cisco prototype, and Ben Titzer's group at Carnegie Mellon
  • A new release candidate was being cut during the call, with a WebGPU example and updated WIT bindings discussed for the C++ and Rust toolchains

Chapters​

Meeting Notes​

Demo: Mounting Kubernetes Volumes into a Component​

Eric Gregory walked through a new doc — opened as a PR — covering how to use external filesystem resources via WASI filesystem pre-opens in wasmCloud v2, backed by a Kubernetes volume. He started from a simple Rust component that uses standard Rust file APIs plus the standard HTTP handler to pull data from an external file and return it in an HTTP response. To make that work in a deployment, the doc names a volume and specifies a target host path in the host deployment, adds the volume to the workload deployment with a matching host path, then adds the volume mount under a component's local resources with a mountPath for where the data appears inside the component. Eric deployed it to a local kind cluster and curled the running component to return a sample.txt file loaded via the mount — a deliberately basic proof of concept. The example will land in the wasmCloud repo and the deployment docs are coming very soon. (See the operator manual on filesystems and volumes.)

New Doc: Workload Services as Stateful Companions​

Eric then shared a second PR — flagged by Bailey as the "doc of the week" under overview → workload services — that expands on Lucas's earlier presentation on services. The doc frames services as the stateful companions to stateless components: they function essentially as a local host providing stateful functionality and TCP service for a workload. It breaks down the communication flow and use cases, and adds code examples and diagrams along with development considerations. Bailey called it close to MVP-complete — it answers one of the top requests, "explain how services look and feel" — with the development side of services still to come under the wash section.

Developing Full Workloads Locally with wash​

Bailey Hayes jumped the queue with a status update: today the way wash and wash dev are configured is geared toward developing a single component or a single service, and the team wants that flow to work for entire workloads. After prototyping a few approaches, Bailey settled on a preferred design and committed to filing a full issue proposal that day. The goal is to let wash config hold a complete workload definition — multiple components plus a service — and iterate on it locally, for example a cron service that triggers a component every second, mirroring the kind of example Eric demoed. (See the developer guide on creating services.)

The HTTP Ingress Problem — and a Gateway Proposal​

Lucas Fontes tackled a question that recurs in the community: how do you receive HTTP on your components once you have more than one host in a cluster? Local and single-host setups are easy — map a port and go — but with multiple hosts, there is no clear answer for which host should receive a request. Because wadm (and the v2 operator) place workloads dynamically, every redeploy can move a workload to a new host, breaking HTTP, and two apps that each declare an HTTP provider can collide on the same TCP port, ejecting one. Lucas called this ingress story one of the key deficiencies of the project, present in both wasmCloud v1 and v2.

Today's workaround is host groups — the Helm chart declares public ingress, private ingress, and default groups, and you place HTTP-serving components in the public group — but this forces extra containers and works against Wasm's density advantage. Lucas's proposal is an intelligent HTTP ingress gateway: an HTTP server in front of all hosts that reads workload-to-host placement from the Kubernetes API (via a watcher on the workload CRD) and routes requests to the correct host. Crucially, it routes by the ephemeral workload ID rather than the declared hostname, so a removed workload's ID is never reused and rollouts are transparent — the operator never removes a workload from a host until the new revision is up and healthy, avoiding 404s and 500s mid-deployment. The gateway stays optional and Kubernetes-agnostic: it can be a target behind existing controllers like Contour or NGINX, and deliberately avoids tying wasmCloud to Kubernetes services so hosts can still run at the edge and on IoT. Lucas expected a prototype PR by the end of the day.

WebAssembly News and Updates​

The thread connecting this call is making WebAssembly on Kubernetes feel like a first-class cloud-native platform: filesystem access through WASI pre-opens, stateful services alongside stateless components, and a real answer for HTTP ingress across many hosts. In the open forum, Frank raised using eBPF with WebAssembly for low-level routing, and Bailey pointed to several research efforts running Wasm in what would otherwise be kernel-space code — work out of a Beijing university (Euphoria), a Cisco prototype, and Ben Titzer's group at Carnegie Mellon exploring ways to instrument WebAssembly at that layer. The call closed with a new release candidate being cut, plus discussion of a WebGPU example and matching WIT bindings across the Rust and C++ toolchains. For ongoing updates, follow the wasmCloud blog and the Bytecode Alliance.

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 architecture. wasmCloud's reference host is built on Wasmtime, schedules workloads over NATS, and distributes Wasm via OCI registries. With a Kubernetes operator and built-in OpenTelemetry observability, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure.

Topic Deep Dive: HTTP Ingress for WebAssembly on Kubernetes​

The hardest problem in this meeting is one Kubernetes solved years ago for pods and wasmCloud now has to solve for WebAssembly workloads: when a scheduler can place — and re-place — a workload on any host in the cluster, how does external HTTP traffic find it? The clever part of Lucas's design is what it routes on. Instead of trusting the hostname a workload declares (which invites collisions when two teams both claim example.com), the gateway keys on the ephemeral workload ID the host generates. Because that ID is never reused once a workload is gone, the ingress layer can never send a request to a dead endpoint. The gateway gets its placement map for free by watching the workload CRD through the Kubernetes API, so no extra state lives in the runtime operator. And by keeping the gateway as a routing target — rather than manipulating Kubernetes service endpoints directly — wasmCloud preserves the property that only the operator must live in Kubernetes while hosts can run anywhere, including at the edge and on IoT. It is the kind of design that makes running WebAssembly components on Kubernetes production-ready without locking you to any one platform.

Who Should Watch This​

This call is especially valuable for platform engineers running multi-host wasmCloud clusters who need a real HTTP ingress story and zero-downtime rollouts (Lucas's proposal starting at 6:56), application developers who need stateful filesystem access or services alongside their components (Eric's volume mounts demo at 0:42 and the workload services doc at 4:09), and infrastructure teams curious about edge routing and eBPF + WebAssembly experiments (open forum at 28:49).

Up Next​

The next community calls follow the release candidate that was being cut during this meeting, plus Lucas's prototype HTTP ingress gateway PR, Bailey's issue proposal for full-workload development in wash, and the volume mounts example and deployment docs landing in the repo. Documentation of the week was the new workload services overview, with the VolumeMount doc tracked in PR review.

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 →