wasmCloud is an off-the-shelf host platform for distributed WebAssembly component applications. It runs components without requiring a custom host for each application, while supplying developer tooling, application manifests, capability providers, and links between components and the capabilities they use. This leaves application code focused on business logic rather than host setup, interface linking, and operational plumbing. section 6.0 section 6.7
A wasmCloud application is described as an application manifest and assembled from components plus capabilities. A component can expose an HTTP handler, while capability providers supply services such as HTTP serving, NATS-backed key-value storage, or a custom machine-learning interface. Links declare which interface connects a component to a provider; the manifest also declares component images and deployment behavior. section 6.1 section 6.6.2
Start with an HTTP component
Create a Rust component with wash, target wasm32-wasip2, and export wasi:http/incoming-handler from its WIT world. The generated component returns an HTTP response; wash builds it into a Wasm artifact, starts local platform services, and deploys the wadm.yaml application definition. An HTTP server capability then routes requests to the component. section 6.1
Listing 6.4 wadm.yaml file (template comments/annotations hidden)
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: rust-hello-world
# ...
spec:
components:
- name: http-component
type: component
properties:
image: file://./build/http_hello_world_s.wasm
traits:
- type: spreadscaler #1
properties: #1
instances: 1 #1
- name: httpserver #2
type: capability #2
properties: #2
image: ghcr.io/wasmcloud/http-server:0.23.2 #2
traits:
- type: link #3
properties: #3
target: http-component #3
namespace: wasi #3
package: http #3
interfaces: [incoming-handler] #3
source_config: #3
- name: default-http
properties:
address: 127.0.0.1:8000
The manifest makes the composition explicit: it declares the component artifact, a spreadscaler instance count, an HTTP server capability, and the wasi:http incoming-handler link between them. section 6.1
Capabilities can be added without embedding their implementation in the application component. A counter endpoint opens a default wasi:keyvalue bucket and atomically increments a counter; its component is linked to a NATS key-value provider. Rebuilding and redeploying updates the application, and the stored count remains after the local host is stopped and restarted. section 6.2.2
Scaling is configured through the spreadscaler trait. Replicas may run across multiple hosts connected by a NATS lattice, with placement based on host labels such as zones. Weighted spreads can place replicas across regions, load balance requests among available replicas, and retain shared storage access through the key-value provider. section 6.4 section 6.7
SmartCMS with storage and generation
A SmartCMS component serves create, retrieve, and generate routes. It links to NATS-backed key-value storage and imports a custom Ollama WIT interface through a third-party provider. The generate route requests a story, assigns it a counter-based name, stores it, and returns the generated result. The same application configuration spreads 100 instances across two labeled hosts. section 6.6 section 6.6.2
wasmCloud can also run in Kubernetes, but it takes a platform-layer approach rather than extending the container runtime. The cluster runs wasmCloud hosts, NATS, and wadm as services; a WasmCloudHostConfig creates a host, and application manifests deploy workloads through that environment. Kubernetes can provide scheduling and resiliency while wash remains useful for inspecting hosts and application status. section 8.3 section 8.3.2
