Skip to main content
← Back

Template Refactor, Workload Config & Environment Variables, WASI TLS

Watch on YouTube ↗

The April 29, 2026 wasmCloud community call covered a template refactor bringing Rust language support into parity with TypeScript using new handler terminology, a detailed proposal for workload configuration supporting environment variables and secrets in the wash dev loop, roadmap updates on microbenchmarking infrastructure and automated releases, and discussions on WASI TLS adoption and host component plugin architecture.

Key Takeaways​

  • Rust templates now match TypeScript — Eric walked through a refactor that brings Rust component templates and language support documentation into parity with the existing TypeScript guides, giving Rust developers the same building blocks
  • "Handler" replaces "service" in template naming — The team adopted "handler" for stateless component templates to disambiguate from wasmCloud's service model, aligning with the WASI HTTP handler interface naming
  • New workload config section for env vars and secrets — Bailey Hayes proposed a new workload section in the wash config YAML that supports environment variables, WASI config fields, and secrets with .env file integration and guardrails
  • Security guardrails for secrets in dev — The design enforces that .env files must be in .gitignore, prevents path traversal, types secrets explicitly so they never appear in logs, and supports environment variable references as a safer alternative
  • Microbenchmarking infrastructure in progress — Bailey is setting up a Hetzner bare-metal box for reproducible benchmarks, adding a Valgrind-based IOPS bench alongside existing micro benchmarks for deterministic CPU-level measurements
  • WASI TLS added to the roadmap — Aditya will pick up the WASI TLS proposal as an experimental opt-in feature, providing implementation feedback for the emerging standard while keeping it clearly flagged as early-stage
  • Test binary build problem getting community attention — Multiple contributors proposed solutions for preventing test binaries from building when wasmCloud is used as a downstream dependency, with a ghost crate approach and an xtask workflow under consideration
  • New maintainers recognized — Aditya was promoted to core and wash maintainer, Pavel to wash maintainer, and Jeremy Fleitz to go maintainer for the runtime operator

Chapters​

Meeting Notes​

Rust Template Refactor and Handler Terminology​

Eric presented a refactor of the wasmCloud component templates aimed at bringing Rust language support into parity with TypeScript. The TypeScript language guide and templates had gotten significantly ahead, so the effort focused on giving Rust developers the same set of building blocks and interface guides. During the process, the team identified a naming collision: wasmCloud uses "service" as a workload model concept, but the templates were also calling some stateless components "services." After discussion, Bailey Hayes and Eric settled on handler as the replacement term for stateless component templates, drawing from the WASI HTTP interface where the incoming request handler is literally called handler. Several new handler templates are landing in the wasmCloud monorepo, and interface guides for Rust components will follow shortly.

Bailey also used the opportunity to call out a growing backlog of community PRs and encouraged anyone — even non-maintainers — to review incoming contributions. She formally congratulated Aditya, Pavel, and Jeremy Fleitz on their promotions up the contribution ladder, recognizing their sustained contributions to the project.

Workload Configuration: Environment Variables and Secrets​

Bailey Hayes walked through a GitHub issue proposing a new workload section in the wash config YAML. The feature addresses a gap Colin Murphy hit while building the WebGPU demo — needing to pass environment variables in the wash dev loop. Today the only workaround is a host interface with WASI config, which works but is cumbersome for simple use cases.

The proposal adds support for loading config values and secrets from literal values, environment variable references, or .env files. The design intentionally sits outside the existing dev section to keep the developer-facing configuration clean and eventually translatable to Kubernetes workload specs, without requiring deep Kubernetes knowledge. Bailey outlined the security guardrails: .env files used for secrets must be in .gitignore, file references are restricted to the project root to prevent path traversal, and secrets are explicitly typed so that the wash CLI never writes them to disk or logs. The team discussed Mozilla SOPs as an alternative encryption-based approach but decided it was too much scope for the initial implementation.

Frank Schaffa raised the point that developers might bypass the secret type by putting sensitive values in regular config fields. Bailey acknowledged this but noted that the explicit typing still gives wasmCloud a stronger security posture than most tools in the space, since the runtime treats the secret type with special handling throughout the pipeline.

Roadmap Review: Microbenchmarking, Releases, and CI​

Bailey provided a status update on the active roadmap. On the microbenchmarking front, she has been setting up infrastructure on Hetzner for reproducible bare-metal benchmarks after finding that the open-source tier of Bencher only provides five minutes of execution time. She added an IOPS Valgrind bench for deterministic CPU instruction counts alongside the existing time-based micro benchmarks, and noted that k6-based network and Kubernetes benchmarks are a welcome future contribution.

On the release side, the team is tracking toward automated releases every two weeks on Tuesdays. Recent work includes adding wasmCloud to the Windows Package Manager (winget) for automatic publishing, and switching Linux builds from musl/glibc to link against the correct system libraries for WebGPU support through Linux Homebrew.

Test Binary Build Problem​

