Skip to main content
← Back

wasmCloud Q4 Roadmap: Python, Workload Identity, Wasm Components

The September 30, 2026 wasmCloud community call was the last of Q3 and a preview of the Q4 roadmap before next week's collaborative planning session. Bailey Hayes walked through the draft in discussion #5619. It has four themes: the wasm component model ecosystem (a Python SDK is the likely next language), performance (a customizable precompiled-component cache, exploded components that deduplicate language runtimes, and k6 load tests), integration (S3 for WASI Blobstore and declarative storage grants), and workload identity with credential brokering, which she called the quarter's biggest rock. Jeremy Fleitz showed a k6 load-test harness that has already found a local-routing bug.

Key Takeaways​

  • wasmCloud 2.10.2 was due the same day. It is a patch release with a few bug fixes, cut before bigger features land. The 2.10 release blog is the readable summary of 2.10: same-host routing, outbound workload identity, spec-conformant OpenTelemetry, and Wasmtime 48, which can run components built with WASI SDK 34 cooperative threads
  • Q4 planning is collaborative, and async input counts. The roadmap lives in discussion #5619 and the planning call is October 7. Bailey asked for comments on three questions: what wasmCloud should prioritize that it doesn't today, which rough edge you've normalized, and what would get your organization to production
  • Q3 delivered a lot. Host component plugins, a pluggable model for service triggers, wasmcloud:messaging@0.3.0 async messaging on P3, a P3-native NATS interface, multi-backend component binding through implements, warm and elastic instance pools, outbound mTLS identity, and two sprints of reliability and security hardening
  • A Python SDK is the probable Q4 language. Go got the focus last quarter, and the wasmCloud Go SDK now builds on componentize-go with easy access to WASI P3. Python is the language Bailey gets asked about most. Cooperative threading in Wasmtime 48 makes it possible, and she thinks something stable is achievable by December. A C/C++ SDK is on the table for anyone who needs it, and Rust gets a refresh onto the latest wstd with P3 support
  • Compiling to WASI is often just flags now. Bailey's aws-lc-rs PR #1239 adds wasm32-wasip2 and wasm32-wasip3 targets using WASI SDK 34, as a recipe others (and their LLMs) can follow. Aditya Salunkhe has gotten Lapin (AMQP), Sentry, and SQLx compiling. "Are we componentized yet?" will turn into a per-language compatibility matrix
  • Exploded components would deduplicate runtimes. If each component in an OCI image gets its own layer, identical CPython or StarlingMonkey bytes can be shared at the registry and in the host's precompiled cache. That cache is getting pluggable so embedders can bring a distributed one. Further out, Bailey wants streamable data segments so components can carry assets, prompts, and models and load them lazily
  • k6 load tests found a real bug. Jeremy Fleitz's PR #5630 adds a k6 harness with HTTP, fan-out, and same-host chain-call scenarios that runs in CI, on a laptop, or against your own cluster. Turning on local routing under load exposed an issue, and the PR waits on the fix
  • Integration: S3 first, then finer-grained grants. Aditya's bucket-scoped operations PR to Apache's object_store is up for review upstream, with S3 to follow in wasmCloud. Bailey wants NATS-style declarative capability grants (bucket prefixes, create permissions) for Blob Store and Key Value too, and new integrations as sandboxed host component plugins in awesome-wasmcloud
  • Workload identity and credential brokering are the biggest rock. The goal goes beyond mTLS: the host brokers credentials so agents and agent harnesses can run safely in a multi-tenant WebAssembly sandbox. Bailey is distilling a long design exploration into a human-written RFC, with stacked drafts for the first phases expected to start landing next week

Chapters​

Meeting Notes​

wasmCloud 2.10.2 and the 2.10 Release Blog​

Bailey Hayes opened the last community call of Q3 by announcing wasmCloud 2.10.2. It is a patch release on top of 2.10 with a couple of bug fixes, and she expected to cut it later that day so the fixes would ship before bigger features land. Last week's call walked through the raw GitHub release notes. Eric Gregory has since published a more readable version, wasmCloud 2.10: Same-host routing, outbound identity, and OpenTelemetry that follows the spec, and that post is the place to compare 2.9 and 2.10.

