Skip to main content
← Back

Tracking Wasmtime 46, the Component Model implements Feature, and WASI P3 Concurrency

The June 17, 2026 wasmCloud community call digs into the runtime work landing on the back of WASI Preview 3 (WASI P3). Bailey Hayes walks through wasmCloud closely tracking Wasmtime 46 — the first release to ship the WASI 0.3.0 interfaces, with WASI P3 about to be enabled by default — and demos the component-model implements feature, using static bindings to multiplex a single Postgres plugin across two isolated database users with Testcontainers. Aditya Salunkhe presents his PR for WASI P3 HTTP streaming, resource linking across components, and cross-component async streams, which opens a deep discussion of core-instance concurrency under long-running streams and how elastic hosts and autoscaling can absorb the load.

Key Takeaways​

  • wasmCloud is closely tracking Wasmtime 46 — a handful of changes depend tightly on it, so the team set up a wasmtime-46 branch others can target PRs against; the Wasmtime 46 release was expected around June 20, and it is the first to ship the WASI 0.3.0 interfaces so you can build HTTP straight off the stable release
  • WASI P3 is being enabled by default — the port to Wasmtime 46 removes the separate WASI P3 Docker image and flips the feature on by default; full implements support waits on Wasmtime 47
  • Many Wasm proposals are about to be on by default in the next Wasmtime release — including GC and exception handling, which unblocks dropping in the Kotlin sample (GC-dependent) with no extra config
  • The component-model implements feature has merged upstream in the component-model spec and in wasm-tools, with the host bindgen resource support landing in Wasmtime; it is emoji-gated as a not-yet-stabilized feature
  • implements adds static bindings for guests and hosts so deployments can be verified at deploy time — e.g. "can this host talk to Postgres?" — instead of looking up a link by name at runtime, which matters for declarative Kubernetes-style production
  • A Postgres multiplexing demo uses a single Postgres plugin and Testcontainers with two database users (team A and team B), proving each gets an isolated connection bound by config through the backend-provider multiplexing model
  • Aditya's PR enables WASI P3 HTTP streaming, dynamic resource linking across components, and cross-component async streams with type safety; an upstream Wasmtime bug that blocked streaming was fixed, and the work targets the Wasmtime 46 branch
  • Long-running, high-concurrency streams stress core-instance limits — every concurrent component instance holds all of its core module instances (WASI adapter, StarlingMonkey for JS, etc.) in memory on one store; the answer discussed is elastic hosts with HPA-style autoscaling and right-sizing rather than a single-host fix

Chapters​

Meeting Notes​

Tracking Wasmtime 46 and WASI P3 by Default​

Bailey Hayes opened the call noting how much is happening now that WASI P3 rolled out the week before, so most of the agenda flowed from it. The first item: wasmCloud is closely tracking Wasmtime 46 because a handful of changes depend tightly on it. Bailey has a draft PR up, but the more important point is that the team created a wasmtime-46 branch so other contributors can target their PRs straight at it. That branch carries the partial implements work — full implements needs Wasmtime 47 — but its big hallmark is that Wasmtime 46 bundles the WASI 0.3.0 interfaces, so you can build HTTP directly off the stable release. The Wasmtime 46 release was expected around June 20, with a merge targeted for the week after.

A chunk of the branch work is simply making WASI P3 enabled by default: flipping the flag on, finishing the full port to Wasmtime 46, testing against it, and cleaning up artifacts that are no longer needed — for example the separate WASI P3 Docker image can go away once P3 is the default.

Enabling Wasm Proposals by Default and Kotlin​

Bailey called out that a good number of Wasm proposals are about to be enabled by default in the next Wasmtime release. Some of the ones she had wanted to target — garbage collection and exception handling — are coming for free that way. The payoff she was most excited about is Kotlin: the Kotlin samples require GC, and with GC on by default you can build off the Kotlin folks' sample and drop it straight in with no extra config. The broader goal is making it easier to add and test new Wasm proposals across the platform.

The implements Feature and Static Bindings​

Bailey then explained the implements feature of the component model and why wasmCloud has tracked it for a while. Today, linking works by setting a state flag naming a link, then resolving that name at runtime. With implements, you instead get static bindings for both guests and hosts that declare exactly who you are talking to — so wasmCloud can verify at deploy time whether the bindings exist. The canonical example: can this host talk to Postgres? If not, you find out at deploy time rather than at runtime, which is exactly the declarative guarantee you want for production Kubernetes deployments.

