There is not a single way of how Wasm modules are distributed. There are a lot of practical options because of their comparably small size. In Cloud-Native, OCI/Docker registries are a natural fit since they're required anyway for container images. Other viable options include the WebAssembly package manager WAPM that already serves WASI-compatible Wasm modules. Moreover, the Bindle project is another alternative that provides a modern infrastructure for distributing applications as a bunch of independent bundles with well-defined relationships between each of them.
Currently, this project only supports OCI registries and the format created by the wasm-to-oci tool (see roadmap). Other module sources can be represented in the invocation format without issue however:
- name: wasm
plugin:
wasm:
module:
# you would use one of these options
oci: ghcr.io/someone/somemodule:latest # already supported
wapm: syrusakbary/qr2text@0.0.1 # on the roadmap
bindle: example.com/stuff/mybindle/v1.2.3 # on the roadmap
There is not a single way of how Wasm modules are distributed. There are a lot of practical options because of their comparably small size. In Cloud-Native, OCI/Docker registries are a natural fit since they're required anyway for container images. Other viable options include the WebAssembly package manager WAPM that already serves WASI-compatible Wasm modules. Moreover, the Bindle project is another alternative that provides a modern infrastructure for distributing applications as a bunch of independent bundles with well-defined relationships between each of them.
Currently, this project only supports OCI registries and the format created by the
wasm-to-ocitool (see roadmap). Other module sources can be represented in the invocation format without issue however: