proxy-wasm is the ABI that lets one extension run in five different proxies

A specification, not an implementation

This repository contains a specification, and that single fact shapes everything about how you should evaluate it. There is no proxy here, no runtime and no SDK code to install. What is here is the definition of the low-level Application Binary Interface and the conventions to use between L4 and L7 proxies, or other host environments, and their extensions delivered as WebAssembly modules. The repository layout is correspondingly thin: a `CHANGELOG.md`, a `CONTRIBUTING.md`, a `LICENSE`, a `docs/` directory and an `abi-versions/` directory that holds the versioned documents. The primary language is not even identified, which makes sense for a document. So the audience is two-sided. Proxy authors read it to know what a host must expose. Extension authors read it to know what they may call. Neither group needs this repository to run anything, and both groups need it to agree on the same bytes on the wire between them.

The versioned ABI directory is the real interface

The version handling is where the design decision shows. The README names v0.2.1 as the latest and widely implemented version of the specification, and links it to a file under `abi-versions/v0.2.1/README.md`. So the versioned documents live in the tree, keyed by ABI version, and a given extension is written against a specific one. That directory layout is a promise about compatibility: a host that implements v0.2.1 can load a module built for v0.2.1, and a module that depends on a different ABI version is a different contract rather than a slightly different build. The `CHANGELOG.md` at the root is the record of what changed between those versions. The practical consequence for an extension author is that the version number is part of your build inputs, not decoration, and that a proxy announcing support for one ABI version will not necessarily run a module built for another. This is the same discipline as a C ABI version, applied to a component model that is much younger.

One extension, five server implementations

The reason a specification exists at all is the list of implementations. The host environments are split into servers and libraries. The servers are ATS, Envoy, NGINX, MOSN and OpenResty, and the links in the README point to the specific integration for each, which for NGINX and OpenResty is a wasm module in the NGINX and OpenResty ecosystem, and for MOSN the project repository itself. The libraries are separate again: a C++ Host, a Go Host and a Java Host, with the Go host living under the MOSN organisation. That list is the argument for proxy-wasm in one sentence. Writing an extension natively against Envoy's extension API gives you Envoy. Writing it against the proxy-wasm ABI gives you a module that the same way across five proxies, assuming each host implements the same ABI version. The alternative is maintaining several near-duplicate extension builds, one per proxy, and keeping them in step as the hosts change.

SDKs in four languages, and where the design came from

The language story is a set of four SDKs. There is an AssemblyScript SDK, which is the solo-io proxy-runtime project, a C++ SDK, a Go SDK and a Rust SDK, with the C++, Go and Rust ones under the proxy-wasm organisation. The C++ and Go SDKs and hosts living under the same organisation as the specification is worth noting, because it means the reference implementation and the specification are maintained together, and a change to one tends to land with the other. The README is explicit about the origin. The event-driven streaming APIs and the convenient utility functions were originally developed for the WebAssembly in Envoy project, and the document about that lives in this repository at `docs/WebAssembly-in-Envoy.md`. What happened next is the important part for a user: the APIs were then made proxy-agnostic, so consumers can use the same Proxy-Wasm extensions across different proxies. The abstraction was extracted from a specific host and generalised into a portable contract.

The limits of a lowest common denominator ABI

Here is the trade-off the specification implies without spelling out. A lowest common denominator ABI is by definition the intersection of what the participating hosts can offer, and the hosts are not identical. Envoy has the richest extension surface, and the README's own history, the APIs having been developed for Envoy first, means the earliest and most specific capabilities tend to be Envoy-shaped. When a capability is not in the common ABI, an extension either forgoes it or falls back to something host-specific, and at that point the portability guarantee you bought with proxy-wasm starts to erode. There is a second cost. The ABI is low-level, which means the extension talks to a host through a defined calling convention rather than a friendly library, and the SDKs are where the ergonomics live. The choice of SDK therefore becomes part of your build story, and it is a decision the repository does not make for you. A third, quieter limit is that the specification is versioned but the ecosystem of extensions and hosts moves independently of it, so your real compatibility surface is the intersection of ABI version, host and SDK.

A small repository with a community around it

The repository is small by design and the surrounding community is the interesting part. There is a Proxy-Wasm Slack workspace linked from the README, and the README invites people to join and engage with the community there. Beyond that, the project is reachable through the implementations themselves: the SDK repositories, the host libraries, and the five server projects each maintain their own Proxy-Wasm support. The licence is Apache 2.0, which is the permissive licence with an explicit patent grant, and it is the right fit for a specification that both host implementers and extension authors will build on, because it lets an extension be distributed in a proprietary product without the copyleft obligations that would apply under a reciprocal licence. The maintenance picture is a single spec repository with the last push on 2026-08-11, no GitHub releases, and versioned documents checked into the tree under `abi-versions/`. There is no tag to pin, so pinning means pinning to an ABI version directory, and there is no homepage to point at, so the documentation is the repository.

Editorial conclusion

Adopt proxy-wasm when you want to write one extension that runs unchanged across Envoy, NGINX, OpenResty, MOSN and ATS, or when you are building a host environment that wants to accept third-party extensions. Skip it if you only serve one proxy and can use that proxy's own extension API, since the portability is the reason to accept the ABI constraints. Before you commit, read the v0.2.1 ABI document and pin to that version, and check the CHANGELOG.md, because the specification changes and an extension built against a different ABI version will not behave the same.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. proxy-wasm/spec on GitHub
4. README