Skip to main content
← Back

WASI OTel Host Plugin Demo, TypeScript Templates & v2 Service Docs

Watch on YouTube ↗

The February 11, 2026 wasmCloud community call is anchored by Jeremy Fleitz's live demo of the WASI OTel host plugin — tracing, logging, and metrics emitted directly from inside a Wasm component into an Aspire collector, with the host adding workload-ID context so component-level spans line up cleanly with host-level spans. Eric walks through new TypeScript templates for HTTP clients and services with wasi-keyvalue and Blobstore backends, plus an expanded services documentation page and a fresh custom hosts / host plugins guide. Bailey updates the community on WASI 0.2.10 (hopefully the final 0.2.x release) and WASI P3 release-candidate progress, and Yordis Prieto confirms he's two code reviews away from landing map support in WIT and is heading for struct next.

Key Takeaways​

  • WASI OTel host plugin lands in wash runtime — Jeremy's PR adds the wasi-otel host plugin with tracing, logs, and metrics, enabled with a single wasi-otel: true line in the wash config and configured via standard OpenTelemetry environment variables
  • Live demo with Aspire collector — Jeremy stood up an Aspire dashboard via Docker, pointed OTEL_EXPORTER_OTLP_ENDPOINT and protocol at it, and watched runtime + component spans, logs, and metrics flow in real time
  • Host plugin links workload-ID context across spans — on bind, the host captures the active context from the component and joins it with a workload ID so traces line up across runtime and component boundaries automatically
  • Performance discussion — Frank Schaffa asked about overhead; Bailey noted that with the OTel logic inside the host, calls from component to host are in-process and nanosecond-scale rather than the previous NATS-over-network pattern. Real benchmarks are still a TODO
  • TypeScript templates with KV and Blobstore backends — Eric's new templates extend the HTTP service template (Hono-based) with wasi-keyvalue and Blobstore implementations, making them both production starting points and educational examples
  • Service documentation expansion — wash services now have a proper guide covering service export requirements with wasi-cli run, custom interface exports, step-by-step setup, and an expanded services overview page
  • Custom hosts and host plugins documentation — a new PR walks through extending wasmCloud with host plugins and building custom hosts (edge deployments, specialized hardware, integration with existing systems)
  • wash doctor is gone — the v2 templates can run an optional command on wash new (download deps, environment checks), so wash doctor was removed. Quick-start and developer guide docs still need cleanup
  • WASI 0.2.10 released, P3 release-candidate close — Bailey shipped 0.2.10 last week (hopefully the last 0.2.x — mostly docs/additive changes/feature-gated). The P3 RC dropped despite GitHub outages; wasi-cli changes exposed bugs fixed in wit-bindgen and wasm-tools. Victor is two-thirds through the second reference implementation
  • WIT map support imminent, struct next — Yordis Prieto is on the third round of code review for map support in wasmtime; struct (cyclic typing tricky) is his next target

Chapters​

Meeting Notes​

Jeremy's WASI OTel Host Plugin Demo​

Jeremy Fleitz walked through the wasi-otel host plugin PR for wash runtime. The plugin implements the wasi-otel interface — tracing (on_start, on_end, outer_span_context), logging (on_emit), and metrics (export) — directly inside the host. You enable it in the .wash config under dev: with a single line: wasi-otel: true. Configuration uses the standard OpenTelemetry SDK environment variables, so anything the OTel SDK already supports (OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_PROTOCOL, etc.) works without bespoke config.

The example PR ships with examples/otel-http — an HTTP component that uses the OTel provider for logging, metrics, and tracing in a single place so users can see all three flowing into a real collector.

For the demo, Jeremy stood up Aspire (a Dockerized OTel collector + dashboard) on ports 18888 (dashboard) and 5318 (collector). He exported OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:5318 and OTEL_EXPORTER_OTLP_PROTOCOL=grpc, ran wash dev, and started hitting the HTTP endpoint with curl. Because the env vars were set, OTel was enabled for both the host and the component:

  • The dashboard logs view filled with both wash-runtime and wasi-otel-tagged log entries with the service name passed from the component
  • The traces view showed spans starting at runtime (component build, reload) and then — as soon as a request arrived — spans from both the runtime and the component, all under one trace
  • The metrics view showed the HTTP counter incrementing along with the gauges the example exports

The integration point that makes spans line up across the runtime/component boundary: on workload-item bind, the host plugin captures the active context from the component and joins it with a workload ID, which is then used as the key for every subsequent event from that component. That's why a single trace can include both host-runtime spans and component-emitted wasi-otel spans cleanly.

Performance Q&A​

Frank Schaffa asked the inevitable question: what's the overhead? Jeremy hasn't captured benchmark data yet but acknowledged OTel can be very noisy — for production, he'd recommend dropping to errors-only on tracing while keeping the dev/info level richer for debugging. Bailey added an important architectural note: in previous architectures, OTel between components and providers involved a network hop over NATS as the provider received the data. With the host plugin, the component is talking to wasi-otel as an interface, which means it's exiting the WebAssembly sandbox into the host — but those calls are nanosecond-scale, in-process (a kernel-level mem copy at most). Real benchmarks are the next step.

Frank also asked whether the OTel processing can be async to avoid impacting hot-path performance. Bailey's answer: right now wasi-otel runs against wasi-p2, and on P3 the host calls will become native async via the canonical-ops mechanism. The component-to-host call is sync; what the host does afterwards (collector batching, network export) is already async.

Eric's TypeScript Templates​

Eric walked through new templates landed in the v2 branch of wasmcloud/typescript under templates/:

  • http-client
  • http-hello-world (fetch-based)
  • http-hello-world (Hono-based)
  • http-service (Hono with a mock backend)
  • New: http-service variants with wasi-keyvalue and Blobstore backends — same UI as the existing mock-status-store template, but the backend is a real wasmCloud capability

The new templates do double duty: they're production-ready starting points and educational models for how to add a specific backend to an HTTP service. Eric demoed adding two items to the Blobstore via the UI, then curling them back as JSON. More templates are coming for all the core WASI interfaces — feedback welcome on which templates the community most wants.

Service Documentation and Custom Hosts​

Eric opened two more docs PRs:

  1. Expanded services documentation — a comprehensive guide moving beyond the previous placeholders. Covers service export requirements (wasi-cli run style vs custom interface export), step-by-step setup, considerations for each pattern, and a much deeper services overview page.
  2. Custom hosts and host plugins guide — a step-by-step, example-rich walkthrough of extending wasmCloud with host plugins and building custom hosts for edge deployments, specialized hardware, or integration with existing systems. Still under review, in part because Lucas just refactored some of the OTel initialization logic and the doc needs to absorb those changes.

wash doctor Removed; Quick-Start Cleanup Pending​

Frank asked whether wash doctor still exists. Lucas Fontes answered no — it's been removed because it checked for the existence of a few binaries in specific places without respecting PATH or picking up nvm installs. The new pattern: templates can run an optional command on wash new (download dependencies, run environment checks), so each template does the right checks for its own toolchain. The quick-start docs and developer guide still reference wash doctor in a few places — Eric flagged the cleanup PR and acknowledged more cleanup is in progress.

WIT Map Support, Struct Next​

Yordis Prieto joined the call to report he's two code reviews away from merging map support in WIT inside wasmtime. Bailey suggested coordinating with Eric to get the new map type documented in the component model book. Yordis's next target: struct support — which people have warned him is tricky because of the cyclic-typing situation structs allow. He's leaning in anyway.

WASI 0.2.10 and P3 Release Candidate​

Bailey shipped WASI 0.2.10 last week ("zero to ten" by her count). She's hopeful that's the last 0.2.x release — all the meaningful work has moved to WASI P3. The 0.2.10 release is mostly documentation updates, additive changes, and feature-gated bits.

The P3 release candidate dropped despite GitHub outages. It's not rolled into most downstream repos yet because wasi-cli changes exposed some existing bugs that needed wit-bindgen and wasm-tools fixes; once those are out, the RC will roll into Wasmtime. Bailey hasn't had another change request on top of that RC yet, and Victor Adossi has made massive progress on the second reference implementation.

WebAssembly News and Updates​

This call lands squarely on two big WebAssembly themes: observability and language ergonomics. WASI OTel inside the host removes the network hop that previous Wasm-OTel architectures imposed, making in-process WebAssembly observability cost-competitive with native runtimes. The TypeScript story — built on JCO and StarlingMonkey — is getting templates that match what TypeScript developers expect from a server framework (Hono, KV, blob storage). And WASI P3 keeps closing in on stabilization with the Bytecode Alliance Plumbers Summit just two weeks away. Yordis's WIT map and struct work is a reminder that the component model is still actively gaining primitives from external contributors.

What is wasmCloud?​

wasmCloud is a CNCF project for building and running WebAssembly components across cloud, edge, and Kubernetes. The OTel host plugin demoed in this call is a v2 building block: components import the wasi-otel interface, the host implements it natively, and the entire OpenTelemetry pipeline (collectors, dashboards, alerting) plugs in via standard env-var configuration without changes to component code. Combined with the WebAssembly component model, declarative workload deploys, and signed/attested OCI artifact distribution, wasmCloud gives platform teams the production-grade observability story they need before deploying Wasm at scale.

Topic Deep Dive: WASI OTel and the Host Plugin Pattern​

The wasi-otel host plugin is a great example of how the v2 host plugin model differs from v1 providers. In v1, a "provider" was a separate process that components communicated with via NATS — flexible, but it meant every observability call (every span, every metric) was a network hop. Even when the provider lived on the same machine, that hop crossed kernel and async-runtime boundaries.

In v2, a host plugin lives inside the host process. The component still imports the wasi-otel WIT interface, so component code doesn't change. But the boundary is now a function-call into the host, which exits WebAssembly into native code in nanoseconds. The host plugin then talks to the OpenTelemetry SDK directly, which handles batching, async export, and protocol details with the standard collector infrastructure.

The interesting architectural detail is workload-ID context binding: on workload-item bind, the host plugin captures the active context from the component and merges it with a workload ID, which acts as the key for every subsequent event from that component. That's what makes traces line up cleanly across the runtime/component boundary — host-runtime spans (component build, reload, request routing) and component-emitted spans (your business logic) appear in a single trace, because they share the workload-ID context all the way through.

For platform engineers, this is the missing piece that brings Wasm component observability up to parity with what containerized apps already have through OpenTelemetry.

Who Should Watch This​

Platform engineers evaluating WebAssembly observability should watch Jeremy's full WASI OTel demo from 07:14, especially the Aspire dashboard walkthrough at 10:00 and the performance discussion at 17:48. TypeScript developers want Eric's new templates at 22:27. Component-model contributors and WASI watchers should jump to Yordis on map/struct support at 30:45 and Bailey's WASI 0.2.10/P3 update at 32:21.

Up Next​

Next week's call (February 18) will bring v2 templates with TCP socket support and Excalidraw diagram tooling. The Bytecode Alliance Plumbers Summit is on February 25-26. WASI P3 RC continues to harden, with the second reference implementation tracking toward completion. Jeremy will look at adding performance benchmarks for the OTel host plugin to measure overhead in production-style settings.

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 →