Skip to main content
← Back

WASI P3 Roadmap, wasmCloud Secrets Plugin & NATS Messaging Interface

Watch on YouTube ↗

The April 15, 2026 wasmCloud community call centered on the finalized Q2 roadmap, with full WASI P3 support as the headline goal for the quarter. The team walked through HTTP routing changes using the component model's External ID spec, introduced a new wasmCloud secrets plugin with typed declarative resource management, and discussed a proposed NATS-specific WIT interface for durable messaging beyond the generic event bus.

Key Takeaways​

  • Full WASI P3 support targeted by end of Q2 — wasmCloud already has P3 behind a feature flag with working async HTTP examples, and the goal is to make it the default before July
  • Component interposition showcases P3 composition — Elizabeth Gilbert's component interposition project demonstrates ordered middleware composition using WASI HTTP, with a shell script to get started building for P3
  • HTTP routing prefers spec-level External ID over host magic — Bailey Hayes is pushing the upstream External ID spec changes to enable component-named routing, with a three-week target before falling back to host-side routing
  • wasmCloud secrets plugin adds typed, declarative secret management — The new plugin uses a get/reveal pattern where secrets are fetched synchronously at deploy time, enabling the host to fail components that can't access required secrets before they run
  • wasm-to-env extracts required environment variables from Wasm binaries — Aditya demonstrated a tool using Walrus that statically analyzes Wasm files to find WASI CLI environment and WASI config store calls and returns the specific variables needed
  • New TypeScript docs cover file systems and configuration — Eric Gregory published developer-side documentation for consuming file system resources and configuration data in TypeScript components, with companion operator manual pages
  • NATS-specific WIT interface proposed for durable messaging — Aditya proposed a NATS-native WIT definition to support JetStream message replay and durability features that the generic wasmCloud messaging interface can't express
  • Multiple host modes support edge and IoT deployments — wash dev, wash host, and wash lit each serve different deployment scenarios, with wash lit closest to flat-file edge deployments and a hub-spoke architecture recommended for DDIL environments

Chapters​

Meeting Notes​

Q2 Roadmap Review and WASI P3 Progress​

Bailey Hayes opened the call by reviewing the finalized Q2 roadmap, which was built from a collaborative dot-voting session the previous week. The roadmap is tracked as a GitHub project under wasmCloud, and the overarching goal is full WASI P3 support by the end of the quarter. wasmCloud already has P3 behind a feature flag in the latest release, with working async HTTP examples. Bailey noted that the plan is to make P3 the default flag by end of quarter while keeping the option to disable it for teams still running P2-only pipelines.

On the standards side, Bailey shared that the W3C WASI subgroup is close to advancing the P3 spec, pending a complete second reference implementation with 100% test coverage. Victor Adithya, a wasmCloud maintainer, is driving that implementation and is estimated to be less than a month out. Bailey also highlighted Elizabeth Gilbert's component interposition project — a CMU PhD student's work demonstrating the power of WASI P3 composition, specifically focusing on the WASI HTTP middleware interface with ordered middleware composition (e.g., ensuring authentication middleware always runs first). The project includes a shell script that gets a P3 build environment running from scratch.

Eric Gregory, who sits on the Bytecode Alliance SIG-Docs group, shared that he is leading a refresh of wasi.dev and the component model book to incorporate WASI P3 changes, with work ongoing over the next couple of weeks.

HTTP Routing and Multiple Backend Instances​

Aditya raised questions about the approach to multiple backend instances. The current proposal uses named interfaces to override backend implementations, but for multi-path HTTP routing the logic is inverted — the runtime decides which components to invoke based on path matching defined in the YAML manifest. Bailey explained that spec-level External ID support would enable both component-to-component calls (where one component invokes another by name) and host-side routing from a single mechanism, and would also unlock support for composed components.

Bailey noted that companies including Akamai, Microsoft, and Fastly have all expressed interest in the External ID design, making standardization the preferred path. She committed to taking a swing at implementing the spec changes within three weeks, with a fallback to host-side routing if the timeline slips. Jeremy had already landed a more Kubernetes-native routing change that was merged and released.

wasmCloud Secrets Plugin​

Aditya asked about the wasmCloud secrets plugin and whether it would support use cases beyond Kubernetes secrets. Bailey walked through the architecture in detail: today, the default host plugin talks to the Kubernetes external secrets operator and plumbs values through to WASI CLI environment variables, with an optional WASI config blob. The secrets plugin is being reintroduced from v1 (it was descoped from the initial v2 MVP) and adds a typed get/reveal pattern.

The key design decision is that secret fetching is synchronous at deploy time — when a component is about to run inside a workload, the host fetches all required secrets first. If fetching fails (e.g., the host lacks permission to connect to Vault), the component doesn't get scheduled. This preserves the declarative resource model where the workload deployment spec explicitly lists every config value and secret. Bailey emphasized that the reveal step isn't primarily a security feature — it's an expressivity tool that lets you trace exactly which component instance in a composed graph actually consumed a secret, enabling richer observability and auditing. The interface also supports pluggable backends, so teams can talk directly to HashiCorp Vault or any other secret store by writing a host plugin.

wasm-to-env and Component Tooling Ecosystem​