Aditya brought up an ongoing issue where test binaries compile even when wasmCloud is used as a downstream dependency via cargo build. Multiple contributors have taken a swing at this. The two leading proposals are a ghost crate approach — an unpublished side crate referenced as a dev dependency so that cargo test picks it up via build.rs but regular builds skip it — and an xtask workflow where test setup is an explicit external command. Bailey noted that she tried cargo config flags first but that approach falls apart for cargo bench and other subcommands. The team asked for community feedback before committing to either path, with Aditya leaving the discussion open for another day.

WASI TLS Proposal​

Aditya raised the question of adding WASI TLS support to the wasmCloud roadmap. Bailey confirmed she created an issue for it after seeing the proposal land in Wasmtime 44 via Dave Bakker's implementation work. The team agreed to bring it in as an experimental, opt-in feature — similar to how WebGPU is handled — with clear signaling that the spec is still pre-phase-two and may change. The rationale: exercising and providing implementation feedback on emerging WASI proposals is exactly the kind of community stewardship wasmCloud should be doing.

Colin Murphy asked what Rust crates could be supported with WASI TLS today. Bailey noted the current focus is on the host-side implementation, with .NET being the first end-to-end guest implementation. She also mentioned upcoming work on WASI crypto from a research group at Université de Montréal that could further unlock the Rust HTTP ecosystem for Wasm.

Host Component Plugins and WIT Interface Design​

The call closed with a discussion on host component plugins — the effort to provide WASI p3 sandbox-compatible versions of wasmCloud's native plugins. Bailey framed this as a large effort where converting all existing native plugins is out of scope for the quarter. Native plugins will continue to exist for use cases like WebGPU that require hardware-level access, but the major demand is for client-style plugins (secrets vaults, service mesh integrations) that benefit from sandboxing.

Aditya asked whether it makes sense to build WIT interfaces for host components when a component could just make the call itself via wasi-http. Bailey offered a decision framework: if the plugin is HTTP-based with good upstream SDKs, lean toward wasi-http host components for maximum ecosystem compatibility. If the plugin uses its own socket-level protocol (like NATS) and benefits from connection pooling, rich types, and composition, a custom WIT interface is worth the additional SDK investment.

WebAssembly News and Updates​

This week's call reflected the maturing developer experience story for WebAssembly. The template refactor and handler terminology alignment show the component model ecosystem converging on consistent naming across languages and frameworks. The WASI TLS discussion highlights how projects like wasmCloud serve as proving grounds for emerging WASI proposals, providing implementation feedback that shapes the standards. Meanwhile, the benchmarking and CI hardening work continues building the kind of production-readiness infrastructure that enterprise adopters expect from a CNCF incubating project.

What is wasmCloud?​

wasmCloud is a CNCF project for building and running WebAssembly applications across cloud, edge, and everything in between. It uses the WebAssembly component model to let developers write portable, composable business logic in any supported language — Rust, Go, TypeScript, Python, C# — while the platform handles deployment, networking, scaling, and observability through OpenTelemetry. Applications are declared as workload deployment specs and can run on Kubernetes or standalone, with built-in support for secrets, configuration, and capability-based security.

Topic Deep Dive: Secrets Handling in Developer Workflows​

The workload config proposal revealed a design tension that every cloud-native developer tool faces: making secrets convenient without making them unsafe. Bailey's approach layers multiple guardrails — explicit secret typing, .gitignore enforcement, project-root scoping, and in-memory-only handling in the wash CLI — rather than relying on any single mechanism. The explicit secret type is particularly significant because it flows through the entire wasmCloud runtime: secrets are never written to logs, never serialized to disk, and get special treatment in the OTEL trace pipeline. This is a meaningful improvement over the common pattern in tools like Docker Compose or Terraform where secrets are just environment variables with no runtime distinction.

The discussion also surfaced the Vercel incident as a cautionary tale — a recent security breach caused by environment variable exposure — and the trade-off between Mozilla SOPs (encrypted secrets committed to git) and .env files (convenient but easy to accidentally commit). For teams evaluating WebAssembly for platform engineering, wasmCloud's typed secrets model combined with the proposed guardrails offers a development experience that is both familiar (.env files, direnv) and meaningfully safer than the status quo in most container-based toolchains.

Who Should Watch This​

Rust developers building wasmCloud components should start with Eric's template refactor walkthrough at 06:02 to understand the new handler terminology and upcoming interface guides. Platform engineers concerned about secrets management in developer workflows will want to watch Bailey's workload config proposal at 11:42 and the security guardrails discussion at 17:51. And contributors interested in wasmCloud internals should catch the WASI TLS and host component plugin discussion starting at 33:10.

Up Next​

Bailey plans to finalize the workload config issue for "ready for work" status after collecting community feedback, and will continue setting up the Hetzner bare-metal benchmarking infrastructure. Aditya committed to picking up the WASI TLS implementation as an experimental feature and continuing work on the wasmCloud NATS interface. Eric will land the remaining Rust handler template PRs and interface guides. The team also flagged the need to update Kubernetes documentation from v2.03 to v2.04 to resolve a Helm ingress role-binding bug that Jeremy identified.

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 →