Envoy (Wasm)
WasmEnvoy is a C++ L4/L7 proxy originally built at Lyft, now the de facto data plane for service mesh (Istio, Consul Connect) and API gateway use cases.
What it is
Envoy is a C++ L4/L7 proxy originally built at Lyft, now the de facto data plane for service mesh (Istio, Consul Connect) and API gateway use cases. The "Wasm" angle here refers to Envoy's WebAssembly extension system (proxy-wasm), which lets you write custom filters — auth logic, header manipulation, custom telemetry, rate limiting — in Rust, C++, Go, or AssemblyScript, compile to a .wasm module, and load it into the proxy without recompiling Envoy or restarting the process.
This matters because Envoy's native extension model requires C++ and a full rebuild. Wasm gives you a sandboxed, hot-swappable alternative — you ship a module, Envoy loads it via EnvoyFilter (in Istio) or its native Wasm config API, and it runs isolated from the host process.
Who builds it and why
Envoy itself is a CNCF project (graduated) with 1,652 contributors — this is not a side project, it's core infrastructure with backing from Google, Salesforce, Lyft, Tetrate, and others who run it in production at scale. The Wasm extension path specifically was pushed hard by Google and Tetrate to solve the "everyone forks Envoy to add one filter" problem that plagued early service mesh adopters.
Real motivation: mesh operators wanted a way for platform teams to ship custom logic to app teams without owning an Envoy fork, and without giving app teams C++ write access to the data plane.
Production readiness signal
Envoy core is battle-tested — it's been in production at Lyft, Google (via Istio/Anthos), Salesforce, Airbnb, and thousands of others since 2016. 28,505 GitHub stars and a commit as recent as 2026-07-01 show active maintenance. Latest release v1.38.3 indicates a mature, well-versioned release cadence.
The Wasm extension subsystem specifically has a rockier history: early versions (2020-2021) had real performance overhead and ABI instability between the proxy-wasm spec and Envoy's implementation. That's largely settled now — the ABI stabilized, and Istio ships Wasm-based extensions (like the metadata exchange filter) by default in production deployments. Still, expect more operational surface area than native filters: separate build toolchain, module versioning, and debugging that spans two runtimes (Envoy + Wasm VM).
Who should use this
- Platform teams running Istio or another Envoy-based mesh who need custom filter logic (custom auth headers, bespoke rate limiting, non-standard telemetry) without forking Envoy.
- Teams that want to ship filter updates independently of Envoy's release cycle.
- Organizations with Rust or Go expertise who don't want to write C++ to extend the proxy.
Who should NOT use this
- If you just need Envoy as a proxy/mesh sidecar with standard L7 routing, TLS termination, and observability — you don't need Wasm at all. Don't add complexity you don't need.
- Latency-critical paths where every microsecond matters: Wasm filters add measurable overhead vs. native C++ filters (though Envoy's proxy-wasm is faster than the old Lua/gRPC-based extension mechanisms it replaced).
- Small teams without dedicated platform engineering — building, versioning, and debugging Wasm modules across the proxy fleet is real operational work, not a weekend project.
- Anyone expecting a full plugin marketplace/ecosystem — Wasm module distribution and discovery for Envoy is still DIY; there's no equivalent to npm or Docker Hub for proxy-wasm modules.
Alternatives
- Native Envoy filters (C++) — more performant, but requires forking/rebuilding Envoy; right call if you control the full build pipeline and performance is paramount.
- Lua filters in Envoy — simpler scripting model for lightweight logic, no Wasm toolchain needed, but far more limited (no shared state across requests, weaker language ecosystem).
- NGINX with njs/Lua modules — if you're not already on Envoy/Istio, NGINX's scripting extensions are a lighter-weight alternative for basic request manipulation.
Pricing
Fully open source, Apache-2.0. No paid tier, no vendor lock-in on the extension mechanism itself. Cost is entirely in engineering time to build and operate.