Skip to main content
← Back

A Year of wasmCloud 1.0: WASI, the Wasm Component Model & 2.0

The May 21, 2025 wasmCloud community call is a short, reflective one centered on the Wasm component model and the standards beneath it. Brooks Townsend walks through his new blog post celebrating a year of wasmCloud 1.0 — built on WASI 0.2, WIT, and the component model — and the deliberate bet on WebAssembly standards that drove community growth. Taylor Thomas and Liam Randall look ahead to wasmCloud 2.0, WASI 0.3, and a more pluggable host shaped by user design feedback. The call closes with an Issue of the Week and a Documentation of the Week highlighting a new capability-provider icon.

Key Takeaways​

  • wasmCloud 1.0 completed a full year with no major breaking changes — released April 2024, it made a deliberate bet on WASI 0.2, WIT, and the Wasm component model as a stable base, and that bet paid off in ecosystem support and community growth
  • Leaning on WebAssembly standards cut wasmCloud's code-generation burden, letting the project focus on application primitives instead of bespoke IDL and RPC interfaces
  • wasmCloud 2.0 is framed as a chance to simplify the host — making it pluggable and integratable so you run the smallest core and turn on capabilities (providers, plugins) as you need them
  • WASI 0.3 adoption is planned as soon as it lands later in 2025, unlocking native async interfaces for writing applications
  • The project will evolve past 1.0 — Taylor Thomas noted a 2.0, 3.0 and beyond are expected, with stabilizing WASI versions leading toward a WASI 1.0 and supported-version windows, and a culture of respecting non-terrible breaking changes between versions
  • User feedback is driving the redesign — Liam Randall is opening one-on-one design-feedback sessions with user groups before rolling proposals into the broader community
  • Issue of the Week is a beginner-friendly fix: wash app list/get hits a deprecated wadm endpoint and emits a deprecation warning — a quick switch from the list to the get operation
  • Documentation of the Week is a new capability-provider icon, contributed by Aditya and integrated by Eric, so architecture diagrams clearly distinguish components from providers — sparking a proposal for a shared community Excalidraw library

Chapters​

Meeting Notes​

A Year of wasmCloud 1.0: Standing on WebAssembly Standards​

Brooks Townsend opened the lone discussion item: his new blog post, One year of wasmCloud 1.0, marking a year since the April 2024 1.0 release. The headline accomplishment was staying on 1.0 — making no major breaking changes to the protocols and tools the project started with. That stability came from a deliberate bet: wasmCloud 1.0 was based on WASI 0.2 and the Wasm component model, standards that were stabilizing right as 1.0 shipped. By putting those at the heart of its IDL, its RPC interface support (wRPC), and its capability providers, wasmCloud shed bespoke FFI and code generation and focused on application primitives instead.

Brooks credited that foundation for the project's steady, near-linear growth in stars and contributions, and thanked the maintainers who came aboard during the 1.0 year — Joe Misaka, Mark Massoud, Masoud Baharlouie, Luke, and Aditya. Looking forward, he argued that leaning further on standards is a clear win — far less codegen effort behind standard interfaces — and that wasmCloud should adopt WASI 0.3 as quickly as possible once it lands later in the year to start writing applications with async interfaces.

From "Too Much, Too Little" to a Simpler, Pluggable Host​

Brooks was candid that even after 1.0 trimmed the project's scope to lean on WASI, the wasmCloud host still carries a lot: it maintains NATS connections, requires a NATS JetStream-enabled cluster, manages global link and configuration distribution across the lattice, and owns wasmCloud-specific concepts like JWT claims and component/provider signing. His call to the community: keep finding ways to simplify what wasmCloud does at the project level, focus on what it does well — running WebAssembly components and making it easy to add extension points via providers or plugins — and resist reinventing the world.

Taylor Thomas agreed, framing this as the next step of evolution. The host has at times done too little and at times too much; the lessons from both inform where 2.0 goes. He was clear that wasmCloud won't stay on 1.0 forever — a 2.0, 3.0 and beyond are expected — and as WASI matures (0.3, perhaps 0.4, toward an eventual WASI 1.0) the project will likely move to supported-version windows. The cultural commitment is that non-terrible, well-communicated breaking changes between versions are healthy.

User Feedback Driving the Redesign​

