Skip to main content
← Back

wasmCloud v2 Templates with TCP Sockets, Excalidraw Tooling & WASI P3 Update

Watch on YouTube ↗

The February 18, 2026 wasmCloud community call leans into v2 architecture and tooling. Lucas Fontes demos new wasmCloud v2 templates that center the full application (cargo workspaces, multiple components per project) and shows off TCP socket binding inside components with per-workload localhost isolation — two workloads can bind the same port without conflict. Eric opens a PR adding Excalidraw diagram tooling to the wasmcloud.com repo, including a Claude skill, custom PNG export, and brand-aligned diagram workflow. Bailey Hayes updates the community on WASI P3 progress (new release candidate, significant wasi-cli reshaping), the upcoming Bytecode Alliance Plumbers Summit, and the imminent reference-implementation completion. Aditya raises a great question about dynamic config updates mid-deployment, which leads to a NATS-backed plus virtualization design discussion.

Key Takeaways​

  • wasmCloud v2 templates scale up to full applications — Lucas demoed templates built around cargo workspaces with multiple components per project, replacing the v1 "one component per project" mental model
  • TCP socket binding inside components — wasmCloud v2 gives each workload its own localhost, so multiple workloads can bind the same port without conflict; the demo's HTTP component talks to a long-lived TCP service component in the same workload
  • Stateless components + long-running connection pools in one workload — this is the architectural shape behind future use cases like compiling PgBouncer or other connection bouncers / database proxies to Wasm and bringing them with your workload
  • Excalidraw diagram tooling PR — Eric proposed a .claude directory skill for Excalidraw diagrams plus custom PNG export scripts, brand colors, and a workflow doc so any contributor — human or LLM — can generate brand-consistent architecture diagrams
  • wasmCloud Excalidraw library available — Bailey published an Excalidraw library with wasmCloud logos, color-scheme legend, and brand elements; one click adds it to your Excalidraw
  • WASI P3 release candidate is close to stable — wasi-cli got significant changes around stdout/stderr/error-message handling using features; new versions of everything except Wasmtime are cut; Victor's massive PR for streams support in the JCO reference implementation landed
  • Bytecode Alliance Plumbers Summit next week — Wednesday and Thursday, three hours each, including Luke Wagner's road-to-1.0 keynote, Cy Brand on cooperative threads, Joel Dice on guest-language componentize work, Victor Adossi on JCO and browser support, plus deep Wasmtime sessions (compile time, built-ins, guest debugging, OOM handling) and lightning talks on component virtualization and WASI spec tooling
  • Dynamic config update flow — Aditya raised the question of updating wasi-config mid-deployment without modifying the host API; Lucas proposed using NATS-backed KV mappings, and Bailey suggested virtualizing the wasi-config API with bundled or component-provided config — both approaches solve it without host-API churn

Chapters​

Meeting Notes​

wasmCloud v2 Templates and TCP Sockets​

Lucas Fontes walked through the new wasmCloud v2 templates and the substantial difference in scope. In v1 with wash, the unit of work was a single component. In v2, the template centers on the full application: a cargo workspace can host three components, regular binaries, helper crates — and the wash config specifies which components to load. After wash new against the template, the build runs against wasm32-wasip2 and wash pulls the right .wasm artifacts as the entry point and service.

The marquee feature: TCP socket binding inside components. In v2, each workload has its own localhost. Two workloads can bind the same port and not collide. The demo template ships an HTTP component plus a long-lived TCP service component in the same workload. When you wash dev and hit the HTTP endpoint, the HTTP component opens a TCP connection to the sibling service, sends text, and reads back the leetcode-encoded response. The HTTP component is a stateless wasi-http handler that only runs on request; the TCP service is a long-running listener holding the connection pool.