Bailey picked out three items. Same-host routing is an opt-in performance path for HTTP calls between workloads on the same host. Host outbound identity presents mTLS client certificates. The rest is OpenTelemetry work. The upgrade to Wasmtime 48 is one of the first Wasmtime releases that can run cooperative threads matching what WASI SDK 34 produces, so anyone experimenting with threads can now do it on wasmCloud. Bailey asked them to report what they find.

The Q4 Roadmap, and What Q3 Delivered​

The Q4 roadmap is in discussion #5619 on the wasmCloud repo, and the collaborative planning session is next week's call (October 7) at the usual time. Bailey usually builds the roadmap live in an Excalidraw. This time she did the pre-work in the discussion and asked for comments ahead of the call, since async input carries the same weight as live participation. The discussion poses three questions: what wasmCloud should prioritize in the next three months that it doesn't today, what rough edge you keep hitting but have normalized, and what would make your organization more likely to put wasmCloud into production.

Since July, wasmCloud shipped five releases, 2.6 through 2.10. Bailey singled out host component plugins. In her view they make wasmCloud the best WebAssembly runtime available, because no other runtime lets you extend the host's capabilities with components. She also listed a pluggable framework for service triggers, async messaging on WASI P3 (wasmcloud:messaging@0.3.0), a P3-native NATS plugin and interface, and multi-backend binding. With multi-backend binding, several components in one workload can share an imported or exported API and the host multiplexes between them. One component can also import the same interface twice, say a Postgres users database and a separate accounts database with different configuration and credentials. On performance, the team added concurrency and warm, elastic instance pools. Two full sprints went to reliability and security hardening, which greatly expanded the policy knobs available in wasmCloud.

Component Ecosystem: Python, C/C++, and Rust​

Bailey organizes the roadmap into themes, because contributors tend to work in one layer. The component ecosystem theme recurs every quarter, and she pointed new contributors to it: the work is user-facing and pays off immediately. Last quarter focused on Go. wasmCloud's Go SDK now builds on componentize-go, which gives users easy access to WASI P3. Bailey thinks this quarter could deliver a Python SDK. Python is the language she is asked about most, largely because of AI. Cooperative threading in Wasmtime 48 makes it feasible. It will be brittle at first and need feature flags, which Bailey described with the Southern saying "hold your mouth right," but she expects something stable by December.

A C/C++ SDK is also possible. Cooperative threading gives near-full pthread compatibility, and Bailey cited 100% compatibility with a POSIX threads test suite. She won't commit her own time to it, but would help anyone who needs it drive it through. Within a couple of weeks she also expects to refresh the Rust ecosystem onto the latest wstd with WASI P3 support.

Plenty of ecosystem work happens outside wasmCloud's own roadmap. Bailey's example was aws-lc-rs PR #1239, which adds wasm32-wasip2 and wasm32-wasip3 targets for a widely used crypto library behind Rust TLS stacks. The PR cross-builds in CI with WASI SDK 34 and tests under Wasmtime 48. It was approved and waiting on one last merge. The hard part was configuring a Rust project with C underneath to build against WASI SDK, so the PR's real value is a recipe that people and their agents can reuse. Improvements in WASI SDK and wasi-libc made that possible, and wasm32-wasip3 is now a nightly Rust target that should become stable soon.

Aditya Salunkhe described what he has compiled to WASI: Lapin (the AMQP client), Sentry, and SQLx. Bailey later simplified his SQLx work using the Tokio WASI P2 support. Her point was that this used to mean changing dozens of dependencies and much of the code, and now it is usually a feature flag. Once a repo documents the flag, a downstream LLM can apply it. She asked contributors to announce each newly compiling library on the community call.

All of this feeds an "Are we componentized yet?" initiative that never got enough specification last quarter. The plan is to break it into subtasks and build a table of what works for each protocol and language: Rust versus Go, plus a column for Python or C/C++ if those SDKs happen. Two more items came out of the previous two calls. One is a doc on which protocol to use for a given problem when designing a component-native architecture. The other is WIT interface design and composition best practices, so the community shares an answer to Bailey's standard review question: "does it compose?"

Precompiled Caches, Exploded Components, and Streamable Data​

