Releases

wasmCloud v2.5.1 was released, but the published notes are too brief to summarize. See the original release notes for details.

wasmCloud v2.5.0 is a feature release centered on the wasmtime 46 upgrade with wasip3 enabled by default, alongside a breaking change to the keyvalue bucket WIT interface and a medium-severity quinn-proto security fix. The rest of the release adds new async keyvalue/blobstore interfaces, operator hardening, and various runtime and tooling fixes.

• securityquinn-proto security fix (RUSTSEC-2026-0185)

  Applies if you build or update wasmCloud from source or run dependency scans: quinn-proto is patched for RUSTSEC-2026-0185 (medium) in this release. Upgrade to pick up the fix; no application code changes needed.

• breakingkeyvalue bucket moved to shared types interface

  Applies if any component uses the wasmcloud:keyvalue interface: the bucket type moved out of the inline interface definition into a shared types interface. Components and providers built against the old wasmcloud:keyvalue WIT must update their bindings and regenerate code before upgrading.

• breakingwasmtime 46 with wasip3 enabled by default

  Applies to all components running on this runtime: wasmtime is now 46 and wasip3 support is on by default. Test existing components against the new runtime before rolling out broadly, especially anything sensitive to wasip3 behavior changes.

wasmCloud 2.4.0 adds autoscaling for WorkloadDeployments, expands architecture support (s390x), and improves the wash CLI and host plugin API. Mostly incremental improvements with some operational benefits.

• enhancementEnable autoscaling for WorkloadDeployments if you manage variable-load services

  wasmCloud 2.4.0 adds autoscaling to WorkloadDeployments. If you currently run static replica counts and workload demand fluctuates (peak hours, batch processing windows, etc.), enable autoscaling to reduce manual scaling and idle cost. Review the autoscaling configuration in your Helm charts or YAML manifests and test thresholds in a staging environment before rolling to production.

• enhancementUpdate wash CLI if you deploy on s390x or other non-x86 systems

  wash now builds for s390x-unknown-linux-gnu. If your infrastructure uses IBM mainframes or other s390x systems, you can now build and run wash natively instead of via emulation or workarounds. Fetch the new binary from the release assets and validate it works with your host setup.

• enhancementReview container health check configuration to rely on NATS connectivity

  Container health checks now use NATS connectivity status rather than a separate probe. This simplifies failure detection: if the container loses NATS connection, it's marked unhealthy faster. Verify your health check thresholds and timeouts still work for your deployment, especially if you have high-latency or congested networks where NATS reconnection may take longer.

v2.3.0 ships workload env/config/secrets management in wash, wasmtime 45 upgrade with security patches, and improved OTel tracing across workloads and HTTP spans.

• securityApply wasmtime 45 upgrade and dependency security patches immediately

  This release includes two wasmtime bumps: 44.0.2 was a targeted security patch, and 45 followed shortly after. On top of that, additional dependency security advisories were patched separately. If you're running wasmCloud in production, upgrade to v2.3.0 now rather than waiting — the cumulative security surface covered here is non-trivial.

• enhancementScope Kubernetes RBAC to namespaces instead of cluster-wide

  The runtime.wasmcloud.dev apiGroup RBAC can now be namespaced rather than cluster-scoped. If you're running the wasmCloud operator in multi-tenant Kubernetes clusters, revisit your RBAC configuration and tighten it to namespace scope where possible. This is a meaningful security posture improvement for shared clusters.

• enhancementStart using wash workload env/config/secrets for structured configuration

  Configuration and secrets management is now surfaced directly in the wash CLI. This is the workflow shift wasmCloud has been building toward — rather than managing config out-of-band, you can now handle env vars, config, and secrets as first-class workload concerns. Check the new otel-config example in the repo to see the intended pattern before adopting it in production.

wasmCloud v2.2.1 was released, but the published notes are too brief to summarize. See the original release notes for details.

wasmCloud v2.2.0 adds WASI Preview 3 TLS support, a customizable HTTP outgoing request handler, and several operator fixes for namespace-scoped deployments.

• breakingOperator users with `watchNamespaces` must verify RBAC after upgrade

  The fix for namespace-scoped role usage in the runtime operator changes which role bindings are applied when `watchNamespaces` is set. After upgrading, confirm your operator's RBAC permissions are correct and that it can still watch resources in the intended namespaces. A misconfigured role here means silent failures in component reconciliation.

• enhancementUse `wasi:tls` for native TLS in Wasm components

  WASI Preview 3 TLS support means you can now handle TLS connections directly inside Wasm components rather than relying on host-side termination or workarounds. If you're building components that make secure outbound connections, test against the new `wasi:tls` interface. This is early-stage — treat it as experimental in production until the WASI spec stabilizes further.

