Skip to main content
← Back

wasmCloud 2.12 for WebAssembly on Kubernetes: DaemonSets, Plugin Secrets, and 163,000 Workloads per Host

The November 4, 2026 wasmCloud community call came the morning after the wasmCloud 2.12 release, the last one before KubeCon. Victor Adossi showed one host with 5 CPUs and 2 GiB of memory holding 27,250 warm or 163,750 scale-to-zero HTTP components. Jeremy Fleitz then demonstrated two new features for WebAssembly on Kubernetes: secrets served by a host plugin from an external etcd cluster, and a WorkloadDaemonSet that places a workload on every host in a host group.

Key Takeaways​

  • wasmCloud 2.12 is out. The release adds WorkloadDaemonSet support (#5784), plugin-backed secrets, finer memory pool controls, and a long list of bug fixes. Bailey Hayes expects it to be the last release before KubeCon, so the demo environment stays stable
  • Three first-time contributors. @cvas22 added PostgreSQL parameter-type validation (#5732), @ThomasDravigney fixed deleted objects in the NATS blobstore and added per-binding credentials (#5726, #5828), and @mackaby fixed nonblocking UDP receives on an empty socket (#5772)
  • OpenSSF Silver, with OSPS Baseline Level 3 next. wasmCloud passed Silver for the OpenSSF Best Practices badge, which required at least 80% test coverage. The project now targets OSPS Baseline Level 3 (#5865). The remaining work is in the other repos, such as the TypeScript and Go SDKs and wasmcloud.com
  • 163,750 scale-to-zero components on one small host. The scale_density benchmark on a 5-CPU host with a 2 GiB process-memory cap served 163,750 scale-to-zero HTTP components at about 12 KiB each, with a 2.42 ms p99 request that includes the wake-up. Kept warm, the same host held 27,250 components at a 1.29 ms p99
  • The biggest gain came from the memory reservation. By default, Wasmtime reserves about 4 GiB of virtual address space for each linear memory so it can skip bounds checks. #5801 makes the reservation configurable. Wasmtime then performs bounds checks, which makes components a little slower and relies more on the engine being bug-free
  • Plugin-backed secrets from etcd. Jeremy Fleitz built a host plugin that implements the wasmCloud secret source interface and reads from an etcd cluster outside Kubernetes. A host group's pluginSecrets block grants the plugin's keys to a namespace or to one workload. Workloads read them through the wasmCloud secrets interface or as wasi:config values
  • WorkloadDaemonSet mirrors a Kubernetes DaemonSet. It runs replicasPerHost instances on every host in a host group. maxConcurrentHosts sets how many hosts update at a time during a rollout, and that field may be renamed (Bailey suggested "max rollouts"). Argo CD now shows health for every resource, down to each workload
  • Next week is a KubeCon special. The call will be short and streamed from the wasmCloud booth on the KubeCon floor

Chapters​

Meeting Notes​

wasmCloud 2.12 and the OpenSSF Silver Badge​

Bailey Hayes opened the first call of November by welcoming a new member, Saleh Hassen. Saleh is a software engineer of about five years who is new to WebAssembly. He joined after hearing Liam Randall's talk at BSides NoVA the previous weekend. Bailey pointed newcomers to the wasmCloud Slack.

wasmCloud 2.12 shipped the night before. Bailey expects it to be the last release before KubeCon, because she and Eric Gregory will be on stage and want a stable base for the demo. The headline features are the ones Jeremy Fleitz demonstrated later in the call: WorkloadDaemonSet support and plugin-backed secrets (#5716, #5833). She thanked three first-time contributors:

  • @cvas22, for PostgreSQL parameter-type validation (#5732)
  • @ThomasDravigney, for treating deleted NATS blobstore objects as absent (#5726) and for per-binding blobstore credentials (#5828), which Bailey then extended further
  • @mackaby, for fixing nonblocking UDP receives so that an empty socket no longer returns an unexpected error (#5772)

A release blog post is on its way. Until then, the GitHub release notes list every change.

Bailey will cover the project's security work at the Security Slam session at KubeCon. wasmCloud has passed Silver for the OpenSSF Best Practices badge, which required 80% test coverage, so many of the release's PRs fill in tests (#5796). The project now targets OSPS Baseline Level 3, the highest level of the Open Source Project Security Baseline. The remaining items are in repos outside the main wasmCloud repo, such as the TypeScript and Go SDKs and wasmcloud.com, and Bailey expects to finish them that week.

Density: 163,750 Workloads on One Host​

Victor Adossi walked through his recent chain of perf and fix PRs. wasmCloud is built on Wasmtime, the Bytecode Alliance runtime that either compiles Wasm to machine code with Cranelift or interprets it with Pulley. wasmCloud adds workload management and configuration on top. For Wasm, the limit on scale is memory, not CPU. So the PRs count and budget linear memory (#5763, #5799), drop linkers once they are no longer needed (#5800), and free stopped workloads (#5802).

The last step, new since the October 21 call, reduces the memory reservation (#5801). By default, Wasmtime reserves about 4 GiB of virtual memory for every linear memory. Because a 32-bit pointer can't reach past 4 GiB, Wasmtime can then skip bounds checks on memory access. Turning the reservation down doesn't make a component unsafe. Wasmtime does the bounds checks instead, which costs some speed. It also means that if the engine has a bug, a component could reach a sibling instance's memory, and that may matter for your security model.

The results below come from the scale_density benchmark on wasmcloud-bench-01, with 5 CPUs, a 2 GiB process-memory cap, and a 256 MiB + 64 KiB memory layout. Bailey said the bench box rents for about €35 a month and uses an older AMD Ryzen 5. Victor called it consumer hardware, and said Apple M-series machines should do much better.

MetricWarmScale-to-zero
Workloads served27,250163,750
Memory per extra workload75,441 B (~74 KiB)12,524 B (~12 KiB)
Starts per second8,15530,999
Request p991.29 ms2.42 ms
CPU per start0.37 ms0.09 ms
Stopped bymax process memorymax process memory

Warm components stay in memory. Scale-to-zero components are registered and start on the incoming request, so their p99 includes the cold start. Victor said other Wasm platforms report around 4,000 workloads per host. With four or five times the memory, he projected more than a million scale-to-zero workloads on one machine. The host also detects memory pressure on macOS, which otherwise freezes rather than killing the process, and has settings to cap memory use.

Is there another order of magnitude? Victor wasn't sure. Each workload's layout is now 256 MiB, and a workload that only streams data could get by with 25 MiB or 10 MiB, but at that point tuning becomes workload-specific. Bailey noted that the project has already gained several orders of magnitude.

Agents and RISC-V Boxes at Wasm Density​

Bailey pointed out that an HTTP component stands in for any I/O-bound workload. An agent that talks to an OpenAI-compatible HTTP interface could be scaled to zero, sandboxed, and woken on demand. Victor added Meta's assistant as an example of where this density changes the cost: he said it is planned at about two vCPUs per user.

He also revisited the RISC-V Linux sandbox that Aditya Salunkhe demonstrated on the October 14 call. At this density, one machine could run 27,000 RISC-V Linux boxes instead of one per vCPU. Aditya said he is now building a multi-core version on the Wasmtime threads proposal. With four threads it ran about eight times faster and reached about 60% of native speed. Bailey's rule of thumb is that 2x slower than native is within the threshold. JavaScript and Python are often about 60 times slower than native, so this counts as near-native.

Plugin-Backed Secrets from an External etcd Cluster​

Jeremy Fleitz demonstrated plugin-backed secrets, which shipped in 2.12. Every wasmCloud build also produces an all-features container image with the build-flagged features turned on, including host component plugins. Jeremy used 2.12.0-all-features.

Why a plugin? Kubernetes Secrets are base64-encoded and only encrypted at rest if the cluster is set up for it. HashiCorp Vault and similar tools solve this for containers with a sidecar that injects secrets into each pod. A wasmCloud host pod runs thousands of workloads, so a sidecar per workload doesn't fit. A host plugin can fetch secrets however you need and hand them to each workload securely.

Jeremy's host-plugin-etcd-secrets implements the wasmCloud host secret source interface and reads from an etcd cluster that runs outside Kubernetes, so the kubelet and the Kubernetes API can't read it. The host loads the plugin by image, gives it its configuration, and allows it to reach the etcd endpoints. The new pluginSecrets block on the host group then does three things:

  • It names the plugin as a secret source (reader-config → etcd-secrets).
  • It maps config keys to etcd keys.
  • It limits which workloads can read them. A grant can cover a whole namespace or a single namespace-and-workload pair.

Workloads can use these secrets in two ways. A workload can call the wasmCloud secrets interface to reveal a secret when it needs it, at call time. Or the standard wasi:config interface can read from the plugin instead of Kubernetes Secrets, so the values arrive at bind time with no extra interface in the component. Bailey recommended the secrets interface where possible, because the value stays typed as a secret all the way through. The type tells you never to log the value, and an untyped config value doesn't.

WorkloadDaemonSet and Argo CD Health​

While building the demo, Jeremy also fixed health reporting for Argo CD. Before, the green health heart stopped at the top-level resource. Now status conditions reach every sub-resource, so a platform engineer can see health from the WorkloadDeployment all the way down to each workload.

The new WorkloadDaemonSet (#5784) has the same structure as a WorkloadDeployment on purpose. wasmCloud mirrors Kubernetes Deployments and pods with WorkloadDeployments and workloads, because "Kubernetes won" and platform engineers already know the model. Two fields are new:

  • replicasPerHost is how many instances run on each host.
  • maxConcurrentHosts is how many hosts update at a time during a rollout. With 1, the hosts update one after another as each becomes ready. With 2, the rollout goes faster. Jeremy wants to rename the field, and Bailey suggested "max rollouts" from Kubernetes.

Like a WorkloadDeployment, a WorkloadDaemonSet targets a host group (or a shared host group). It runs only on the hosts in that group, not on every host in the cluster. Bailey summed it up: the wasmCloud operator now understands a DaemonSet equivalent, with components in place of containers.

KubeCon Next Week​

Next week's call will be a short KubeCon special from the wasmCloud booth, probably hosted by Jeremy, because Bailey and Eric will be getting ready for their talk. Bailey closed by thanking Aditya for his recent PRs, including host component plugin volume mounts, which is now ready for review. A volume-mounted secret could start the plugin secrets flow without a Kubernetes Secret at all. For now, the plugin needs one Kubernetes Secret to bootstrap its connection to Vault or etcd.

WebAssembly News and Updates​

In webassembly news this week, security baselines are becoming part of shipping a release. The OpenSSF Best Practices badge and the OSPS Baseline give CNCF projects a public checklist, and wasmCloud is now at Silver and targeting Baseline Level 3. On the runtime side, Wasmtime's configurable memory reservation lets a host trade the 4 GiB reservation for explicit bounds checks. That trade is how one small host holds more than 160,000 isolated WASI HTTP handlers. Work on the Wasmtime threads proposal, such as Aditya's multi-core RISC-V emulator, shows Wasm getting close to native speed for workloads that once needed a full VM.

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, secrets, 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: WebAssembly Kubernetes Patterns in wasmCloud 2.12​

The two features Jeremy demonstrated make WebAssembly on Kubernetes look more like the Kubernetes you already run. A WorkloadDaemonSet does for components what a DaemonSet does for pods: it runs a set number of replicas on every host in a host group, with a controlled rollout. That suits per-node agents, local caches, and edge gateways. The operator manages it through the same custom resources as WorkloadDeployments, and GitOps tools like Argo CD now see health at every level.

Plugin-backed secrets solve a problem that sidecars can't solve at Wasm density. Thousands of components share one host pod, so the secret source belongs to the host. You write it once as a host plugin, connect it to etcd, Vault, or another store, and grant its keys per namespace or per workload. Components see the result through the typed wasmCloud secrets interface or through wasi:config, which keeps the code portable. If you still use Kubernetes Secrets, see secrets and configuration and injecting configuration from ConfigMaps and Secrets. For density and scale-to-zero on Kubernetes, see lightweight deployments and workload security.

Who Should Watch This​

Platform engineers running Wasm on Kubernetes should start with Jeremy Fleitz's secrets demo at 23:07 and the WorkloadDaemonSet walkthrough at 32:27. Teams sizing hosts or planning agent sandboxes will want Victor Adossi's density results from 11:13 and the agent discussion at 18:13. Security and compliance leads can find the OpenSSF badge and OSPS Baseline update at 1:05.

Up Next​

Next week's call will be a short KubeCon special streamed from the wasmCloud booth. Expect the 2.12 release blog post, the remaining OSPS Baseline Level 3 work in the SDK and website repos, a new name for the WorkloadDaemonSet rollout field, and review of Aditya Salunkhe's host plugin volume mounts PR.

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 →