The architectural payoff: components can be stateless while still talking to long-running connection pools inside the same workload. Future use cases Lucas teased: compile PgBouncer or any database/connection proxy to Wasm and bring it with the workload. You keep WebAssembly's scale-to-zero properties while still getting connection pooling for downstream services — the same property containerized apps have today, but without the container.

Bailey noted she's adding a health check pattern to examples — it makes the dev loop dramatically less frustrating when you accidentally break a sibling component and need a sanity ping.

Excalidraw Diagram Tooling​

Eric opened a PR adding Excalidraw diagram tooling to wasmcloud.com. The motivation: as the v2 docs build out, the team needs architecture diagrams, build-pipeline diagrams, etc. — and the project has an established Excalidraw scratchy-style brand identity. The question is how to leverage tooling like Claude Code to generate diagrams that are programmatic, reproducible, brand-consistent, and pretty.

The PR adds:

  • A Claude skill for Excalidraw diagrams in the .claude/ directory
  • Custom scripts to export Excalidraw files to crisp PNG (a real challenge — getting clean output was non-trivial)
  • A Claude.md file that helps Claude Code generate brand-consistent diagrams
  • A README covering the workflow, brand colors, and instructions for creating/editing diagrams

The framing for the community: "what do you think of this? Is it usable? Tell us before merge."

wasmCloud Excalidraw Library​

Bailey Hayes walked through her published wasmCloud Excalidraw library — a one-click add to your Excalidraw that drops in wasmCloud logos, brand elements, and a color-scheme legend. She submitted it to the Excalidraw marketplace; the queue is long, but the library link works directly. The library is what most of the public-facing wasmCloud diagrams already use. Demo: she pulled up a Claude-generated host-self-registration diagram, dropped in the wasmCloud branding, and recolored backgrounds with the eyedropper + brand palette in seconds.

WASI P3 Update and the Plumbers Summit​

Bailey cut a new WASI P3 release candidate and rolled it into Wasmtime. Implementation feedback on wasi-cli led to significant changes in how stdout, stderr, and error messages flow through futures, which required additional changes in wasm-tools and wit-bindgen. Those changes uncovered several bugs (now fixed), and new versions of everything except Wasmtime are out — the Wasmtime cut will fold them in next release. Victor Adossi landed a massive PR for streams support in the JCO reference implementation; next week he's taking on futures, which should be much easier with streams as scaffolding. As far as Bailey is aware, no more WASI API changes are needed — the current RC is close to stable.

The Bytecode Alliance Plumbers Summit is next week (Wednesday and Thursday, three hours each). The agenda:

Day 1:

  • Luke Wagner keynote on the road to component model 1.0
  • Cy Brand on cooperative threads
  • Roadmap discussions
  • Joel Dice on componentize-py, componentize-go, and the broader componentize landscape across guest languages
  • Victor Adossi on JCO and the work to support browsers with the component model

Day 2:

  • Wasmtime-focused sessions on compile time, canonical built-ins, guest debugging, and OOM handling
  • Lightning talks: Yan Chen on component virtualization and component-based fuzzing ("component inception"), Till on a tool for writing better WASI specifications

The Summit overlaps wasmCloud Wednesday; Liam will MC the wasmCloud call (briefly) so everyone else can pay attention to the Summit content.

Community Engagement​

Liam asked how the wider community can help. Bailey's pitch:

  • Follow along in the Bytecode Alliance — there are concrete to-dos and PRs welcome
  • wit-bindgen expansion is a high-leverage place to contribute; her recent PRs have been adding missing cases in the C# and C++ paths, and the pattern of "handle one case at a time" is friendly to new contributors
  • The JCO browser shim (polyfill, in browser-folks language) is the leading indicator for Chrome's decision on whether to natively support the component model — using the shim and demonstrating real component-model traffic on the web is what unlocks the Chrome-team investment
  • Yordis Prieto is the model: he wanted WIT map types, didn't wait for the component model to prioritize it, designed the change, implemented it across wasm-tools, and got it landed. That path is open to anyone

