Skip to main content
← Back

Q2 Roadmap Planning: Componentize the World, WASI P3, Multipath Routing & MCP Sandboxing

Watch on YouTube ↗

The April 8, 2026 wasmCloud community call is a full Q2 roadmap planning session, run as a collaborative Excalidraw whiteboard with DIY dot-voting. Bailey Hayes seeds high-level themes — componentize-the-world, WASI P3 readiness, LLM fuzzing, operator/platform experience — and the community fills in the gaps: SQLite/Lightstream integrations, microcontroller and tiny-device support via a slimmer Wasmtime, sandboxed MCP workloads on WebAssembly, multipath routing for workloads, named interfaces for backend selection, and a richer cron job provider. Jeremy Fleitz walks attendees through wasmCloud v2's built-in SIG store attestation and provenance for OCI artifacts, and the session closes with attendees voting on which initiatives shape the Q2 plan.

Key Takeaways​

  • Q2 roadmap planned collaboratively — Bailey ran an Excalidraw whiteboard session with DIY dot-voting; the maintainers will combine the votes with Slack feedback to publish the Q2 wasmCloud project roadmap by end of week
  • Componentize-the-world is a core Q2 theme — track examples and templates for every supported language in wasmCloud, linking each one back to the upstream PR (launch-badges, sqlx, side rest) that made it possible
  • wasmCloud signs and attests every OCI artifact via GitHub — runtime, operator, wash CLI, and even WIT-only artifacts ship with SIG store / cosign-backed attestation and provenance through a reusable GitHub workflow; gh sarah and the wash install script verify on download
  • Microcontroller and tiny-device support is now plausible — Wasmtime has become small enough to target embedded devices, opening a new deployment story for wasmCloud
  • Sandboxing MCP and AI workloads with WebAssembly is the leading Q2 thesis — Bailey's argument: WebAssembly is a better sandbox than process-level isolation (bubble wrap, BPF, syscall filtering) and lets you skip the per-credential whack-a-mole that tools like cloud-code now play
  • Multipath routing for workloads — Aditya proposed letting multiple components in one workload export wasi-http and route by path; Bailey explored doing this at the runtime gateway instead with named interfaces and host components
  • Richer cron job provider — Aditya proposed an evolution of the current sleep/wake/fire pattern into a Kubernetes-CronJob-aligned scheduling provider for production use cases
  • Database integrations on the request list — SQLite, Lightstream, PG Lite, and SoLap are all candidates for first-class examples and templates; the broader push is to be the easiest place to run new databases as WebAssembly
  • Multi-cluster runtime operator support — Frank Schaffa proposed an Argo CD-style pattern where multiple operators coordinate across clusters, while staying unaware of each other
  • Performance dashboard for the runtime — "are we fast yet?" page tracking key metrics over time so users can see where the runtime is heading and compare across releases

Chapters​

Meeting Notes​

Q2 Roadmap Planning Session​

Bailey Hayes opened the call as a deliberate Q2 roadmap planning session — three months of work to land by July — and shared an Excalidraw whiteboard for collaborative input. The prompt to attendees: what's one thing wasmCloud should prioritize this quarter, what's a rough edge you've been hitting repeatedly, and what would make you deploy this in production?

She seeded the board with a few high-level themes she's been thinking about:

  • Component ecosystem — make X, Y, and Z compile to a component and provide it as an example with an ergonomic development experience
  • LLM-driven fuzzing for WebAssembly and wasmCloud — leveraging new fuzzing techniques to secure open source software
  • Operator and platform experience — observability, runtime, operator Helm charts, customized integrations with the cloud-native ecosystem
  • Ecosystem integrations — MCP servers and other emerging workflow patterns

WASI P3 is the biggest planned milestone for Q2 — already tracked, already with some experimental flag-gated support — and a confirmed Q2 deliverable. Bailey then went quiet on stream for several minutes to let attendees drop their own items onto the board.

Componentize-the-World and Composition Tooling​

Bailey's core component-ecosystem proposal: rather than chasing every example as a one-off, track in wasmCloud which upstream crates and libraries have been made component-compatible, link the relevant PRs (launch-badges, sqlx, side rest), and treat each as a small, well-scoped good first issue. These are concrete, time-boxed, and benefit everyone.

