A wadm manifest is a declarative YAML application configuration for wasmCloud. It names components and capability providers, points to their images, sets deployment traits, and defines the links through which components use imported interfaces. This keeps application wiring outside the component binary: a component can request wasi:keyvalue access while the manifest selects and configures the provider that fulfills it. section 6.2.1 section 8.3.2
Treat the manifest like a deployment map. A component image supplies application behavior; capability entries supply services such as HTTP or key-value storage; link traits connect them by namespace, package, and interface. Provider choice can remain interchangeable when providers implement the same wasi:keyvalue interfaces, allowing a NATS-based store, Redis, or HashiCorp Vault to be selected with minor configuration changes rather than component-code changes. section 6.2.1
Listing 6.6 wadm.yaml (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
properties:
instances: 1
- type: link #1
properties:
namespace: wasi
package: keyvalue
interfaces: [store, atomics]
target: #2
name: kvnats
config: #3
- name: wasi-keyvalue-config #3
properties: #3
bucket: default #3
enable_bucket_auto_create: #3
➥'true' #3
#3
- name: httpserver
type: capability
properties:
image: ghcr.io/wasmcloud/http-server:0.23.2
traits:
- type: link
properties:
target: http-component
namespace: wasi
package: http
interfaces: [incoming-handler]
source_config:
- name: default-http
properties:
address: 127.0.0.1:8000
- name: kvnats #4
type: capability #4
properties: #4
image: ghcr.io/wasmcloud/keyvalue-nats:0.3.1 #4
This manifest excerpt shows a component image, a spreadscaler trait, and a link to the kvnats provider. The link grants the component's store and atomics interfaces a configured bucket target. section 6.2.1
A manifest can describe these practical deployment concerns:
- Component identity and artifact location through application metadata and a component image reference. section 6.6
- Instance count and host placement through a spreadscaler trait, including weighted zone requirements for a multi-host deployment. section 6.6
- Provider wiring through link traits, including the imported interface names and target-specific configuration such as a default bucket. section 6.2.1
- Container-ready deployment changes, such as registry image references and an HTTP address bound to 0.0.0.0. section 8.4.1
Moving SmartCMS from local hosts to Kubernetes
For SmartCMS, the manifest changes from a local component path and manually weighted zones to registry-hosted images and Kubernetes-oriented settings. Kubernetes takes over scheduling and fault tolerance, so the local zone-spread configuration is removed. The HTTP provider binds externally, and the Ollama provider is configured to reach its Kubernetes service rather than localhost. Apply the resulting file with kubectl apply -f wadm.yaml, then inspect the application with kubectl get app or wash app status. section 8.4.1 section 8.3.2
A manifest is environment-sensitive rather than entirely portable without edits. Local host simulation may use manually labeled zones and local files, while Kubernetes requires registry-accessible images and container networking settings. Conversely, Kubernetes replicas replace the local spread setup for scheduling and resiliency; a failed wasmCloud host can have its components migrated while Kubernetes restarts the failed pod. section 6.6 section 8.3.2
