Skip to main content
← Back

Q2 2025 Roadmap: WebAssembly on Kubernetes, HTTP & WASI P3

The April 23, 2025 wasmCloud community call is a special edition dedicated to Q2 2025 roadmap planning. Brooks Townsend reviews how the Q1 roadmap went — 3,500 contributions and nine completed items — then reorganizes the roadmap into research, development, and good first issue categories to give contributors clearer entry points. The biggest theme is hardening HTTP across the wasmCloud ecosystem, including how WebAssembly on Kubernetes should integrate with Envoy, Istio, and ingress controllers. The team also commits to preparing the codebase for WASI P3, moving the workload identity RFC forward, and adopting the XDG Base Directory Specification.

Key Takeaways​

  • The Q1 2025 roadmap completed nine items, but the bigger story is scale: ~30 contributors per month and over 3,500 contributions to wasmCloud in a single quarter, with monthly releases and nearly 2,000 GitHub stars
  • The Q2 roadmap is reorganized into three new categories — research (open-ended, expert-driven work like WASI P3 tracking), development (well-scoped features any maintainer can take), and good first issue (clear on-ramps for new contributors)
  • Lucas Fontes proposed treating bugs as thematic bundles rather than isolated issues, pairing subject-matter experts with newer contributors; HTTP is the prime example, warranting a mini task force
  • The headline epic is hardening HTTP across guest SDKs, the host, and the built-in HTTP server/client — with a concrete goal of taking the built-in HTTP provider out of experimental and onto wasmCloud's SemVer stability guarantees
  • A deep design exploration of HTTP will define what wasmCloud is responsible for (getting a request to the right component via path- and host-based routing) versus where you front it with Kubernetes, Envoy, Istio, or NGINX for load balancing and ingress
  • Preparing the codebase for WASI P3 is a top research priority, alongside validating the 0.3 feature set and tracking interface and provider changes
  • The workload identity RFC (SPIFFE-based, demoed at KubeCon) moves onto the roadmap under research, with an open question about how an upstream SPIFFE issue affects Istio ambient mode integration
  • wasmCloud will adopt the XDG Base Directory Specification, replacing the ad-hoc ~/.wash directory with standard config, data, and cache homes — important groundwork for the evolving wash plugin system

Chapters​

Meeting Notes​

Looking Back at the Q1 2025 Roadmap​

Brooks opened by noting this was a special-edition call with a single agenda item — quarterly roadmap planning — and no demo. Before planning Q2, he walked back through the Q1 2025 roadmap, the first one formalized after wasmCloud's acceptance as a CNCF incubating project. The team applied rigor to APIs, capability provider SDKs, and documentation, and tracked the large community effort around WASI P3.

The retrospective was honest: Q1 was an ambitious roadmap with a few under-specified items (like external capability provider support with no RFC), but most items were at least started, and several — the cron-job capability provider, the built-in HTTP client provider, NATS object stores, and clap autocompletion — are sitting in open pull requests. Going forward, Brooks suggested tagging those open PRs directly on the roadmap so the remaining work is visible and items close when the PR merges. The CNCF dev stats tell the real story: roughly 30 contributors a month, over 3,500 contributions in the quarter, a steady monthly release cadence, and nearly 2,000 GitHub stars — far more activity than the nine formally "completed" roadmap items suggest.

New Roadmap Categories: Research, Development, Good First Issue​

To make the Q2 roadmap more actionable, Brooks introduced three categories that describe who can pick up an item rather than just its type. Research is for big, open-ended, expert-driven work — WASI P3 tracking, Taylor's exploration into defining wash plugins — that often results in RFCs. Development items are well-scoped features that any maintainer or experienced contributor can take (for example, switching the Blobstore S3 provider from scrubbed environment variables to config and secrets). Good first issue provides a clear on-ramp for newcomers who want to know exactly where to start.

Lucas Fontes reinforced the principle: items on the roadmap should be specific enough that the team knows what needs to be done; anything ambiguous — including investigating why a bug happens — belongs in research. The long-standing "revisit provider SDK testing ability" issue was the canonical example: real, but too vague to act on without a maintainer first defining its scope.

Hardening HTTP Across the wasmCloud Ecosystem​

The largest theme of the session was HTTP. Lucas argued that wasmCloud was accumulating "death by a thousand cuts" — many small HTTP issues across the host, guest SDKs, and providers — and proposed bundling them into a focused mini task force that pairs an expert with someone ramping up on the code. Brooks captured a research item: broadly harden HTTP support across the ecosystem so it is consistent, failure-resistant, and easy to use. The concrete goal Lucas suggested: get comfortable enough to take the built-in HTTP provider out of experimental and commit it to the same SemVer stability strategy as the rest of wasmCloud's features.

A big part of that exploration is defining wasmCloud's responsibility for HTTP routing and load balancing — and where it hands off to existing infrastructure. wasmCloud already supports listening on a reserved address/port with routing by path or by host header, but path wildcards and variables add real maintenance burden. Brooks and Colin Murphy landed on a clear scoping principle: wasmCloud's job is to efficiently get an HTTP request to the right component, not to become an ingress. Beyond that, you front it with Kubernetes, Envoy, Istio, or NGINX. Lucas detailed the nuance — load balancers like AWS and GKE expect a stable port, so a single multi-tenant HTTP provider with host-based routing behaves very differently from a dedicated per-component provider — concluding that the real gap is documentation explaining when to use each pattern for each use case.

