Announcing the WebAssembly (wasm) OCI Image Spec

In recent years, WebAssembly (Wasm) has emerged and gained in popularity for platform extensions as a portable binary instruction format with an embeddable and safe execution environment for client and server applications, including popular cloud-native technologies. We are very excited about the potential of Wasm across the industry, and specifically as a way to extend an Envoy-based data plane in frameworks like API Gateways (Gloo) and Service Meshes (Istio, AppMesh, etc).

If WASM+WASI existed in 2008, we wouldn’t have needed to created Docker. That’s how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let’s hope WASI is up to the task! https://t.co/wnXQg4kwa4

— Solomon Hykes (@solomonstre) March 27, 2019

At Solo.io, we started with WebAssembly back in December 2019 when we announced tooling to improve the experience of working with Wasm in Envoy and in March 2020 evolved that tooling to support Istio 1.5 wasm extensions. Since December, we’ve been talking to our customers and partners about their interest in Wasm and worked with them to optimize the way the modules are bundled.

To broaden the collaboration, today we announce the WebAssembly OCI image specification as a community initiative to define a standard format to bundle and store Wasm modules and its metadata to facilitate interoperability.

The Wasm OCI Image Specification

Although our work on Wasm started with Envoy Proxy, the Wasm OCI Image spec is intentionally generic to be able to support any type of Wasm module including Envoy, OPA, the browser, and more. The purpose of the spec is to define how to bundle Wasm modules as OCI images to make it easy to build, pull, publish, and execute.

The Wasm OCI Image itself consists of a Wasm binary file, configuration file, and metadata for the target Wasm runtime. As each target Wasm runtime may have runtime-specific configuration parameters, the Wasm image bundles together two layers: a content layer for the module itself and a configuration layer with metadata for the target runtime. 

The configuration layer currently includes the following property descriptions: type, abiVersions, and config. Type is the name of the target runtime for the bundled module. abiVersions includes a list of ABI (Application Binary Interface) Versions for the target runtime with which the image is compatible. Lastly, config stores any configuration parameters required by the target runtime with a parameter structure dependent on the target runtime. 

As an example, the runtime configuration layer for Envoy Wasm images have the following format:

• type is set to envoy_proxy
• abiVersion is set to a recognized version of the Envoy Proxy WASM Filter ABI
• config is a JSON Object containing a list of filter root_ids that can be used with the provided filter

For end users interested in Wasm modules for different runtime targets, contributions to the spec on the required metadata assists in standardizing what’s needed to make sure that specific runtime targets can be used by anyone regardless of whether they built it or not.

Get involved

If you’re interested in WebAssembly, we invite you to check out and contribute to the WebAssembly OCI Image Specification here. You’ll also find SDKs and tools related to Wasm in addition to the spec in the project repo. 

Learn more about Wasm by watching videos and demos and joining the discussion in the community slack. Participate in the bi-weekly community meetings and register for an upcoming event. 

Ready to start building and sharing modules with the community? Visit the WebAssembly Hub and the tutorials in docs.