Skip to main content
← Back

WebAssembly and Kubernetes, Provider Supervision & wash 0.38

The January 29, 2025 wasmCloud community call leans into resilience and developer experience. Brooks Townsend demos a new feature that lets the wasmCloud host supervise and automatically restart a capability provider that exits unexpectedly, Taylor walks through a Helm chart that aggregates benchmarking results into ConfigMaps for CNCF testing infrastructure, and the team digs into the wash 0.38 release with extended registry overrides and interface wildcards. After the formal agenda, Bailey Hayes fields a community question on WebAssembly and Kubernetes — why wasmCloud integrates with Kubernetes rather than replacing it — and the call closes with a deep, freewheeling discussion of error handling, Protobuf, and WIT.

Key Takeaways​

  • The wasmCloud host now supervises capability providers. If a provider process exits unexpectedly (a crash, an OS-level kill -9), the host logs a warning, re-pulls the provider's configuration and secrets, and restarts it — keeping the provider available for the next invocation without waiting on a higher-level orchestrator like wadm.
  • The host is evolving into a resilient daemon. This mirrors how wasmCloud already handles components: a panic during one invocation doesn't tear down the whole thing — the runtime simply readies itself for the next call. Provider supervision lands in wasmCloud 1.6.
  • Benchmarking gained data aggregation. The benchmarking Helm chart (v0.20) can now wait for a test to complete and write k6 summary results as JSON into Kubernetes ConfigMaps, where a small script aggregates them into a single array — the groundwork for scheduled benchmark runs on CNCF infrastructure.
  • wash 0.38 shipped extended registry overrides and interface wildcards. You can now declaratively point WIT dependencies at custom GitHub repos, local files, or HTTP archives in wasmcloud.toml, and override default capabilities (like swapping NATS KV for Redis) — making wash dev smoother behind proxies and pull-through registries.
  • wash dev is getting more (and optionally less) declarative. Custom-interface overrides let wash dev generate a complete deployment manifest even for non-standard interfaces, preserving the magic hot-reload loop for developers while still empowering platform engineers who want explicit, committed manifests.
  • wash CLI and wash lib are being consolidated into one wash crate. The merge streamlines releases (no more shipping the library, then the binary) — contributors planning large wash changes should coordinate with maintainers before the migration starts.
  • WebAssembly and Kubernetes are complementary, not competing. Bailey Hayes explains that wasmCloud's operator creates the Kubernetes abstractions so containers and components interoperate, letting platform operators keep their CNI, storage, and tooling while gaining resource density and solving the cold-start problem.
  • WASI Preview 3 native async is targeted for end of March. Bailey previews structured concurrency that resolves the function-coloring problem, with an easy adapter path from Preview 2 to Preview 3.

Chapters​

Meeting Notes​

Demo: A Self-Healing Host That Restarts Capability Providers​

Brooks opened with a demo born from an issue Lucas Fontes filed: when a capability provider fails — say it can't bind a port and the process exits, or someone runs kill -9 — the wasmCloud host previously just reported the exit and did nothing, leaving recovery to a higher-level orchestrator like wadm. The new feature changes that. Whenever a provider exits before the host has explicitly told it to stop, the host re-pulls the provider's configuration and secrets (reusing the same X key and ID for stability), then restarts the provider process.

Brooks ran a local host with wash up for NATS and wadm, deployed a hello-world component plus the HTTP server provider, confirmed curl localhost:8000 returned a response, then sent kill -9 to the provider. The logs showed a warning-level message ("it exited with wait status 9, so it was killed") followed immediately by the provider restarting and re-registering its listener. Under the hood, a new provider module keeps a process handle plus a background task that watches for config changes and waits on the provider's exit. Rather than exponential backoff, Brooks opted for a simple five-second sleep-and-retry to prevent hot loops — a deliberately pragmatic choice. He framed this as part of the host's evolution into a resilient daemon whose job is to keep components and providers running. The feature lands in wasmCloud 1.6.

In the Q&A, ossfellow asked about leftover resources and dynamic link changes. Brooks explained that each component instantiation gets its own resources, cleaned up after every invocation, so nothing lingers between calls. For a component using set-link-name against a provider that panicked, the component would need to handle the error during the failed call, but once the provider restarts with refreshed configuration, re-running the component logic finds all the same links and config in place.

Demo: Data Aggregation for Benchmarking​

Taylor demoed v0.20 of the wasmCloud benchmarking Helm chart, a continuation of work shown the prior week. New options let you wait for a test to complete and then collect results from Kubernetes ConfigMaps — the chart writes each k6 run's summary as JSON, one ConfigMap per test, and a small JQ command (plus a helper Python script in the repo) aggregates them into a single JSON array. Leaving results in ConfigMaps lets users do whatever they need: ship them to S3, build historical graphs, or visualize them however they like.

The motivation is running production-scale benchmarks on dedicated, isolated CNCF testing infrastructure — Kubernetes spins up a full wasmCloud lattice across multiple hosts, then hits it hard (the team had previously pushed ~100,000 requests/sec). The plan is a CI pipeline, scheduled weekly or triggerable per branch by maintainers, that spits out JSON to start and grows toward stored historical data. Micro-benchmarks on a single host stay cheap and informative; the big runs need clean, isolated infrastructure so nothing else skews the numbers. This work also seeds good first issues for the community around storing and visualizing benchmark data.

wash 0.38: Registry Overrides, Interface Wildcards, and a More Declarative wash dev​

