wasmCloud v2 ships a fundamentally different runtime, Kubernetes-native orchestration, in-process host plugins, and an explicit networking model. It's the result of sustained work to translate production experience and community feedback into a reimagining of wasmCloud that's both simpler to operate and more powerful to build on. But shipping v2 was just the starting line.

Last Wednesday, we ran our Q2 roadmap planning session as part of the regular wasmCloud Wednesday community call. We walked through candidate priorities, the community weighed in on what matters most, and the results are now live as tracking issues in the Q2 2026 project board. This post walks through the work currently underway, the issues queued up for pickup, and how to get involved.

The Q2 priorities​

WASI P3 and async components​

WASI P3 is the biggest technical milestone on the horizon for wasmCloud, and for the WebAssembly ecosystem more broadly. P3 rebases WASI onto the Component Model's native async primitives: first-class stream<T> and future<T> types that propagate correctly across component boundaries, and an async handler model that lets developers write components in their language's native async style without any WASI-specific plumbing.

The practical impact is significant. HTTP handlers become async fn; bodies become stream<u8>; what were eight resource types in wasi:http collapse to two. The v0.3.0-rc-2026-03-15 release candidate is available now with support in Wasmtime 43 and experimental support in wasmCloud—see our blog on wasmCloud's WASI P3 support for the full walkthrough.

For Q2, the focus is on bringing WASI P3 support to production-readiness. The tracking issues are:

• #5015 — Support WASIP3 rc behind a flag (in progress): Landed the initial experimental P3 support behind the wasip3 Cargo feature; ongoing work keeps the implementation in step with the evolving RC.
• #5028 — Harden sockets and http impls for p3 (ready for work): The dispatch path works for the straightforward case; this issue tracks the edges — streaming bodies under load, backpressure, and long-lived connections — that separate a preview from a production-ready feature.
• #4951 — Support separate WasiCtx for different components in same store (triage): A prerequisite for correct per-component isolation as we scale up concurrent P3 workloads.

Language coverage is expanding in parallel: Rust is the happy path today, with TypeScript support via componentize-js in process. If you're building P3 components in any language, please file minimal reproductions for anything that surprises you.

Kubernetes integrations​

With v2, wasmCloud is Kubernetes-native. Several Q2 priorities focus on closing remaining gaps for operators coming from existing cluster topologies. One significant piece is already done:

• #5025 — Replace runtime-gateway with Kubernetes-native Service routing (completed): Shipped earlier this month, simplifying how wasmCloud integrates into cluster networking.

The remaining tracked work:

• #4939 — Autoscaling WorkloadDeployments (ready for work): Native autoscaling semantics for wasmCloud workloads, bringing scale-to-zero and load-driven scaling into the same reconciliation loop that already manages placement.
• #5016 — Implement wasmcloud:secrets plugin backed by Kubernetes Secrets (triage): A first-party secrets plugin that sources values from Kubernetes Secrets, closing the loop on secure credential delivery to components.
• #5049 — Scheduled vulnerability scans for published container images (ready for work): Ongoing CVE scanning for wasmCloud's published images, making them fit naturally into compliant container pipelines.

Beyond the tracked issues, the community also flagged a need for better ingress-controller documentation (Envoy, Traefik, Istio) and more complete Helm chart references. Expect those to land as doc PRs over the quarter.

Host plugins, interfaces, and routing​

One of the most substantial pieces of the Q2 roadmap is the maturation of wasmCloud's host plugin model. Host plugins let you extend what a wasmCloud host can offer to components as in-process capabilities with well-defined WIT interfaces.

Core plugin work:

• #5018 — [FEATURE] Host Component Plugins (triage): Lets a host plugin itself be backed by a Wasm component, rather than native Rust code. This is a significant expressiveness win: plugin authors can target a stable WIT contract and ship their plugin as a component.
• #4949 — [FEAT] HTTP Client Plugin (in progress): A first-party plugin that implements wasi:http/outgoing-handler, so components can make outbound HTTP calls without each deployment rolling its own.
• #5053 — [Example] Connection Pool Example for wasi:sockets Host Plugin (ready for work): A worked example of a stateful plugin, showing how host plugins can hold onto expensive resources (connections, sessions) across invocations.
• #4954 — [FEAT] Represent plugin+host WitWorld with VersionReq (ready for work): Lets plugins express version compatibility ranges rather than exact pins, so the host can resolve compatible plugins at load time.
• #5055 — [DOC] Host Plugin vs wasmCloud Service (ready for work): v2 introduced both in-process host plugins and persistent service companions. This tracks the documentation work to give operators and developers clear guidance on when to use each.

Multi-backend routing:

• #5051 — Implement Multiple Backend instances for hostInterfaces (triage): A recurring theme in the community discussion — the ability for a single wasmCloud host to support multiple backends for a given API, and to route across multiple components exporting handlers for the same interface. The Q2 scope is design: defining the semantics (A/B deployments, fallback chains, per-tenant backend selection) before committing to an implementation.

Performance and observability​

With v2's architectural simplifications, there's now a clean baseline to measure against, and the Q2 roadmap invests heavily in making that measurement public and repeatable.

• #5052 — [Performance] Benchmarking Suite for wasmCloud v2 (ready for work): A reproducible benchmark harness covering cold start, steady-state throughput, and tail latency: something evaluators and operators can run themselves.
• #5054 — Add HTTP invocation microbenchmarks for wash-runtime (in progress): Tight, per-path benchmarks for the HTTP dispatch hot path in wash-runtime, to catch regressions as the runtime evolves.
• #5056 — Instance pooling / reuse for HTTP invocations (blocked): A significant latency win once prerequisite work lands: reusing component instances across invocations instead of constructing them fresh each time.
• #5050 — [OTEL] OTEL Example with Context Roll-Up for v2 Wasm Workloads (ready for work): A worked OpenTelemetry example showing trace context propagating from an ingress request down through component invocations and plugin calls.
• #5023 — [FEATURE] Configurable engine flags and builder (ready for work): Exposes Wasmtime's engine configuration surface through wash-runtime, so operators can tune pooling, fuel, and memory limits per workload.

Adjacent to the perf work, arewefastyet.com-style public performance dashboards came up repeatedly in community discussion. Once the benchmarking suite in #5052 exists, a public dashboard built on top of it is the natural next step.

Platform tooling and developer experience​

A set of targeted DX improvements round out the roadmap:

• #5047 — Unify TLS support for wash dev and wash host (in progress): One TLS configuration path that works consistently between local development and production host deployments.
• #5030 — CI: Add publishing for wash-runtime crate (in progress): Publishes wash-runtime to crates.io on each release, making it a first-class dependency for embedders.
• #5017 — [FEATURE] Add wash winget package for windows (ready for work): Closes the last major install-experience gap on Windows.
• #4937 — [CI] publish OCI artifacts of examples (ready for work): Publishes the example components as OCI artifacts so users can wash and run them without a local build.
• #4953 — [BUG] wasmtime host resource types are string comparisons (ready for work): A correctness fix in the resource-type dispatch path.
• **#5034 — [Tests] Add wash-runtime integration test for host aliases in DynamicRouter: Test coverage for host-alias routing, guarding a subtle piece of the request-dispatch logic.

Composition tooling also came up strongly in community discussion. A wash compose subcommand, bringing component composition into the standard wash workflow rather than requiring wasm-tools directly, is a clear next step; expect a tracking issue to follow.

Security: proactive, not reactive​

If you've been following the wider WebAssembly ecosystem, you may have seen the Bytecode Alliance publish the largest set of security advisories in Wasmtime's history: 12 vulnerabilities uncovered with the help of a frontier LLM model.

wasmCloud is a natural target for this class of analysis. We inherit Wasmtime's security posture, and that's a strong foundation, but wasmCloud's own host implementation is independently in scope.

As part of the Q2 roadmap, we're committing to a proactive LLM-assisted fuzzing effort against wasmCloud's codebase, complementing the scheduled image scans tracked in #5049. The intent is to get ahead of external researchers rather than behind them. Findings will be filed and tracked publicly wherever responsible disclosure permits.

How to get involved​

The Q2 roadmap is live in GitHub Projects, broken out by status: In Progress issues are actively being worked, Ready for Work issues are unblocked and looking for owners, and Triage issues are under active design discussion.

A few ways to jump in:

• Pick up a "Ready for Work" issue: If any of the issues in that column sound interesting—especially the examples (#5053, #5050), the benchmarking suite (#5052), or the Windows package (#5017)—comment on the issue to coordinate.
• Weigh in on "Triage" issues: The Host Component Plugins, Multiple Backend instances, and Kubernetes Secrets plugin issues are all in the design phase. If you have production experience with any of these patterns, your input matters now.
• Join wasmCloud Wednesday: The community call runs every Wednesday; bring your questions, ideas, and PRs. Add to your calendar or join via Zoom.
• Good first issues: We maintain a curated list for new contributors: github.com/wasmCloud/wasmCloud/issues.
• Slack: The fastest path to maintainers and other contributors is the wasmCloud Slack.
• P3 bug reports: If you're testing WASI P3 components and running into issues, please file them. Minimal reproductions are especially valuable right now.

Related reading:

• wasmCloud v2.0 is here
• Writing and running async components on wasmCloud with WASI P3
• Wasmtime Security Advisories, April 2026
• wasmCloud Q2 2026 Roadmap