• enhancementUnblock CI pipelines with `--non-interactive` in `wash new`

  If you've been working around interactive prompts in `wash new` inside CI, this fix removes that friction. Update your pipeline scripts to use `--non-interactive` cleanly — no hacks required. Also worth re-examining your `wash config` flows now that validation and cleanup are built in.

wasmCloud v2.1.0 delivers operator reliability fixes, plugin support in services, and a wave of CI security hardening — a solid incremental release with a few operator-side changes worth watching.

• securityBump wasmtime and run cargo audit in your own builds

  wasmtime was bumped alongside the removal of rustls-pemfile and the addition of cargo audit to the build pipeline. If you build wasmCloud components from source or maintain forks, add cargo audit to your own CI now. The dependency surface for WASM runtimes shifts fast, and catching advisories early matters.

• breakingOperator readiness behavior changed — review your health checks

  The operator now only marks WorkloadDeployment as Ready when replicas are actually available. If your CI/CD pipelines or monitoring poll readiness status, they'll behave more correctly — but any tooling that relied on the previous optimistic Ready state may see deployments appear 'stuck' longer. Validate your rollout timeout thresholds after upgrading.

• enhancementPlugin support in services opens new extension patterns

  Services now support plugins, which means you can attach custom behavior at the service layer without forking core components. If you've been waiting to extend service behavior in a maintainable way, this is the release to experiment with. Start by reviewing the updated service plugin API in the docs before designing new integrations.

A maintenance release focused on operator reliability, security hardening, and CI improvements. Key fixes address NATS workload readiness and Kubernetes operator deployment status accuracy.

• securityWasmtime bump + cargo audit added — review your own Wasm supply chain

  This release bumps wasmtime and drops rustls-pemfile, while adding cargo audit to CI. If you're building custom wasmCloud components or providers in Rust, add cargo audit to your own pipelines now. The removal of rustls-pemfile suggests a dependency consolidation — check if any of your code directly imports it and update accordingly.

• breakingOperator WorkloadDeployment readiness semantics changed

  The Ready condition on WorkloadDeployment now reflects actual replica availability rather than just the existence of the deployment. Any automation or health checks that relied on Ready=True firing quickly after deployment creation will now correctly wait for replicas to be up. Review any CD pipelines or readiness probes that poll WorkloadDeployment status — they should now behave more accurately, but may appear 'slower' to reach Ready.

• enhancementNATS subscription readiness fix reduces false-positive healthy states

  Previously, hosts could report as ready before NATS subscriptions were actually established. After this fix, readiness is tied to actual subscription availability. If you're running wasmCloud in Kubernetes and using readiness gates or traffic routing based on host health, upgrade to get accurate readiness signals and avoid routing traffic to hosts that aren't yet fully connected.

A maintenance release focused on operator reliability, NATS subscription readiness, and security dependency bumps — no API changes, but a few fixes matter in production.

• securityUpgrade to pick up wasmtime security bump and new audit pipeline

  wasmtime was bumped and rustls-pemfile was removed as a dependency in this release. cargo audit has also been wired into CI, meaning future vulnerabilities in the dependency tree will be caught earlier. If you're running 2.0.5 or earlier, upgrade now — there's no reason to stay on an older wasmtime in a Wasm runtime.

• breakingOperator readiness behavior changed — review your health checks and rollout strategies

  WorkloadDeployment Ready status is now gated on replica availability, not just the existence of a deployment object. If your CI/CD pipelines or monitoring systems check for the Ready condition to gate traffic or proceed with rollouts, they'll now see a more accurate (and potentially longer) 'not ready' window. Verify your rollout wait conditions and alerting thresholds won't false-alarm during normal startup.

• enhancementNATS subscription readiness fix — relevant if you've seen premature ready signals

  The fix for NATS subscription workload readiness means the host now correctly waits before reporting ready. If you've dealt with race conditions at startup where components tried to subscribe before NATS connections were fully established, this should resolve those. No config changes needed — just upgrade and validate your startup sequence behaves as expected.

Patch release upgrading to Wasmtime 44 and fixing a pooling allocator crash, plus new glibc builds for GPU workloads on Linux.

• securityUpgrade if you hit pooling allocator crashes — the fix prevents silent failures

  The pooling allocator was being enabled without checking whether the host hardware actually supports it, which could cause runtime crashes or unpredictable memory behavior. If you've seen wash-runtime instability on certain host types, this fix directly addresses that. Upgrade and monitor memory allocation behavior post-deploy.

• breakingTest Wasmtime 44 upgrade in staging before rolling to production

  Wasmtime 44 is a major version bump for the underlying runtime. While wasmCloud wraps it, Wasmtime releases frequently carry behavior changes in memory handling, WASI interfaces, or component model semantics. Validate your component workloads in a non-production environment before upgrading clusters.

