Skip to main content
← Back

wasmCloud Q1 2025 Roadmap: WebAssembly on Kubernetes

The January 15, 2025 wasmCloud community call is the project's Q1 2025 roadmap planning session. Liam Randall walks the GitHub roadmap board live, gathering community feedback on the work that matters most for the quarter. A recurring theme is WebAssembly on Kubernetes: simplifying the platform Helm chart and hiding the NATS requirement for operators, plus an RFC for minimal-footprint ingress. The call also covers a provider SDK testing framework, tracking WASI Preview 3, bundling wasmCloud and wadm into the wash CLI, and stabilizing wasmCloud's CloudEvents and control-interface APIs nearly a year after the 1.0 release.

Key Takeaways​

  • Q1 2025 roadmap planning ran straight from the GitHub discussion and roadmap board — Liam reviewed the Q4 2024 carryover (NATS object store, WASI Blobstore, HTTP server provider docs) before opening community feedback
  • Simplifying WebAssembly deployment on Kubernetes was a major thread: the platform Helm chart subsumes several charts (including NATS), and the team wants the default install to hide NATS for operators who don't need it — while keeping an escape hatch for complex, production NATS setups
  • A provider SDK testing framework rose to the top of the list, with a standard suite of integration tests that can run against any vendor implementation (Azure Blob Store, NATS Blobstore, key-value) reusing the same baseline interface tests
  • WASI Preview 3 became a tracking epic — wasmCloud plans to integrate behind an experimental feature flag, follow the Bytecode Alliance's progress, and avoid breaking the developer experience while the async/streams model stabilizes
  • Bundling wasmCloud and wadm as libraries in the wash CLI was re-proposed as a spike: a single binary for wash up and wash dev for a more consistent local developer experience, gated behind a toggle to disable the embedded components
  • API stabilization got three tickets: standardizing how host IDs appear in CloudEvents, defining event structures in a language-agnostic IDL (WIT or JSON Schema) for codegen, and consolidating image-reference field names across the control interface
  • A cron job (built-in scheduler) provider and wasi-nn provider were discussed as good first issues, with Aditya volunteering for the scheduler and Masood drafting an RFC; community-produced wasmCloud videos were also welcomed
  • An ingress RFC for minimal-footprint deployment (Colin) sketched header-based routing through a reverse proxy so wasmCloud can act as an open-source CDN/edge compute platform without depending on Kubernetes for ingress

Chapters​

Meeting Notes​

Reviewing the Q4 Roadmap and Process​

Liam opened the Q1 2025 roadmap planning session by looking back at the Q4 2024 roadmap, noting that the benchmarking suite and testing work largely landed and that the remaining items — the NATS object store implementation, a feature-complete-and-tested WASI Blobstore PR awaiting review, and HTTP server provider docs — could simply roll into the start of the year. He explained that the new roadmap board followed the repeatable roadmapping process documented in the wasmCloud repo, so any maintainer could lead a session. Tickets were sourced from the issue backlog, requests from teams running wasmCloud from QA to production, and the public GitHub discussion. On process, the call confirmed that roadmap items should not be auto-closed as stale: items with a roadmap label or attached to a milestone are excluded by the stale-bot action (which Lachlan migrated from the deprecated stalebot).

Providers, Testing, and WASI Proposals​

A provider SDK testing framework was one of the strongest threads. Masood, drawing on his NATS Blobstore provider work, argued the framework itself needs to be functional before requiring integration tests on every provider delivery. Liam agreed and described a standard suite of baseline-interface tests reusable across vendors (Azure Blob Store, NATS Blobstore, key-value). The group also discussed bringing a new capability provider per quarter onto the roadmap; Masood agreed to write an RFC for a wasi-nn provider (or possibly wasi-messaging, given momentum on the messaging side), and a cron job / built-in scheduler provider was flagged as a great first issue, with Aditya volunteering. Aditya also offered to produce community wasmCloud videos. On standards, Liam created a WASI Preview 3 tracking epic; Bailey Hayes explained the goal of building integration workflows to test upstream changes behind a flag — without rolling them out — and tracking the Bytecode Alliance work through sub-issues.

WebAssembly on Kubernetes: Simplifying Deployment​