Brooks walked through the wash 0.38 release. Fixes included wash dev fetching WIT via wackage, colorized text, and wash --version -o json. The headline features: extended registry overrides (thanks to Victor) let you specify in wasmcloud.toml exactly where each WIT dependency comes from — a custom GitHub repo, a local file, or an HTTP archive — which is a big help for teams operating behind proxies or pull-through registries like Artifactory. Interface wildcard overrides let you point all invocations of an interface (for example, wasi:keyvalue atomics, store, or batch) at a custom provider such as Redis instead of the built-in NATS KV, with configuration. And wash up now auto-downloads new patch versions of wadm and wasmCloud, so the team no longer needs a full wash release just to bump an included version.

Asked whether this makes wasmCloud more or less declarative, Brooks answered "more and/or less." wash dev already inspects a component for its runtime capabilities and generates a declarative manifest; for custom interfaces it can only leave a placeholder. The override feature lets developers feed wash dev the missing information so it builds the full manifest — preserving the magic hot-reload experience for developers while still empowering platform engineers who want explicit, version-controlled manifests. Liam Randall underscored that wasmCloud now serves both audiences: "just give me your component and I'll run it" for the naive path, and full declarative control for those who need it.

Crate Consolidation, the Roadmap, and a Call for Demos​

The team plans to consolidate the wash-cli and wash-lib crates into a single wash crate (the project recently took ownership of the long-registered wash name). The goal is smoother releases — today a new feature has to land in the library and then the binary. Brooks asked contributors with large in-flight wash changes to coordinate with maintainers before the migration, and ossfellow flagged that provenance/attestation workflows reference wash-cli in many places that will need cleanup. On the Q1 roadmap check-in: the benchmarking Helm chart is done, Roman is reworking provider and binary builds with GitHub Actions and Nix for faster CI, and much of the protocol/documentation work (Cloud events, control interface, policy APIs in a language-agnostic IDL or JSON schema) is still in brainstorming. Liam closed the formal agenda with a call to action: anyone in the community is welcome to demo at the top of the hour — reach out to Brooks on Slack.

WebAssembly News and Updates​

In the post-meeting discussion, Bailey Hayes gave a preview of upstream WebAssembly work. The Go SDK has matured to the point of idiomatic Go code with working breakpoints and test debugging, and several wasmCloud contributors are pushing WASI Preview 3 toward an end-of-March target — Victor Adossi is building the second reference implementation (in JCO) needed to ship, and Roman is on the Wasmtime side. The big Preview 3 feature is native async: structured concurrency that lets you compose components regardless of whether they're sync or async, resolving the function-coloring problem and eliminating the pollable/callback gymnastics of Preview 2. Bailey noted a fresh design decision — async via an explicit annotation rather than async-by-default — and pointed to Luke Wagner's earlier talk as the blueprint. Preview 2 components will get an easy adapter path straight to Preview 3. For more on the road to P3, see the WASI Preview 3 on wasmCloud blog post.

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 distributes workloads as OCI artifacts over NATS. With built-in OpenTelemetry observability and a Kubernetes operator, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure.

Topic Deep Dive: WebAssembly and Kubernetes​

After the agenda, Yordis Prieto relayed a conversation with a well-known DevOps voice who kept framing things as WebAssembly versus Kubernetes — and asked how wasmCloud answers people who see WebAssembly as something that must be injected into an existing container platform. Bailey Hayes's answer is the through-line for anyone weighing WebAssembly on Kubernetes: it's not an either/or choice.

If you use wasmCloud's Kubernetes operator, it creates all the Kubernetes abstractions so containers can talk to WebAssembly components and vice versa, and a platform operator can keep being a Kubernetes expert. Kubernetes is excellent at abstracting infrastructure — it's just not the right abstraction layer for applications, which is the gap components fill. The recommended pattern is to run the wasmCloud host inside a container: you inherit everything you've already built (CNI, storage, networking) and it keeps working, while you gain far better resource density and a solution to the cold-start problem.

Bailey cautioned against the anti-pattern of treating one container as one WebAssembly app (one host to one component), which throws away the density benefits and weakens the case for adopting Wasm in the first place. The "container-to-Wasm" approach can leave you with two problems — Wasm's current rough edges plus all the issues containers already have — because today's guest toolchains still assume POSIX and pull in the whole world (Go, for example, imports the WASI CLI socket APIs whether or not you use them). The upstream toolchain authors are actively retrofitting standard libraries to be capability-driven, and Bailey expects that what gets produced will eventually match exactly what you use. Yordis asked for a concise blog post to point curious-but-skeptical platform teams toward, and Bailey shared an existing post based on a talk by Lucas Fontes as a starting point. For the deeper "why," see how WebAssembly components extend the frontiers of Kubernetes.

Who Should Watch This​

This call is especially valuable for platform engineers and operators weighing how WebAssembly fits alongside an existing Kubernetes investment (jump to Bailey's WebAssembly-and-Kubernetes discussion at 1:03:06), wasmCloud operators who want the host to self-heal failing providers (the supervision demo at 6:30), and component developers tracking the wash toolchain and the road to WASI Preview 3 native async (wash 0.38 at 29:45 and the P3 preview at 57:37).

Up Next​

The next community calls will continue the Q1 roadmap push — faster CI via the Nix and GitHub Actions rework, the wash-cli/wash-lib consolidation, and protocol/documentation work like language-agnostic IDLs and JSON schemas for Cloud events and the control interface. Watch for benchmark runs landing on CNCF infrastructure, the wasmCloud 1.6 release carrying provider supervision, and a more formal WebAssembly/WASI Preview 3 update once the native-async design locks in.

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 →