• enhancementGPU workloads on Linux now have proper glibc builds — start testing if relevant

  If you're running or planning wasmCloud workloads that touch GPU features on Linux, the new glibc builds resolve compatibility issues with standard Linux distributions that expect dynamically linked runtimes. Pull the new artifacts and validate against your target GPU host environment.

v2.0.4 is a minor maintenance release with TLS improvements for wash dev/host, a Helm chart fix for gateway routing, and governance updates.

• breakingCheck your Helm chart values if using local gateway routing

  The gateway is now disabled in values.local.yaml, and the hello-world example routes through a Kubernetes Service instead. If you forked or customized local Helm values with gateway-based routing, your setup may stop working after this update. Review your local values files against the updated defaults before upgrading.

• enhancementEnable TLS on wash dev/host if you're running local or production clusters

  TLS support now works across both wash dev and wash host. If you've been skipping TLS for local dev because it was unsupported, that excuse is gone. Test your TLS config in dev to catch certificate or connection issues before they surface in production.

v2.0.3 patches a NATS race condition, adds Kubernetes EndpointSlice support, hardens container security with non-root ownership, and expands Helm chart configurability.

• securityUpgrade now: containers finally run as non-root by default

  Previous releases ran with root ownership, which is a container security red flag. This release sets non-root ownership by default. If you have volume mounts or init containers with root-dependent file permissions, test before rolling to production — you may need to adjust fsGroup or runAsUser settings in your pod specs.

• breakingHelm chart image tag behavior changed — audit your values files

  The default image tag no longer falls back to a hardcoded value; it now uses the chart's appVersion. If you rely on overriding the tag in your values files, this likely works as-is. But if you were depending on the old default tag behavior for pinning, verify your deployed image versions after upgrading the chart.

• enhancementEnable EndpointSlice support if running Kubernetes 1.21+

  EndpointSlice is the modern replacement for Endpoints and scales better with large service backends. If your cluster runs Kubernetes 1.21 or later, enable this feature — it reduces load on kube-apiserver and avoids the scaling limits of the classic Endpoints API. Check your Helm values for the new endpointslice configuration option.

v2.0.2 is a focused patch: wasmtime runtime bumped to v43, a new Kubernetes Host pod reconciler added, and install scripts smoothed out.

• enhancementUpdate to pick up wasmtime 43 runtime improvements

  Wasmtime 43 includes upstream bug fixes and performance work. If you're running v2.0.1 in production, this is a low-risk upgrade worth taking. No API changes expected on the wasmCloud side — just redeploy your hosts.

• enhancementKubernetes operators: test the new Host pod reconciler

  The Host pod reconciler adds smarter lifecycle handling for wasmCloud hosts running as Kubernetes pods. If you're using the wasmCloud operator, deploy this in a staging cluster first and validate that host pod restarts and scheduling behave as expected before rolling to production.

• enhancementWindows users can now install wash via winget

  wash is now in the winget package registry. Windows-based teams can standardize installs with 'winget install wash' instead of manual binary downloads — useful for onboarding and CI pipelines on Windows runners.

v2.0.1 is a minor housekeeping release — migrates the runtime-operator Go module to v2, regenerates protos, and cleans up a temporary go.work workaround.

• breakingUpdate import paths if you import the runtime-operator Go module

  The runtime-operator Go module moved to a v2 module path. Any Go code importing it directly must update import paths to include the /v2 suffix. If you're only running wasmCloud as an operator and not importing the module in your own code, no action is needed.

• enhancementUpgrade from v2.0.0 if you hit proto or lint issues

  This patch fixes regenerated protos and removes a temporary go.work shim that may have caused inconsistencies in local development builds. If you were building the operator from source against v2.0.0, pull this patch to avoid stale proto or dependency resolution issues.

wasmCloud v2.0.0 is the stable release of the v2 runtime, bringing HTTP/2+gRPC support, OpenTelemetry metrics, wasmtime 42, and a security fix for RUSTSEC-2026-0007.

• securityPatch RUSTSEC-2026-0007 by upgrading immediately

  The lock file was updated to address RUSTSEC-2026-0007. If you're running any pre-v2.0.0 build, treat this as a mandatory upgrade. Check your supply chain tooling (cargo-audit, Dependabot) to confirm the vulnerable dependency is resolved in your environment.

• breakingHelm users: CRD path changed, update your GitOps pipelines

  CRDs were moved from templates/crds to a top-level /crds directory. This is a structural change that will break ArgoCD, Flux, or any Helm-based GitOps pipeline that references the old path. Before upgrading, verify your Helm release and CI/CD tooling point to the new CRD location.

• enhancementEnable metrics now — observability is first-class in v2

  OpenTelemetry metrics support is included out of the box. If you're already running an OTEL collector, wire up wasmCloud v2 to it and start collecting runtime metrics. This is the right time to establish baseline dashboards before rolling this to production, not after.