The performance and efficiency theme starts with a long-standing item: make the cache for precompiled component artifacts customizable, so embedders can bring their own solution, such as a distributed cache. Bailey wants it among the first features shipped in Q4.

Next is exploded components, one of her favorite ideas, and in her view essential if wasmCloud invests in a Python SDK. Each component gets its own OCI layer, so a CPython or StarlingMonkey runtime that many components pull in, with the exact same bytes, can be deduplicated in the registry and also in the runtime's precompiled cache. Liam Randall asked what that means in practice. Today Go and Python components are larger because each carries a full copy of its runtime. Afterward the host could load one copy of each runtime and spawn instances from the shared precompiled artifact. Bailey corrected his wording from "data segment" to "instance" because data segments are a separate idea she also wants to pursue.

That idea is streamable data segments. Data segments are the core Wasm mechanism for bootstrapping linear memory. If they could load asynchronously and on demand, components could become the single packaging format for everything: Markdown documents, prompts, models, and other static assets. Apps could prefetch what a web page needs, or load only the parts of a neural network that the current inference path uses. Liam called it one of the most exciting features on the list.

k6 Load Tests and the Benchmarking Milestone​

Any work on caching needs measurement, so benchmarking stays an evergreen milestone. Jeremy Fleitz showed PR #5630, which closes issue #5052 after two quarters. wasmCloud already runs Criterion and Gungraun benchmarks on every release. The new k6 harness instead load-tests a deployed wasmCloud v2 stack end to end, measuring throughput, tail latency, the breaking point, and CPU and memory cost. Scenarios include http-hello, fan-out-10, chain-5, and many-workloads, with constant, stress, and spike profiles. The run.sh script creates or reuses a kind cluster, installs the runtime operator chart, and runs the same way in CI, on a laptop, or against your own cluster.

Running the same-host chain calls with local routing enabled exposed a bug that only shows up under strong load. The PR is a draft until that fix merges, and Jeremy expected it to be ready that day. Bailey wants every new plugin or network-touching feature to get its own k6 spec, starting with the NATS plugin. k6 is a macro benchmark. Micro benchmarks remain the right tool for fine margins such as host component plugin loading and async, and the team also wants realistic load tests that run for long periods.

Integration: S3 for WASI Blobstore and Declarative Storage Grants​

The integration theme belongs largely to Aditya. His issue and pull request adding bucket-scoped operations to Apache's object_store crate are filed upstream and awaiting maintainer review. He tested a preliminary wasmCloud implementation against LocalStack. Once the upstream work lands, the plan is to implement S3 first and stub Azure and GCS until they follow. Bailey expects this early in the quarter. object_store is the one dependency that can talk to every provider behind the built-in WASI Blobstore and WASI Key-Value plugins, so it is the right abstraction to maintain.

Bailey then proposed borrowing from the NATS plugin. There, the binding that attaches a workload to a plugin is a capability grant, and it can say which subjects a workload may use or which buckets it may create. Reviewing Jeremy's NATS work made her want the same declarative, fine-grained authorization for Blob Store and Key Value. She showed an earlier sketch, PR #5498, which adds operator-controlled bucket naming, a bucket_prefix, and a create policy for NATS-backed key-value. Asked which backends to prioritize, she said S3 by far, since it has become the lingua franca of object stores.

She closed the theme by encouraging new integrations as host component plugins in awesome-wasmcloud, outside the main repo, where every dependency goes through cargo-vet and audits. Each plugin is sandboxed, so expanding the host's capabilities this way is low-risk.

Can Agents Build the Integrations?​

Frank Schaffa asked why the community doesn't spec these integrations and have Claude or other agents build them. Bailey said it is possible, and pointed to her own Couchbase PR in awesome-wasmcloud, which compares several ways to implement one host component plugin. An LLM can one-shot something that works, but not yet something she would publish in the wasmCloud namespace for others to build on. A human driver still has to make sure the output uses the properties WebAssembly provides. Aditya added that host component plugins are built around WIT interfaces that need specificity and expertise, the way Yordis Prieto's input shaped the NATS interface. Both agreed that the protocol and WIT design docs, plus more representative examples, are what would let agents produce solid host component plugins at scale.

Workload Identity and Credential Brokering​