The feature has now merged upstream. The component-model spec is updated (the not-yet-stabilized feature is emoji-gated with a label tag in the spec), implements support is fully landed inside wasm-tools, and as of the day before the call it landed in Wasmtime too — the last remaining host-bindgen piece was supporting resources with implements. Bailey's remaining work is in wac, where a PR lets you round-trip, compose, and encode/decode component-linked graphs; it stays in draft until one last pass on the dependent wit-bindgen-wrpc (wRPC bindgen) piece is done.

Postgres Multiplexing Demo with Testcontainers​

To make implements concrete, Bailey showed an integration test using a single Postgres database image spun up with Testcontainers, so it is a real database. The test defines two users — team A and team B — writes rows, and validates that reads and writes do not share a connection: the two teams are isolated from each other, yet a single Postgres plugin serves both. Architecturally this works through multiplexing across backend providers: when a provider registers, it declares the backend type it serves; a workload deployment then names which backend it wants, and that name binds to the appropriate plugin backend. In the Postgres scenario, "I'm team A, I want team A's Postgres" is how the connection gets wired up from config. The remaining PRs depend on upstream releases (wit-bindgen-wrpc and the wac change), so they will sit in draft behind an implements opt-in flag until those land.

Aditya's PR: HTTP P3 Streaming, Resource Linking, and Cross-Component Streams​

Bailey handed off to Aditya Salunkhe, noting she had fixed one of the issues he hit. Aditya's PR set out to do three things — Bailey's work already crossed off the first. (1) WASI P3 HTTP streaming through the HTTP handler, for both gRPC and regular HTTP, which had been blocked by an upstream Wasmtime bug that is now resolved. (2) Resource linking across components: if component A creates a resource and passes it to another component, resource linking lets the second component call that resource's methods — done dynamically through the linker, since not everyone composes their components together for shared state. (3) Cross-component async stream support: upstream had intentionally opted async and stream values out of being lifted and lowered; this PR reintroduces them with type safety. After an error Aditya resolved in Wasmtime, the streams work. The PR targets the Wasmtime 46 branch, and Aditya planned to close the old PR and open a fresh one against that branch.

Bailey summarized the bigger picture: once components are composed, a composed component has multiple memories, and Wasmtime now links components so they can share resources and streams natively. A wasmCloud hallmark is letting multiple components in the same workload talk to each other — and with separate lifetimes, so a service can run long-lived while individual bursty components are instantiated only when routed to, rather than instantiating everything at once the way composing-into-one would.

Core-Instance Concurrency Under Long-Running Streams​

Aditya raised the harder problem with long-running components. When a component is invoked, its store stays alive and holds the core instances for the whole mapped-out graph of the workload. For long-running, high-concurrency cases — e.g. many clients hitting the same P3 streaming endpoint — you hit a core-instance maxing-out problem. He explored two mitigations: removing eager instantiation in favor of lazy instantiation (so at least in-flight requests are supported, though peak concurrency is unchanged), and Bailey's suggestion of ephemeral stores at safe call sites — suspension points like awaiting a future — where core instances can be handed to a temporary store and dropped when the task finishes. That added stability but did not solve the underlying cap on core instances drawn from the engine pool.

Bailey added important framing: a component does no compute on its own — it contains core module instances, and it is rare to have only one. There is usually a WASI adapter, sometimes a third; a JCO-built component carries a StarlingMonkey core module for the JavaScript runtime. Each core module instance takes memory, so a long-running stream holds the whole component and all its core modules resident. Lazy instantiation helps when workloads are not in the hot path of the stream, but in the worst case they all are, all on the same store (which is how the linker passes values around). The workload spec today caps component replicas/instances, not core instances directly.

Elastic Hosts, Autoscaling, and Right-Sizing​

The practical answer Bailey pointed to is the autoscaling work demoed the previous week. Rather than a hard host limit, elastic hosts plus the Horizontal Pod Autoscaler let a big burst scale out another host and spread workload deployment instances elastically — handling the load instead of dropping requests. In production you would pair a load balancer taking HTTP in with a metric server reflecting host-pod resource utilization to decide when to scale out. Bailey also floated a fun idea: inspect a component with wasm-tools to count its core module instances and estimate per-component resource cost — "napkin math," but enough to right-size a cluster for a target like 100,000 requests per second, which is far easier to surface for WebAssembly than for containers. The honest conclusion: on a single host, long-lived high-concurrency instances are challenging because they are instantiated for concurrency; the fix is to run N concurrently per host and scale across hosts, with some room for instance reuse.

