リリース

wasmCloud v2.5.0 はフィーチャーリリースです。wasmtime 46 への更新と wasip3 のデフォルト有効化、wasmcloud:keyvalue bucket WIT の破壊的変更、および quinn-proto の MEDIUM セキュリティ修正 (RUST-SEC-2026-0185) が主な変更点です。wasmcloud:keyvalue を利用しているコンポーネントは WIT の対応が必要です。

• securityquinn-proto のセキュリティ修正 (RUST-SEC-2026-0185)

  MEDIUM 深刻度の rust-sec-2026-0185 (quinn-proto) を修正しています。QUIC 通信を利用する環境では v2.5.0 へ更新してください。

• breakingwasmcloud:keyvalue bucket のWIT定義が破壊的変更

  wasmcloud:keyvalue の bucket 型がインターフェースごとのインライン定義から共有 types インターフェース経由の定義に移動しました。wasmcloud:keyvalue WIT を利用するコンポーネントやプロバイダは WIT の修正とリビルドが必要です。

• breakingwasip3 がデフォルト有効化

  wasip3 が v2.5.0 からデフォルトで有効になりました。wasip3 対応外のワークロードで予期しない動作が発生する場合は、設定で明示的に無効化してください。

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.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.