Bailey said quarterly planning should place the big rocks first, and that workload identity is the biggest. She means more than mTLS, and more than each workload having its own identity for TLS connections to external services. She wants the host to do credential brokering reliably, so that people building agents and agent harnesses can run them safely in a multi-tenant sandbox. That design is complex, but she thinks it is what people want right now as they search for a safe platform for agents.

She argued that WebAssembly is the best sandbox for this. Approaches built on VMs aim for isolation rather than true sandboxing, which is why they keep failing. She cited a weekend incident that came down to DNS ("it's always DNS") and noted that WASI has no DNS interface, so whole classes of POSIX-era problems never arise. Her design exploration is a large document that she will condense into a human-written RFC for feedback. The implementation is broken into phases as a stack of drafts, and the first parts should land next week.

PR Backlog​

Bailey said open pull requests are piling up. She has about 15 queued and reviews roughly four a day. She invited anyone, maintainer or not, to do first-pass reviews, because another reviewer's look gives her confidence. After the recording stopped, she planned to walk the maintainers through a threat model she has been developing.

WebAssembly News and Updates​

This week in webassembly news: wasmCloud 2.10.2 was cut, and the 2.10 release blog is live. Wasmtime 48 can now run cooperative threads produced by WASI SDK 34. That progress in the Bytecode Alliance is what puts Python and C/C++ SDKs within reach for the component model. wasm32-wasip3 is now a nightly Rust target and should become stable soon, and aws-lc-rs is close to building for both WASI P2 and P3. Apache's object_store is getting bucket-scoped operations so one implementation of WASI Blobstore can reach S3, Azure, and GCS.

What is wasmCloud?​

wasmCloud is a CNCF project for building applications out of WebAssembly components and running 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. The platform supplies capabilities like HTTP, messaging, key-value storage, blob storage, and observability through standard interfaces and a pluggable host plugin architecture backed by Wasmtime. wash is the developer shell for building, running, deploying, and debugging. The runtime operator schedules Wasm workloads on Kubernetes the same way you schedule containers, with WASI Preview 3 support on by default. Together they give you a production platform for WebAssembly on Kubernetes and at the edge.

Topic Deep Dive: Exploded Components and the Wasm Component Model​

In the wasm component model, an interpreted-language component is mostly runtime. A Python component built with componentize-py carries a whole CPython interpreter, and a JavaScript component carries StarlingMonkey. Your code is a small slice on top. That is fine for a single component. On a multi-tenant host running hundreds of them, it means storing, pulling, and precompiling the same interpreter bytes over and over. Exploded components separate those parts. Each inner component gets its own OCI layer, so a registry stores one copy of a given runtime build and a host pulls it once. Because wasmCloud precompiles components before running them, the host's precompiled cache can deduplicate too: one compiled CPython artifact serves every component that embeds those exact bytes, and each workload gets its own instance with its own linear memory and stack.

That is why the feature sits next to the customizable precompiled-component cache on the Q4 board, and why Bailey Hayes tied it to the Python SDK. Cheap Python components need both. Streamable data segments go further, letting a component carry static assets, prompts, or model weights and load them on demand instead of at instantiation, so the component itself becomes the packaging format. For background, see how components work in wasmCloud, packaging, and language support in wash.

Who Should Watch This​

Contributors looking for a first project should start with the component ecosystem theme at 6:07 and the "compile it with flags" discussion at 9:14. Python and C/C++ developers evaluating WebAssembly will want the SDK outlook at 6:07 and exploded components at 15:54. Platform engineers running wasmCloud on Kubernetes should watch the k6 load-test harness at 20:08 and declarative storage grants at 25:40. Teams building an AI sandbox or agent platform should jump to workload identity and credential brokering at 32:32.

Up Next​

Next week's call (October 7) is the collaborative Q4 roadmap planning session. Add comments to discussion #5619 beforehand. Expect wasmCloud 2.10.2 to be out, Jeremy Fleitz's k6 harness to merge once the local-routing fix lands, and the first workload identity drafts to start landing, with Bailey Hayes's RFC to follow. Bailey also owes a Rust refresh onto wstd with P3 support and subtasks for the "Are we componentized yet?" compatibility matrix. Aditya Salunkhe's object_store work is waiting on upstream review.

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 →