Skip to main content
← Back

New People Pages, Multi-Backend Named Interfaces, and WASI Preview 3 on main

The June 24, 2026 wasmCloud community call is a short one with a couple of focused updates. Bailey Hayes opens with the new maintainer people pages and a quickstart fix from Eric Gregory, then walks through a packed status update on main: Wasmtime 46 brings the WASI 0.3.0 APIs with WASI Preview 3 enabled by default — no feature flag needed — alongside a new implements feature flag and a PR that lets a single named interface (like a key-value store) be backed by multiple plugins at once, for example Redis and NATS. The call wraps with Aditya Salunkhe's work on component-to-component linking using Wasm component model P3 types and an announcement of the July 8 roadmap planning session.

Key Takeaways​

  • New maintainer people pages are live — discoverable profile pages for active maintainers who have spoken at a community call or written a blog post, with social links, blog bylines, and the calls they appeared in; reachable from blog author bylines and the speaker chips and transcripts on community-call pages, with feedback welcome on the wasmCloud Slack
  • A quickstart end-state example landed in the examples repo — after hitting regressions in the create-HTTP-component → add-persistent-storage flow, the team added a tested reference for exactly where the quickstart should land you, so readers have an end-state to check against and CI can guard the quickstart from breaking
  • main now builds on Wasmtime 46 with WASI Preview 3 by default — the WASI 0.3.0 APIs are enabled out of the box, so there is no feature flag to turn on WASI P3; you just get it when you bring wasmCloud in
  • A new implements feature flag mirrors the Wasmtime proposal — wasmCloud now surfaces the same component model implements flag Wasmtime exposes, and the team is actively building on it
  • Multi-backend named interfaces let one interface use several plugins at once — a guest can import a single key-value store and be wired statically to two named bindings (Team A and Team B) backed by, say, Redis and NATS; the host side gains multiplexed plugins keyed by backend name, and the pattern will extend to blob store, Postgres, and every other host plugin
  • Host components build on implements — separate per-component workload stores plus a bridge for spawning concurrent tasks, sharing much of the infrastructure Aditya is adding for component-to-component linking; the host component is largely a specialization of a service that runs for all workloads on the host
  • An SQLx example is up so you are not blocked on upstream — Bailey filed a PR fixing SQLx's broken main and an example showing MySQL/Postgres usage with connection pooling, and will mirror it on the wasmCloud side so the team is not gated on the upstream merge
  • Roadmap planning happens July 8 — pushed past the US holiday week; add comments or file issues for big-ticket items (distributed caching for WebAssembly compilation and caching cwasm was called out as one) to shape wasmCloud releases for the next quarter

Chapters​

Meeting Notes​

New Maintainer People Pages​

Bailey Hayes opened the call and handed straight to Eric Gregory, who had two items. The first is part of an ongoing effort to improve discoverability across the wasmCloud documentation site: new people pages for maintainers. The pages are scoped to active maintainers who have either participated in a community call or written a blog post — Eric used Bailey's page as the live example. Each page gathers social information, links to that person's blog posts, links to the community calls where they appeared, and other relevant places they show up across the WebAssembly ecosystem.

The pages are wired into the rest of the site rather than standing alone. They are linked from the author byline on a blog post, and from the speaker chips shown alongside each community-call summary page (and from the speaker labels in the transcripts), so a reader can click a speaker and follow through to that maintainer's page. Eric invited anyone who is an active maintainer to review their own page and send comments or feedback on the wasmCloud Slack.

A Quickstart End-State Example​

The second item addressed a recurring pain point: the team had hit a couple of minor and a couple of more significant regressions in the quickstart — specifically the flow from creating a simple HTTP component to one that adds persistent storage. While building resilience against that, they realized they were missing an in-state example: an example that implements persistent storage exactly the way you arrive at it over the course of the quickstart. That example now lives in the wasmCloud examples repo.

The example does double duty. Readers and users get a concrete reference for what they should be winding up with at the end of the quickstart, and the project gets something to test against so CI can catch when a change is about to throw the quickstart out of whack. Bailey confirmed the docs page was updated to point at it.

What's Happening on main: Wasmtime 46 and WASI Preview 3 by Default​

Bailey then gave the status update on main, and there was a lot. The big landing is that wasmCloud is now building with Wasmtime 46, which carries the latest WASI 0.3.0 APIs with WASI Preview 3 enabled by default. There is no feature flag to turn P3 on — in fact there is no flag at all; you simply get it as part of wasmCloud when you pull it in.

On top of that, a new implements feature flag has landed on main. wasmCloud mirrors the same flag Wasmtime surfaces for this component model proposal, and it is the foundation the team is actively building on.

Multi-Backend Named Interfaces​

The headline PR that builds on implements lets a single named interface be backed by multiple plugins at once. In Bailey's example, a guest component declares that it wants to talk to both Redis and NATS as its key-value store. When it imports that interface, the generated bindings carry two distinct named bindings — Team A and Team B in the demo — threaded statically through both the component side and the host side.

On the host side, this surfaces as a new kind of multiplexed plugin. For the key-value interface, the multiplexed plugin is keyed by backend name: NATS maps to the NATS backend, Redis to the Redis backend, and so on. Bailey exercised key-value end to end as part of this PR and expects it to land in the release the following Tuesday; the remaining work is extending the same pattern to blob store, Postgres, and every other host plugin that needs implements backing — work she described as roughly 70% done, with the remaining 30% largely mechanical.