Aditya demonstrated wasm-to-env, a tool he built that takes a Wasm binary and uses Walrus to statically analyze deterministic code paths, finding WASI CLI environment and WASI config store get calls to extract the specific environment variables a component needs. Bailey called this exactly the kind of ecosystem tooling she wanted to see, and connected it to related projects: Worm (a spiritual successor to Walrus maintained by Elizabeth Gilbert), Splicer (with its adapter component concept), and wasi-virt (which virtualizes WASI interfaces for declarative deployments). Bailey noted that wasi-virt hit composability constraints in P2 that forced a monolithic virtualization component, but P3 will enable modular per-interface virtualization components.

New TypeScript Documentation​

Eric Gregory walked through newly published documentation in the language support section under TypeScript, specifically covering file system and configuration consumption from the component authorship side. Previously, the operator manual had instructions on providing file system resources via Kubernetes volumes, but developers lacked guidance on consuming them. The new file system page starts from the HTTP service hello template and adds file system functionality step by step. A companion template with file system support was also added to the TypeScript examples repository. The configuration page follows a similar pattern for consuming config data provided through wasmCloud's various configuration mechanisms.

NATS Messaging and Alternative Protocols​

Aditya proposed creating a NATS-specific WIT interface to support JetStream features like message replay and durability that the generic wasmCloud messaging interface can't express. Bailey strongly supported the idea, noting that jumping between event buses is rare in practice and that NATS's capabilities far exceed what a common-denominator interface can offer. She encouraged Aditya to file a GitHub issue and add it to the roadmap, noting the benefit for the wash dev local development loop as well.

Brian Boynton mentioned his work on wRPC over WebSocket for his registry project. Bailey walked through the trade-offs: wasmCloud v1 was architecturally dependent on wRPC, and the team learned hard lessons about making network calls obvious rather than magical. She recommended considering gRPC (which can upgrade to WebSocket) or direct WASI HTTP with HTTP/3 support, noting that Cloudflare has done significant work on HTTP/3 in the Rust ecosystem.

Edge Deployments and Host Modes​

Liam Randall asked about flat-file deployment scenarios for DDIL (Denied, Disrupted, Intermittent, Limited) edge environments. Bailey explained that wasmCloud already supports multiple host modes: wash dev for local development, wash host for standard deployment, and wash lit for lightweight embedded scenarios. For most IoT edge use cases, she recommended a hub-spoke architecture where a Kubernetes cluster serves as the hub and edge hosts communicate over NATS, with NATS acting as the connectivity agent. Eric pointed out that existing documentation in the runtime section covers wash lit and custom host building. Building a custom host is straightforward — it just requires embedding the wash-runtime crate with a different start mode.

WebAssembly News and Updates​

This week's call highlighted the rapid progress toward WASI P3 standardization, with the W3C WASI subgroup nearing the launch of phase three pending a second complete reference implementation. The component interposition project from CMU demonstrates that the component model is enabling sophisticated composition patterns like ordered middleware chains. The broader ecosystem tooling — Worm, Splicer, wasi-virt, and community tools like wasm-to-env — shows a maturing landscape for building, analyzing, and deploying WebAssembly components. The Bytecode Alliance continues driving standards work across the component model book and wasi.dev documentation refresh.

What is wasmCloud?​

wasmCloud is a CNCF project for building and running WebAssembly applications across cloud, edge, and everything in between. It uses the WebAssembly component model to let developers write portable, composable business logic in any supported language — Rust, Go, TypeScript, Python, C# — while the platform handles deployment, networking, scaling, and observability through OpenTelemetry. Applications are declared as workload deployment specs and can run on Kubernetes or standalone, with built-in support for secrets, configuration, and capability-based security.

Topic Deep Dive: Declarative Secrets and the Wasm Component Model's Resource Advantage​

The wasmCloud secrets plugin discussion revealed a design philosophy that goes beyond simple secret injection. The get/reveal pattern leverages the wasm component model's resource types to create a typed, traceable secret lifecycle that traditional environment variable injection can't match. When a composed component graph has multiple sub-components — say, one talking to DynamoDB and another to PostgreSQL — the top-level component fetches secrets via get and passes only the relevant secret reference to each sub-component. The sub-component calls reveal to actually access the value, and that call can be traced, audited, and logged with full knowledge of which component instance used which secret.

This matters because it preserves declarative resource management — one of wasmCloud's core architectural properties. Unlike WASI CLI environment variables, where a component's requirements are opaque until runtime, the secrets interface makes dependencies explicit at deploy time. Combined with tools like Aditya's wasm-to-env (which can statically extract environment variable requirements from Wasm binaries) and the future External ID spec for per-secret naming, wasmCloud is building toward a world where the entire resource graph — compute, config, and secrets — is declaratively specified and verifiable before a single component instance starts.

Who Should Watch This​

Platform engineers evaluating secret management strategies for component-based architectures should jump to the secrets plugin deep dive at 17:56 — the get/reveal pattern and declarative deploy-time fetching are directly applicable to Vault and external secrets operator workflows. Developers getting started with WASI P3 should check out the component interposition walkthrough at 07:09 for a hands-on starting point. And anyone building on NATS with wasmCloud will want to hear the NATS-specific WIT interface discussion at 47:06.

Up Next​

Aditya committed to filing a GitHub issue proposing a NATS-specific WIT interface for durable messaging and JetStream support, aiming to add it to the Q2 roadmap. Bailey plans to take her swing at the External ID spec changes for component-named HTTP routing within the next week, with host-side routing as the fallback. Eric will continue the wasi.dev and component model book refresh over the next couple of weeks. The HTTP client plugin work will proceed using the PWD builder pattern to support the outgoing handler.

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 →

Recording​