wasmCloud is a CNCF incubating platform for running WebAssembly components in the cloud. Think of it as a runtime that lets you write tiny, portable pieces of code in any language, deploy them anywhere, and have them talk to each other without the usual infrastructure headaches.
The problem it solves? Deployment complexity. Instead of shipping a monolithic container image with a full OS, a language runtime, and all your dependencies baked in, wasmCloud lets you deploy small, sandboxed WebAssembly modules that start in milliseconds, consume almost no memory, and can be composed like Lego bricks.
Who uses it? Platform engineers building distributed systems, edge computing teams who need tiny footprints, and developers who want to write polyglot microservices without managing a dozen different runtime environments.
Why care about v2.5.0 specifically? This is the release where wasmCloud turns on WASI Preview 3 (async) by default, adds cross-component streaming, and introduces multiplexed capability imports — meaning your components can now talk to multiple databases, message queues, and key-value stores simultaneously without glue code.
It is like upgrading from a walkie-talkie to a smartphone. Before, your components could send messages back and forth. Now they can stream data to each other in real time, juggle multiple database connections, and do it all asynchronously.
What’s New in wasmCloud v2.5.0
WASI Preview 3 Enabled by Default
This is the headline feature. WASI Preview 3 (wasip3) brings async I/O, HTTP/2 server capabilities, and component model streams to the default wasmCloud configuration. Previously you had to opt in. Now it is just there.
Why does this matter? Because async I/O is the difference between a component that handles one request at a time and one that handles thousands concurrently. It is the foundation everything else in this release builds on.
# wasip3 is now the default — no flags needed
wash new component --template http-hello-world
wash dev
# Your component now has async I/O out of the boxPR #5258 — feat: update to wasmtime 46 and enable wasip3 by default
Cross-Component Streams via Dynamic Linker
WebAssembly components are great at being isolated. But sometimes isolation is the problem — you want two components to stream data directly to each other without bouncing everything through a message broker. v2.5.0 adds a dynamic linker that creates streams between components at runtime.
This unlocks real pipeline architectures. Component A can produce a stream of data, Component B transforms it, and Component C writes the result to storage — all flowing through direct streams with no intermediate buffering.
// Components can now stream to each other
// via the dynamic linker
stream: inlet.send(chunk) -> outlet.recv()PR #5171 — feat(runtime): support wasip3 cross-component streams via dynamic linker
Multiplexed Capability Imports
This one sounds technical, but it solves a genuinely annoying problem. Before v2.5.0, if you wanted a component to talk to two different key-value stores — say, Redis for hot data and PostgreSQL for persistent state — you had to write glue code or pick one. Now you can declare multiple imports using the (implements ..) pattern and wasmCloud handles the multiplexing.
The same pattern works for PostgreSQL, messaging, and key-value interfaces. You declare what you need, and the runtime routes requests to the right provider.
// Multiple capabilities in one component
// wasi:keyvalue, wasmcloud:postgres, wasmcloud:messaging
// all multiplexed via (implements ..) imports
world multi-store-app {
import cache: interface wasi:keyvalue;
import db: interface wasmcloud:postgres;
import queue: interface wasmcloud:messaging;
}This is spread across three PRs that each add multiplexing for a different capability:
Composable Engine Config via WasmProposal
WebAssembly has a growing set of proposals — experimental features like garbage collection, threads, and exception handling that are not yet part of the core spec. wasmCloud v2.5.0 lets you toggle these proposals on and off via a composable configuration system exposed through the CLI and Helm chart.
This matters because it lets you opt into cutting-edge WASM features without waiting for them to ship in a stable wasmtime release. Want to run a component that needs GC? Turn it on. Running in a locked-down environment where you want only the safest subset? Turn everything off.
# Configure WASM proposals in your Helm values
engine:
proposals:
- gc
- threads
- exceptionsPR #5254 — feat(wash-runtime): make engine config composable via WasmProposal and PR #5276 — surface wasm proposals to cli and chart
Async KeyValue and Blob Store Interfaces
wasmCloud’s built-in keyvalue and blob store interfaces now have async versions. In the wasip3 world, everything is async, so these interfaces needed to catch up. Now they have.
If you are building components that do heavy I/O — caching, file operations, database lookups — this means your code no longer blocks the runtime while waiting for a response.
PR #5286 — feat(wit): add async wasmcloud:keyvalue and wasmcloud:blobstore
Breaking Change
One breaking change in this release: the bucket type in the keyvalue interface has been moved to a shared types interface. If you have components using the keyvalue capability, you will need to update your WIT declarations to reference the new shared types interface.
PR #5296 — feat(wit)!: share keyvalue bucket via a types interface
Security and Bug Fixes
This release fixes rust-sec-2026-0185, a vulnerability in quinn-proto rated CVSS 7.5 (HIGH). The vulnerability allows remote memory exhaustion — an attacker can trigger uncontrolled memory allocation by sending specially crafted QUIC packets. If you are running wasmCloud with QUIC-based networking (the default transport), you should upgrade.
PR #5277 — fix: rust-sec-2026-0185 quinn-proto
Other notable fixes include operator server-side apply improvements (PR #5282), Helm chart hardening for the runtime-operator chart (PR #5287), and proper cleanup of ephemeral tasks via AbortOnDrop (PR #5299).
The full v2.5.0 changelog includes 31 entries across features, fixes, CI improvements, and dependency updates.
wasmCloud v2.5.0 is the release where WebAssembly component model stops being experimental and starts being the default.