Dynamic Config Update Flow​

Aditya asked about updating wasi-config values mid-deployment without modifying the host API. In wasmCloud v1, wasi-config was dynamic — you could change values and NATS reconciliation would surface them in the component. In v2, the team has been treating wasi-config and the wasi-cli environment as siblings (both hash maps representing configuration) and started by mirroring values from both into a single source.

Lucas proposed keeping the CLI environment in the host API and using NATS-backed KV for wasi-config — so values can be updated in NATS and reflected on the component without changing the host API. This preserves the idempotency property of workload deploys.

Bailey added a complementary path: virtualize the wasi-config API with your own implementation. If you want fully declarative, statically-bundled config, you can ship that with your component — no wasmCloud host changes needed, just composition at the component model level. Both approaches solve the problem without touching the host API surface.

Aditya flagged that the wasi-cli environment is statically linked with the WASI context (one-time), so the dynamic update route really is wasi-config + NATS or virtualization. Lucas added: for local development without NATS, the same pattern works as with the Blobstore KV — back the values with the filesystem and convert files into wasmCloud KV maps.

WebAssembly News and Updates​

This call sits at the convergence of several big WebAssembly threads. WASI P3 is on its final release-candidate run, with JCO streams support landing and futures imminent. The Bytecode Alliance Plumbers Summit next week will set the public agenda for the road to component model 1.0 — cooperative threads, browser support, and the componentize-everything story for guest languages. wasmCloud is positioning v2 to land exactly when this lift gives it the most leverage.

What is wasmCloud?​

wasmCloud is a CNCF project for building and running WebAssembly components anywhere — cloud, edge, or Kubernetes. The v2 architecture demoed in this call introduces per-workload localhost — every workload gets its own loopback, so multiple workloads can bind the same port without conflict — and supports TCP socket binding directly from inside components. Components can be stateless wasi-http handlers while sharing a workload with long-running connection pools or service components, all linked through the component model. Built-in OpenTelemetry observability, declarative workload deploys, and signed/attested OCI artifact distribution round out the operational story.

Topic Deep Dive: Per-Workload Localhost and Stateless+Stateful Composition​

The TCP socket demo highlights a pattern that's genuinely new in wasmCloud v2: mixing stateless HTTP handlers with long-running stateful service components in the same workload, all sharing a private loopback. In a traditional container or VM world, this composition exists but is operationally heavy — each side is a separate pod with its own deployment, scaling, and lifecycle. In wasmCloud v2, it's a single workload deploy. The HTTP handler still scales to zero (only instantiated on request); the TCP service component still holds its connection pool. Communication between them happens over per-workload localhost, which means latency stays in-process and there's no port-collision story when you scale out across hosts.

For platform engineers, the immediate use case is the one Lucas teased: ship a workload that includes its own database connection bouncer compiled to Wasm. You get the scale-to-zero benefits of the component model without giving up the connection pooling that traditional databases need at scale. Once componentize-go and the rest of the guest-language toolchains finish landing, that pattern opens up across every supported language.

Who Should Watch This​

Rust developers building wasmCloud applications should start with Lucas's v2 template walkthrough at 05:58 and the TCP socket demo through 13:00. Docs contributors and AI tooling watchers want Eric's Excalidraw PR at 14:12 and Bailey's library walkthrough at 17:36. WASI P3 and component model followers should jump to Bailey's RC update at 20:18 and the Plumbers Summit agenda preview at 22:00. Platform engineers thinking about secrets and config management will want the dynamic config update discussion at 29:54.

Up Next​

Next week is the Bytecode Alliance Plumbers Summit — Wednesday and Thursday. The wasmCloud Wednesday call will run in parallel; Liam will MC briefly so the wider team can focus on Summit content. Victor will land streams + futures in JCO, completing the second reference implementation. Aditya plans to evaluate the NATS-backed wasi-config approach.

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 →