The most-debated topic was simplifying WebAssembly deployment on Kubernetes. wasmCloud's platform Helm chart subsumes several charts — including NATS — and Bailey proposed hiding the NATS requirement by default so operators can focus on deploying wasmCloud, with the ability to point at an existing NATS deployment. Jochen cautioned that complex NATS setups (multiple JetStream domains) make assumptions the Kubernetes operator must respect, so configurability for JetStream and leaf domains is essential. Masood reminded the group that the original "platform chart" intent was a single bespoke deployment of the whole platform, while Yordis pushed for capturing real user pain points (and better NATS documentation) before optimizing. Bailey framed it as a personas problem — newcomers who just want a host versus production teams already expert in NATS — and noted the value of letting users deploy either the host or the operator. Colin's separate ingress RFC for minimal-footprint deployment sketched header-based routing through a simple reverse proxy (Envoy or nginx) so wasmCloud can serve as an open-source CDN/edge compute platform without depending on Kubernetes for network ingress.

Developer Experience and API Stabilization​

Several improvements targeted developer ergonomics and long-term stability. Liam re-proposed a spike to bundle wasmCloud and wadm as libraries in the wash CLI, giving a single binary for wash up and wash dev (potentially embedding NATS too) — gated behind a build toggle to disable the embedded components, per Mark's request. Smaller wins included tab autocomplete for wash app subcommands, auto-generated CLI docs on release, replacing the --rpc and --ctl flags with --nats, and only rebuilding changed providers in CI. Finally, with wasmCloud approaching a year on 1.0, three API stabilization tickets aimed to standardize how host IDs appear in CloudEvents, define event structures in a language-agnostic IDL (WIT or JSON Schema) for cross-language codegen and auto-updating docs, and consolidate image-reference field names across the control interface.

WebAssembly News and Updates​

This roadmap call lands squarely in the wasmCloud 1.x era, with the project freshly incubating in the CNCF and approaching its first anniversary on 1.0. The headline ecosystem item is WASI Preview 3 — the next iteration of the WebAssembly System Interface bringing native async, streams, and futures — which the Bytecode Alliance was actively building and which wasmCloud planned to track behind an experimental feature flag. The team also flagged the upstream shift in HTTP interfaces that P3 would bring (a single bidirectional handler replacing separate incoming/outgoing handlers), influencing whether to build a built-in HTTP client now or wait. For more on WASI's trajectory, see the wasmCloud blog's coverage of WASI Preview 2 on wasmCloud.

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 capability provider architecture. wasmCloud's host is built on Wasmtime and connected over NATS, and its Kubernetes operator brings the same workload and scheduling model into existing clusters. With built-in OpenTelemetry observability, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure.

Topic Deep Dive: WebAssembly on Kubernetes​

Much of this call traces back to one question: how do you make WebAssembly on Kubernetes simple enough for operators who don't want to become NATS experts, while staying flexible for those who already are? wasmCloud's Kubernetes operator schedules WebAssembly workloads into clusters, but the platform Helm chart's habit of bundling NATS, Grafana, and Prometheus charts created friction — both in configuration surface and in naming (the "wasmCloud host" chart versus the host itself). The proposed direction is a default install that embeds just the NATS wasmCloud needs (a few KV buckets, streams, a JetStream domain) while letting advanced users point at an existing deployment, much like how teams treat managed Kubernetes installs. Colin's ingress RFC complements this by exploring header-based routing through a reverse proxy, so a host can listen on a port and route to a component's incoming handler — letting wasmCloud behave like an edge/CDN compute platform without leaning on Kubernetes networking. As the component model and host plugins mature, the goal is a Kubernetes-native experience where WebAssembly workloads schedule, scale, and route like any other cloud-native primitive. For a hands-on look, see the blog on running WebAssembly components on Kubernetes with wasmCloud.

Who Should Watch This​

This call is especially valuable for platform engineers and operators running wasmCloud on Kubernetes who want to influence how Helm and NATS deployment get simplified (start with the Helm/NATS discussion at 1:01:01), capability provider authors interested in the provider SDK testing framework and a new-provider-per-quarter cadence (the testing thread at 13:48), and WebAssembly tooling watchers tracking the road to WASI Preview 3 and its impact on the HTTP interfaces (Bailey's WASI P3 epic at 52:06).

Up Next​

The roadmap items raised here set the agenda for Q1 2025: a provider SDK testing framework and integration tests, the WASI Preview 3 tracking epic, the wash bundling spike, simplified Kubernetes/Helm deployment, and the API stabilization tickets. Liam committed to documenting the high-level roadmap goals, running a retrospective on the previous roadmap, and opening a Q2 2025 discussion to start collecting the next round of ideas. The full roadmap discussion lives on GitHub, with items tracked on the roadmap project board.

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 →