Skip to main content

Community Calls

Weekly wasmCloud Wednesday agendas, notes, and recordings. Add the next meeting to your Calendar or watch it live on YouTube.

wasmCloud Q4 Roadmap: Python SDK, Wasm vs. Containers, AI Policy

The October 7, 2026 wasmCloud community call was the Q4 planning session. Bailey Hayes named three big rocks for the quarter: a Python SDK, workload identity, and an expanded k6 suite that benchmarks WebAssembly on Kubernetes against the same app in containers and microVMs. The second half became a long discussion with Aditya Salunkhe, Yordis Prieto, and Frank Schaffa about AI-assisted contributions. It ended with a fourth rock: a permissive, written AI policy and agent stack for the project.

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.

wasmCloud 2.10, S3 Blob Storage, and Wasm Component Model Design

The September 23, 2026 wasmCloud community call opens the day after wasmCloud 2.10 shipped: Bailey Hayes walks the release (spec-conformant OpenTelemetry, host-wide mTLS client identity with rotation, enforced plugin egress, Wasmtime 48, Go 1.27, and a published all-features image) and sketches Q4. Aditya Salunkhe proposes S3, Azure, and GCP support for WASI Blobstore through Apache's object_store crate, and that turns into the call's real subject — a wasm component model design question: when do you write a WIT interface, when do you reach for gRPC or HTTP, and which implementation should back it? Bailey's answer is one question: does it need to compose?

Native WASI P3 for Go, Node.js in JCO, and Couchbase Plugins

The September 16, 2026 wasmCloud community call is three demos deep. Victor Adossi shows JCO's new Node.js SDK support running a gRPC server and an MCP server as WebAssembly components with one component-specific line each. Bailey Hayes builds two Couchbase host components — one embedding the vendor's Rust SDK, one speaking the HTTP Data API — behind a single WIT interface, and then shows the result of an all-nighter: a fork of Go that targets WASI P3 natively with component model cooperative threads, no wasip1 adapter, and no garbage-collector reentrancy trap. Yordis Prieto closes with Erik, a WebAssembly-only OpenAPI generator and linter, and a case for WIT annotations. If you care about Go WebAssembly, this is the call.