Ephemeral Stores, Service-as-Router, and Roadmap​

Bailey previewed a follow-up: a separate pass on ephemeral stores for services, distinct from ephemeral stores for individual components, because the two should have different lifetimes — the rule of thumb is one store per lifetime. The goal is for a service to act as both ingress and egress and as the long-lived router: last week's multi-handler routing paved the way, so for streaming the service can route a request straight to the component that handles it without instantiating the whole graph — directly easing the concurrency pressure Aditya described. The latest release (2.40, out the night before) also tightened allowed-hosts checks: you can set allowed hosts per component and per workload, and passing nothing now means nothing is allowed and is blocked by default. On the roadmap, the config piece is nearly complete; the team is adding k6 to the benchmarking suite to cover macro benchmarks alongside the already-landed micro benchmarks, with host-operator coverage a priority. Bailey's philosophy: set aggressive goals, aim for a "C-plus" hit rate, and ratchet harder next quarter (which ends July 1).

KubeCon India and Community Engagement​

To wrap up, Aditya announced he will attend KubeCon India in Mumbai, giving a talk on Wasm at the edge, and invited attendees to connect on Slack to meet up. Bailey asked for a "KubeCon report" at a future call — especially the barometer on how well the audience understands WebAssembly — and encouraged spreading the word about wasmCloud and WebAssembly.

WebAssembly News and Updates​

This call captures the WebAssembly ecosystem turning the WASI Preview 3 launch into shipping runtime features. With WASI P3 rolled out, Wasmtime 46 becomes the first release to bundle the WASI 0.3.0 interfaces and is on track to enable P3 by default, while the next Wasmtime release flips on a batch of proposals (GC, exception handling) that unlock languages like Kotlin. Upstream in the Bytecode Alliance, the implements feature landed across the component-model spec, wasm-tools, and Wasmtime, bringing static, deploy-time-verifiable bindings to the component model. And cross-component async streams and resource linking through the linker push WASI P3 concurrency from spec into practice. 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, Kotlin, 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 built-in OpenTelemetry observability, HPA-aligned autoscaling, and native WASI P3 support. The result is the production substrate for WebAssembly on Kubernetes and the edge.

Topic Deep Dive: The Component Model implements Feature and Static Bindings​

The most consequential thread in this call is the implements feature of the Wasm component model and what static bindings unlock for wasmCloud. Historically, wasmCloud resolved links by name at runtime: a state flag said "talk to this link," and the system looked up the target and dispatched on that name. That is flexible but late — you only learn at runtime whether a host can actually satisfy a dependency. implements replaces that with static bindings baked into the binary: a component declares the interfaces it implements, the import names are threaded through the binary definition, and the host can answer at deploy time whether the required bindings exist — "can this host talk to Postgres?" — before anything runs in production.

For wasmCloud that closes the loop on a long-standing feature-tracking item, because the platform is built to be declarative: you describe a workload and expect the system to validate it the way Kubernetes validates a manifest. The Postgres multiplexing demo shows the runtime payoff — a single Postgres plugin serving two isolated users, with the backend-provider multiplexing model binding "team A's Postgres" by config. With the feature now merged across the component-model spec, wasm-tools, and Wasmtime (including resource support in the host bindgen), the remaining work is in wac and the wit-bindgen-wrpc layer so components can be composed, encoded, and round-tripped end-to-end inside wasmCloud — all behind an opt-in implements flag.

Who Should Watch This​

This call is especially valuable for component-model developers tracking the implements feature and static bindings — jump to the deep dive at 2:54 and the Postgres multiplexing demo at 7:30. Runtime and Wasmtime contributors working on WASI P3 streaming, resource linking, and cross-component async streams should watch Aditya's walkthrough at 9:53. And platform engineers and SREs sizing high-concurrency Wasm workloads will want the core-instance concurrency and elastic-host discussion at 17:32.

Up Next​

The next calls follow the Wasmtime 46 release (expected around June 20) and the WASI P3-by-default merge. Watch for Aditya's rebased PR targeting the wasmtime-46 branch, Bailey moving the implements work out of draft once the upstream wit-bindgen-wrpc and wac changes ship, a pass on ephemeral stores for services with the service acting as long-lived router, and k6 landing in the benchmarking suite for macro benchmarks. Aditya will also bring back a KubeCon India report. With the quarter ending July 1, expect a P3-oriented release and blog post with the new features landing alongside Wasmtime 46.

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 →