A capability provider gives wasmCloud components access to an external service through a defined interface. Components import the interface in WIT, while deployment configuration links that import to a provider. This keeps application code focused on requests and responses rather than the backing storage system or machine-learning runtime. section 6.6.1 section 9.1
Use a provider when a needed capability is outside standardized WASI support or must connect to a particular system. wasmCloud supports third-party providers with custom WIT interfaces, making proprietary integrations and specialized capabilities configurable parts of an application deployment. section 6.5.2 section 6.6.2
A provider integration has three connected pieces:
- Declare the capability interface as a WIT import. The SmartCMS backend imports `wasi:keyvalue` storage interfaces and later imports `thomastaylor312:ollama/generate`. section 6.6.1 section 6.6.2
- Package or select a provider that exports the matching interface. The Ollama provider is a Rust provider artifact whose WIT world exports `generate`. section 6.6.2
- Deploy the provider and link the component interface to it in `wadm.yaml`. A link targets the key-value provider; the Ollama artifact is declared as a capability. section 6.6.1 section 6.6.2
Storage and story generation in SmartCMS
The HTTP component opens a default key-value bucket to store and retrieve stories through the linked `wasi:keyvalue` provider. For `/api/generate`, it calls the custom Ollama `generate` interface, combines the prompt with the response, and stores the generated story in that same bucket. The component depends on interfaces; providers handle storage and inference behind those links. section 6.6.1 section 6.6.2
Providers are an extensibility trade-off. Spin favors minimal configuration and broad SDK/template support, while wasmCloud is suited to fine-grained configuration and integrations that need custom capability providers. Not every desired interface has an out-of-the-box wasmCloud provider: `wasi:nn`, for example, is handled here through a third-party Ollama provider instead. section 6.5.2 section 6.6.2
Figure 9.1 Final architecture of SmartCMS deployed in Kubernetes. The frontend interacts with a wasmCloud host via an HTTP server. Inside the host, Wasm components use capability providers for storage and ML. The ML provider delegates inference to Ollama, while persistent storage is handled by kvnats.
The architecture shows the boundary clearly: components use storage and ML providers inside a wasmCloud host; the ML provider delegates inference to Ollama and storage is handled by kvnats. section 9.1