Component-to-Component Linking and Host Components​

Aditya Salunkhe joined and Bailey called out his change: component-to-component communication inside the same workload. Now that P3 is part of main, the team is building on those types so that linking between components in a workload is ergonomic — components can talk to each other using P3 types like streams, futures, and passing around the handle for a resource. Aditya noted it had been covered well in prior meetings and in the PR description, with little to add.

Bailey is working on a closely related piece — components in the same workload talking to a service — so the two efforts share infrastructure and will be merged together. That feeds directly into host components, which build on implements: the architecture gives each component its own workload store per workload, with a bridge for spawning concurrent tasks that manages and threads everything through, so a host component can handle the separate tasks arriving from workload components. In many ways the host component is just a specialization of a service that runs for all workloads on the host.

On the project board, most of the remaining items are close. A couple are blocked: one is patching implements onto Wasmtime 46 using a patch already merged to Wasmtime's main (so the team can build now rather than wait a month for Wasmtime 47); another needs intricate work that Bailey wants to detail on the P3 concurrency side first. Multi-backend is the 70%-there PR above; once those land, the rest are more straightforward.

The SQLx Example​

Bailey also flagged an SQLx PR. SQLx's main branch had been broken for a while, so she put up a PR upstream to fix it — her own change can't merge until that lands, but it works. To unblock users in the meantime, she wrote an example showing exactly how to use SQLx from a component, covering both MySQL and Postgres with connection pooling enabled, with no modifications to SQLx required. It is a reference humans (or LLMs) can point at to write working database code. She plans to mirror it on the wasmCloud side so the team is not blocked waiting on the upstream merge.

July 8 Roadmap Planning Session​

The next big thing is a roadmap planning session on July 8. Bailey posted a discussion thread right before the call so people had fair warning and could weigh in. The session was scheduled the week after the end of the quarter to avoid the US holiday week, when many people are on vacation. Anyone with big-ticket items — "big rocks" to plan for over the next quarter — is encouraged to add comments or file issues describing what they want to build. Bailey seeded the list with items top of mind for her and will keep expanding it through July 8. One example she called out as worth scoping: distributed caching for WebAssembly compilation and caching cwasm — a larger feature that was out of scope this quarter but, she argued, belongs on the next one.

WebAssembly News and Updates​

This call is a snapshot of WASI Preview 3 moving from "about to launch" to simply being the default. With Wasmtime 46 carrying the WASI 0.3.0 APIs and WASI P3 on by default, the Bytecode Alliance component model's async story — streams, futures, and resource handles — is now available to wasmCloud workloads with no flags to flip. The implements proposal layered on top opens the door to multi-backend named interfaces, a genuinely new capability for component authors who want to address several backends behind one typed import. For ongoing webassembly news, follow the Bytecode Alliance and the wasmCloud blog.

What is wasmCloud?​

wasmCloud is a CNCF project for building applications out of WebAssembly components and deploying them across cloud, edge, and Kubernetes clusters. The Wasm component model lets you write business logic in Rust, Go, Python, TypeScript, C#, Java, and more — while the platform handles capabilities like HTTP, messaging, key-value storage, and observability through a pluggable host plugin architecture backed by Wasmtime. wash is the developer shell — build, run, deploy, debug — and the runtime operator schedules Wasm workloads on Kubernetes the same way you schedule container workloads, with native WASI P3 support now on by default. The result is the production substrate for WebAssembly on Kubernetes and the edge.

Topic Deep Dive: Multi-Backend Named Interfaces​

The most technically interesting change in this call is the multi-backend named interface, and it falls out naturally from the Wasm component model's implements proposal. In the classic model, a guest component imports a capability interface — a key-value store, say — and the host wires that single import to a single backend at link time. The implements flag changes the shape of the binding so that one logical interface can carry multiple named bindings, each resolvable to a different backend, all type-checked statically in the bindings generated for both the component and the host.

In the demo, a guest declares it wants a key-value store backed by both Redis and NATS, producing two bindings — Team A and Team B — that thread through to the host. There, the new multiplexed host plugin is keyed by backend name, so a request tagged for the NATS binding lands on the NATS backend and one tagged for Redis lands on Redis. Bailey exercised this for key-value as the proof of concept, with blob store, Postgres, and the rest of the plugin surface to follow. For component authors this means a single typed import can fan out across heterogeneous backends — a different distribution and consistency story per binding — without changing the component's interface contract.

Who Should Watch This​

This short call is most useful for three audiences. Maintainers and contributors who blog or speak at the calls should watch Eric's walkthrough of the new people pages (0:46) and review their own profile. Component authors and platform engineers tracking the component model should jump to the multi-backend named-interface demo and the implements feature flag (3:59). And anyone building database-backed components will want the SQLx connection-pooling example and the host-component roadmap (8:42).

Up Next​

The immediate calendar item is the July 8 roadmap planning session, scheduled past the US holiday week to set wasmCloud's direction for the next quarter — add your big rocks to the discussion thread before then. On the engineering side, expect the multi-backend named-interface PR to land in the next Tuesday release and the pattern to extend from key-value to blob store and Postgres; host components and Aditya's component-to-component P3 linking to converge on shared infrastructure; and the SQLx example to be mirrored on the wasmCloud side so it is usable without waiting on the upstream merge.

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 →