Liam Randall, with the project since its first line of code, emphasized that wasmCloud has been fearless about trying new things while staying responsive to user feedback. As wasmCloud has landed in high-profile production settings and powered community demos at KubeCon and Wasm I/O, a recurring lesson is that less is more. The design thinking now — echoed in recent blog posts — is to make the host more pluggable and integratable at every layer: refactor complexity out of the core so you can run the simplest possible piece and turn on the functionality you want from there. To shape that work, Liam is reaching out to user groups for one-on-one design-feedback sessions before rolling proposals into the broader community, with no fixed timeline yet but formal proposals likely close.

Issue and Documentation of the Week​

Issue of the Week — Brooks highlighted a small, beginner-friendly issue: wash uses model.list, which gives a deprecation warning on wadm. Running wash app list (or wash app get) hits an old wadm endpoint that emits a deprecation warning, even though it's functionally identical to the current get operation. The fix is a quick switch from calling list to get — a great first contribution for anyone wanting to get their hands dirty in the wash CLI. Thanks to Thomas for raising it in Slack.

Documentation of the Week — Brooks gave kudos to Aditya for a new capability-provider icon (integrated into the docs by Eric). The WebAssembly logo clearly marks a component, but providers had no equally recognizable symbol, leaving architecture diagrams relying on generic shapes. The new icon makes "component talking to component" versus "component talking to provider" instantly readable — a small touch that makes wasmCloud's Platform Overview and quickstart diagrams much clearer. Taylor Thomas proposed going further: collect all of these Excalidraw resources into a shared community Excalidraw library so anyone updating docs — or building a talk — can reuse official wasmCloud and Wasm components. Brooks agreed to open an issue for it in the wasmcloud.com repo.

WebAssembly News and Updates​

This call is fundamentally a status check on wasmCloud's bet on WebAssembly standards. A year of wasmCloud 1.0 shows what it looks like to build a production platform on the Wasm component model and WASI 0.2 rather than a bespoke stack: less code generation, more ecosystem leverage, and a stable base that survived a full release year without breaking changes. The next chapter is WASI 0.3, which brings native async, streams, and futures — wasmCloud plans to adopt it as soon as it stabilizes. For the broader trajectory of these standards, follow the Bytecode Alliance and the WASI and component model subgroups.

What is wasmCloud?​

wasmCloud is a CNCF project that lets you build applications using WebAssembly components and deploy them anywhere — cloud, edge, or Kubernetes clusters. It uses the WebAssembly component model to let you write business logic in any supported language (Rust, Go, Python, TypeScript, C#, and more) while the platform handles capabilities like HTTP, messaging, and key-value storage through a pluggable provider architecture. wasmCloud's reference host is built on Wasmtime and distributes both components and providers as OCI artifacts. With built-in OpenTelemetry observability and Kubernetes integration, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure.

Topic Deep Dive: The Wasm Component Model​

Everything in this call traces back to the Wasm component model. The reason wasmCloud 1.0 could hold a stable line for a full year is that it offloaded its hardest problems — typed interfaces, language interop, and a portable binary target — to the component model and WASI 0.2 instead of maintaining its own IDL, RPC, and code generation. The component model defines how isolated components compose through typed WIT interfaces without trusting each other's internals, which is exactly what lets wasmCloud run business logic written in any language and connect it to capability providers over wRPC. The forward-looking thread — adopting WASI 0.3 and refactoring the host to be pluggable — is really about pushing more of the platform onto these standard, component-model-aware interfaces so the wasmCloud core can shrink to "run components, plug in capabilities." wasmCloud's bet is that the component model becomes the universal contract across languages, hosts, and the Kubernetes-native tooling that schedules them. To learn the fundamentals, start with the WebAssembly components overview.

Who Should Watch This​

This call is especially valuable for platform teams and architects weighing whether to build on bespoke abstractions or standard WebAssembly interfaces (start with Brooks's year-of-1.0 retrospective at 5:08), wasmCloud users with production feedback who want a say in the 2.0 host redesign (Liam's design-feedback invitation at 13:02), and first-time contributors looking for a friendly entry point into the wash CLI (the Issue of the Week at 15:48).

Up Next​

The next community calls lead toward the wasmCloud 2.0 design conversation and WASI 0.3 adoption. Watch for one-on-one user design-feedback sessions to roll up into public proposals for a more pluggable host, a community Excalidraw library issue in the wasmcloud.com repo, and the beginner-friendly wash/wadm deprecation fix getting picked up by a first-time contributor.

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 →