She also floated the question of whether wasmCloud should ship a wash compose command — a CLI surface that takes a wash config and composes components together (YAML syntax for the config, since that's what the rest of the wash config already uses). The honest open question: should composition tooling be in wash, or should it live as an external project? She wanted community input on that direction rather than pushing it down a path.

CI Signing, Attestation, and Provenance​

Jeremy Fleitz asked for vulnerability scans (Trivy or similar) to be visible inside the repo, and for the wasmCloud image to clearly attest its UBI-minimum base. Frank Schaffa picked up on the thread and asked about image signature protection. Bailey demoed the existing setup: every wasmCloud OCI artifact built with the setup-wash and publish actions is signed with attestations and provenance using GitHub's built-in SIG store / cosign integration — visible on a recent CI run, and propagatable to an enterprise's internal SIG store. The wash install script uses gh sarah to validate signatures on download, so users don't have to manage public keys themselves. Bailey is also doing this for the WASI WIT-only artifact publishes (wasi-random, etc.), so even pulling raw interface definitions can be cryptographically verified. Frank's reaction summed it up: "this should probably be more publicized."

Integration Examples and Multi-Cluster Operator​

Jeremy walked through the integration examples roadmap. Several customers and KubeCon attendees have asked for opinionated getting-started configs that combine a kind cluster with a specific gateway — envoy, traefik, Istio, and the Kubernetes Gateway API — to show how wasmCloud v2 resolves and routes via service endpoints and endpoint slices on headless services. A PR is in code review now adding the Kubernetes API Gateway example. Frank Schaffa added two items: multi-cluster operator support (an Argo CD-style pattern where multiple operators coordinate across clusters without knowing about each other — the trick being not how to deploy in multiple, but how to make them aware of each other), and a performance metrics dashboard that tracks where the runtime is over time so attention to performance is baked into every release.

Microcontroller Support, Big-Go, and Database Integrations​

Bailey surfaced a few other items she's been mulling. Microcontroller and tiny-device support is plausible now that Wasmtime has its tiny embedded build, which is a major change from a year ago. Database integrations — SQLite, Lightstream, PG Lite, SoLap — have been repeatedly requested in Slack; the goal would be enumerated high-value targets shipped as examples and templates. And the big-Go migration would replace the existing tinygo-based Go support with the new Bytecode Alliance ergonomic SDK/CLI pattern (parallel to componentize-go, componentize-py, componentize-net), which should clean up the long-standing reflection-library issues with tinygo.

Sandboxing MCP and AI Workloads on WebAssembly​

Yordis Prieto asked whether anyone has done AI sandboxing on top of wasmCloud — he's building Trogan AI on a full distributed JetStream-backed state model and wants to spawn sandboxed agent containers with controlled capabilities and network policies. Liam Randall flagged that he's heads-down on phase two of sandboxmcp.ai, exactly that kind of sandboxed-MCP workload pattern.

Bailey's pitch: there is no better sandbox than WebAssembly if you can get the code to compile to it. She contrasted the WebAssembly approach with how tools like cloud-code do process-level sandboxing today — namespacing the file system, using bubble wrap for process isolation on Linux, BPF for syscall filtering, and a per-credential proxy for each kind of secret (GitHub creds, AWS keys) in a continuing game of whack-a-mole. Network policies inside Kubernetes are what most enterprises invest in, but the WebAssembly story can go further: service chaining with wasi-http and the component model means agents and tools can talk over wasi-http streams inside the same workload without ever dropping out to the network — solving one of the main complaints about MCP architectures.

Yordis pushed for going 100% WebAssembly — including network policies and CLI tools — and Bailey agreed that's the magic-wand outcome she's been pushing for. Frank Schaffa added that with copilot, cloud-code, and similar AI coding assistants, the historical "we're waiting for Java to compile to WebAssembly" objection is dissolving: developers don't care which language a function is built in if an LLM is generating it, so Rust-into-WebAssembly becomes the safest sandboxed target by default.

Multipath Routing, Named Interfaces, and Host Components​

Aditya brought a POC: having more than one component in a single workload export the wasi-http incoming handler, with the runtime gateway routing among them by path. Each component gets its own host-interface surface, so two components can export the same interface but mean different things. Bailey's response wove together several adjacent threads:

  • Host components — the long-term plan to replace many native plugins with WebAssembly host components, especially for client-style plugins (NATS, Redis clients) where sandboxing is desirable. Native plugins remain for cases that need direct hardware access (WebGPU).
  • Named interfaces — a wasmCloud-level mechanism for distinguishing "the NATS backend of wasi-keyvalue" from "the Redis backend" through a name on the interface, so a component can declare which one it expects.
  • The sandwich problem — a known reentrancy challenge in wasi-p2 (callback tables across nested invocations) that wasi-p3 partially resolves by pushing async coordination into the runtime, but reentrancy for sub-task invocations is still an open design problem that may need a 3.x point release.

Bailey also flagged that this whole bundle of features (multipath, named interfaces, host components) is the architectural shape of "I want every workload to talk to NATS and Redis at the same time, declaratively" — a goal that comes up repeatedly in user feedback.

Outgoing HTTP Handler Trait and Cron Job Provider​

Aditya also raised two smaller items. First, the outgoing HTTP handler trait: today the host HTTP handler is tightly coupled to Wasmtime's default request sender; for users who need custom TLS certs or other handler logic, that needs to be pluggable. With p3 merging, the design needs to be re-examined against the new code. Several relevant issues and PRs need to be linked into the tracking issue so they don't get lost. Second, a richer cron job provider: the current sleep/wake/fire pattern is too basic for production use; Aditya proposed aligning the new design with the typical Kubernetes CronJob shape so users don't have to implement scheduling from scratch each time.

Voting and Final Remarks​

The session closed with attendees placing dots on the items they want prioritized in Q2 (four dots each, honor system). Bailey will combine the vote results with Slack feedback over the week and draft the Q2 wasmCloud project roadmap by end of week. A screenshot of the final board was posted in the wasmCloud Slack for asynchronous comment.

WebAssembly News and Updates​

This week's roadmap session reflected several maturing themes in the broader WebAssembly ecosystem. WASI P3 is moving from "behind a flag" to "first-class" across multiple host runtimes and the JCO reference implementation is nearing completion. The WebAssembly component model is making sandboxed-MCP and agent workloads a credible deployment pattern, with wasi-http service chaining as the key primitive. Tooling like cosign and SIG store, plus GitHub's built-in attestation/provenance, are making cryptographic supply-chain verification a no-cost default for CNCF projects. And the Bytecode Alliance's work on big-Go and componentize-* tooling is closing the language-coverage gap that has historically slowed enterprise adoption.

What is wasmCloud?​

wasmCloud is a CNCF project for building and running WebAssembly components anywhere — cloud, edge, or Kubernetes. It uses the WebAssembly component model so business logic written in Rust, Go, TypeScript, Python, or C# can be composed with capability providers for HTTP, messaging, KV, secrets, and more. Applications run on the wasmCloud runtime through a Kubernetes operator or standalone, with built-in OpenTelemetry observability, declarative workload deploys, and signed-and-attested OCI artifact distribution via the SIG store / cosign integration discussed in this call.

Topic Deep Dive: Sandboxing MCP Workloads on WebAssembly​

The conversation around AI sandboxing surfaced one of the strongest current arguments for WebAssembly in platform engineering. Today's leading approaches to sandboxing agentic and MCP workloads rely on stacked Linux primitives: process namespacing, bubble wrap, BPF-based syscall filtering, and a growing ladder of per-credential proxies that gate access to each kind of secret. Each layer is correct in isolation, but together they're a whack-a-mole game — every new credential type means a new proxy, and the gaps are where incidents happen.

WebAssembly inverts the model. A Wasm component is a sandbox by default, with no syscalls and no ambient authority; capabilities are imported explicitly via WIT interfaces, which means an agent literally cannot make a network call unless its workload deploy spec grants it the wasi-sockets interface. With wasi-http and the component model, the agent can talk to its tools over service chaining — composed in the same workload, never leaving the host's memory — eliminating the network-layer attack surface that MCP architectures otherwise inherit. For platform engineers evaluating how to safely host AI workloads at scale, this combination of capability-based security and in-process composition is meaningfully different from the container-plus-syscall-filtering pattern that dominates today.

Who Should Watch This​

Platform engineers thinking about the Q2 wasmCloud direction should watch the whole planning session start at 04:33 and pay particular attention to the vulnerability scan and attestation discussion at 20:31. Engineers building MCP and AI workloads will want to jump to the sandboxing-on-WebAssembly conversation at 35:00 and Liam's note on phase two of sandboxmcp.ai. Runtime contributors focused on advanced routing should pick up at Aditya's multipath routing POC at 46:07 and the deep dive on named interfaces and host components that follows.

Up Next​

Bailey and the wasmCloud maintainers will combine the dot-voting results with Slack feedback over the week and publish the Q2 roadmap. Aditya will continue working on the outgoing HTTP handler trait, the multipath routing proposal, and the richer cron job provider. Jeremy will keep iterating on the gateway examples (envoy, Istio, Kubernetes Gateway API). The community is invited to file additional Q2 issues directly on the wasmCloud GitHub repo and post comments on the roadmap whiteboard or in Slack.

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 →