wasmCloud makes experimental WASI P3 usable for Rust developers today
wasmCloud turned on experimental WASI P3 behind a single Cargo flag, and Rust HTTP components are already running with async handlers and streamed bodies.

wasmCloud quietly crossed a useful line for Rust WebAssembly developers: experimental WASI P3 support is already wired into the runtime behind the wasip3 Cargo feature, and Rust HTTP components are running end to end with it. The April 15 update made clear this was not a slide deck or a future promise. The example component runs on wash built with features wasip3, giving component authors a concrete path to try the next WASI model now, even though the support is still preview-quality.
That matters because WASI P3 changes the shape of component code in practice. wasmCloud said the new model rebases WASI on the Component Model’s native async primitives, with stream<T> and future<T> moving across component boundaries instead of forcing older outparam-style plumbing. For Rust developers, that means HTTP handlers become async fn and request bodies become stream<u8>. The payoff is cleaner ergonomics and a closer match to the async style Rust already uses in application code.
wasmCloud also framed P3 as its biggest technical milestone for Q2 2026, and the roadmap recap showed why the preview is significant beyond a single demo. The team said Rust is the happy path for current WASI P3 support, while TypeScript is moving through componentize-js. Blobstore and sockets are still under active work, with hardening still needed for long-lived streams, backpressure, and load. The roadmap called out issue #5028 for sockets and HTTP hardening, and issue #4951 for separate WasiCtx isolation across components in the same store, a prerequisite for correct per-component isolation when multiple P3 workloads run concurrently.
The broader ecosystem is moving in the same direction. wasmCloud cited the WASI P3 release candidate 0.3.0-rc-2026-03-15, and Wasmtime 43 already supports it. Rust’s nightly platform-support docs place wasm32-wasip3 as the next stage after wasm32-wasip2, note that it brings native async support that fits Rust’s ecosystem, and still mark it as Tier 3 and not yet tested in CI. Those docs also said, as of 2025-10-01, WASIp3 had not yet been approved by the WASI subgroup of the WebAssembly Community Group.
That is what makes wasmCloud’s April 15 update stand out. It did more than announce compatibility: it showed a working implementation that Rust developers can build against, break, and help shape while the standard and runtimes continue to harden around it.
Know something we missed? Have a correction or additional information?
Submit a Tip