Preparing for WASI P3​

Throughout the call, WASI P3 was treated as the marker that everything else has to line up behind. wasmCloud contributors are putting serious time into it — Bailey driving it as TSC director, Roman implementing P3 in Wasmtime, and Victor Adossi working on the JavaScript tooling and Node runtime pieces. Colin Murphy suggested making validation of the 0.3 feature set its own epic, and the team agreed P3 prep belongs in research: there isn't a single takeable task yet, but tracking how HTTP interfaces and providers change under P3 is critical, since wasmCloud wants to add P3 support without breaking existing WASI P2 components. The team also added a documentation item for the new bus error type — a wRPC-derived error interface that lets custom interfaces surface transport-layer failures (a disconnected NATS, an unbound TCP socket) to the guest as errors instead of panics.

Workload Identity, WebGPU, and XDG​

Brooks moved the workload identity RFC onto the roadmap under research. Jonas and Colin have already landed early features — connecting to NATS with workload identity and letting a component fetch its own identity, as demoed at KubeCon — but an open upstream SPIFFE issue may change how it's implemented, especially for sidecarless service meshes like Istio ambient mode (the topology wasmCloud's lattice already resembles). The team agreed identity should be optional and largely invisible: "just like Istio, just like Kubernetes — wasmCloud should work with it, but you shouldn't need it."

Colin floated WASI WebGPU for machine-learning workloads ("wasmify your LLM"), which the team agreed to keep an eye on once headless WebGPU lands in Wasmtime. Finally, Brooks proposed replacing the ad-hoc ~/.wash directory with the XDG Base Directory Specification — config and context in the config home, downloads/logs/keys in the data home, and package cache plus JetStream in the cache home — an easy, conventional improvement that also lays groundwork for plugins.

WebAssembly News and Updates​

This roadmap session is a window into where server-side WebAssembly was heading in mid-2025. The community-wide effort around WASI Preview 3 — the next major step for the component model, bringing native async, streams, and futures — dominated the long-term planning, with wasmCloud maintainers contributing directly to Wasmtime and the JavaScript tooling under the Bytecode Alliance. For more on what P3 means for the platform, see WASI P3 on wasmCloud. On the operational side, the call reflected WebAssembly's growing convergence with cloud-native infrastructure: how Wasm HTTP workloads should compose with Kubernetes ingress, Envoy, and Istio, and how SPIFFE-based workload identity fits a Wasm lattice. For ongoing updates, follow the Bytecode Alliance and the wasmCloud blog.

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, and C#) while the platform handles capabilities like HTTP, messaging, and key-value storage through a pluggable provider architecture. wasmCloud's host is built on Wasmtime and connects hosts into a flattened NATS lattice, with first-class Kubernetes integration for running components alongside your existing infrastructure. With built-in OpenTelemetry observability and a deny-by-default security model, wasmCloud bridges WebAssembly's portable, sandboxed execution and production cloud-native operations.

Topic Deep Dive: WebAssembly on Kubernetes​

The HTTP discussion in this call is really a discussion about WebAssembly on Kubernetes and where wasmCloud sits in a cloud-native stack. The team's conclusion is deliberately narrow: wasmCloud should give you the tools to route an HTTP request to the right component — by path or host header — and nothing more. Everything beyond that (real load balancing, TLS termination, advanced routing) is delegated to the infrastructure Kubernetes users already run: Services, Envoy, Istio, or an ingress controller. That boundary has concrete consequences. Cloud load balancers expect a stable port, so a single shared HTTP provider doing host-based routing integrates cleanly with Kubernetes Services, while binding each component to its own port pushes you toward headless/external-name Services and DNS-based balancing. Colin's earlier Envoy work pointed at the same answer the team keeps returning to: in production you'll have a Kubernetes API server, and Kubernetes-native solutions for service meshes and ingress flow from there. To go deeper on running components on Kubernetes, see the wasmCloud Kubernetes operator and the guide on exposing a workload via a Kubernetes Service.

Who Should Watch This​

This call is especially valuable for platform engineers and Kubernetes operators trying to understand how WebAssembly HTTP workloads compose with Envoy, Istio, and ingress (the HTTP and Kubernetes discussion from 29:27), wasmCloud contributors looking for a clear, well-scoped on-ramp under the new research/development/good-first-issue categories (18:20), and security and identity teams tracking the SPIFFE-based workload identity work and its Istio ambient mode implications (the workload identity RFC at 49:00).

Up Next​

The Q2 2025 roadmap sets the agenda for the coming months: a focused HTTP hardening pass aimed at taking the built-in HTTP provider out of experimental, a deep design exploration of HTTP routing and Kubernetes/Istio/Envoy integration, preparation of the codebase for WASI P3, the workload identity RFC, evolution of the wash plugin system, automatic washboard standup with wash dev, documentation for the new bus error model, and the move to the XDG Base Directory Specification. You can follow and comment on the full roadmap on the wasmCloud GitHub project.

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 →