Solo.io Borrows OCI Spec to Bundle WebAssembly Modules – InApps 2025

Following last year’s release of its WebAssembly Hub, Solo.io has released a proposal for a new WebAssembly (WASM) Open Container Initiative (OCI) image specification that it says will “define how to bundle WASM modules as OCI images to make it easy to build, pull, publish, and execute.”

Although Solo.io is concentrating on the use of WASM to extend service mesh functionality, portable WASM bundles could be a major step forward in ease of development. “If WASM+[a WebAssembly System Interface] 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,” Docker founder Solomon Hykes wrote in a recent Tweet.

Solo.io first launched the WebAssembly Hub in Dec. 2019 with a focus on extending the Envoy proxy, which forms the basis for its Gloo API Gateway. Last March, after Google and the Istio team reached out to Solo.io, the company expanded the focus of the WebAssembly Hub to include extending the Envoy proxy-based Istio service mesh, which had also added WASM extensibility. Solo.io describes the hub as providing “everything you need to build, publish, discover and deploy custom extensions for Envoy Proxy, Gloo and Istio.”

“While we were working on [the WebAssembly Hub], we learned quite a lot. We learned how to bundle WebAssembly. We knew that we wanted to do something like the Docker experience, and we decided the best way to do this is to take advantage of stuff that already exists, like the OCI spec,” said Solo.io founder and CEO Idit Levine in an interview. “Imagine that the OCI is a base class. You basically inherit OCI and extend it. The OCI spec is just very high level, not specific, and we want it to be more specific, because we feel that it will be better for the tooling, because then the tooling can take those metadata and basically say ‘Ahh, this is an Envoy spec!’”

The WASM Image specification defines an image that consists of a WASM binary file and a configuration file, with the configuration file consisting of a JSON object specifying the intended runtime for the module, the module’s runtime ABI compatibility, and opaque runtime-specific configuration. The description in the spec repository further clarifies that “the spec can be considered an extension of the OCI Image Spec designed specifically for use by applications which produce and consume WASM modules (as opposed to application containers).”

But is it an Image?

After the initial release, some members of the Open Container Initiative questioned the naming of the proposed spec, with OCI Technical Oversight Board member Steve Lasker writing “I think there’s a bit of confusion in the specific branding. If I understand it correctly, It’s technically not an OCI Image, rather [an] OCI Artifact type. It can be stored in a registry, like Singularity, Helm, OPA, etc. […] Either way, I wouldn’t call it an OCI Image as that does have a specific meaning.”

The topic of the WASM specification’s naming was a topic at this week’s OCI meeting, where Levine offers a full background on Solo.io’s offerings, which leads into a primer on WebAssembly as used by Solo.io in this instance, before diving into the spec itself.

In the meeting, Lasker seemingly decides on “OCI artifact” as a more correct terminology, saying “one of the things we were trying to bring to discussion was the term ‘OCI Image’ versus some others, because there’s meaning. […] From our perspective, I wouldn’t call in an ‘OCI Image’ because we think of the OCI image as being the runtime container image, kind of the platform-neutral Docker container, if you will.”

Levine explained during the discussion that Solo.io was ahead of the curve in their work with WebAssembly and that they wanted to propose a specification (the current version is v0.0.0) using their experience to try to prevent future potential issues.

“Building all of this, we realized one thing […] in cloud native, it tends to create a lot of, the politics and providers create a lot of misalignment. I think that misalignment is destroying innovation in my opinion,” said Levine. “Therefore, it was very important to me not to drag the community through another problem like that. We had it with container management, then we had it now with service mesh, and I really don’t feel that this is healthy.”

Naming and trademark aside, Levine offered that she sees this is just the very beginning, with this sort of extension seeing an uptick beyond Envoy and Istio, with the Open Policy Agent (OPA) and NATS also moving in this direction.

“I personally think that this is only the beginning. We needed it, this is something that we’re running with our customers in production, this is why we needed it,” said Levine. “In my opinion, this will be the future of cloud native: extending stuff.”

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.