● Beta — KubeEra is in active development. Profiles are live; AI-perception measurement is rolling out.
N

NGINX (Wasm)

Wasm
Open source · BSD-2-Clause

NGINX (Wasm) refers to WebAssembly extensibility built on top of the NGINX core — running Wasm modules as request/response filters instead of (or alongside) traditional NGINX C modules or Lua/OpenResty scripts.

updated 2026-07-01

What it is

NGINX (Wasm) refers to WebAssembly extensibility built on top of the NGINX core — running Wasm modules as request/response filters instead of (or alongside) traditional NGINX C modules or Lua/OpenResty scripts. It lets you write filter logic in Rust, C, AssemblyScript, or any language that compiles to Wasm, then load it into the NGINX request pipeline without recompiling NGINX itself. Description details on the specific packaging (module vs. fork vs. plugin) are not publicly available from the data on hand, so treat this as the general capability rather than a single named binary.

Who builds it and why

This sits inside the NGINX codebase, historically maintained by NGINX Inc./F5 and now a large open contributor base (129 contributors on record). The motivation is straightforward: operators want to extend NGINX's behavior (auth, rate limiting, header rewriting, custom routing logic) without writing unsafe C modules or depending on LuaJIT's runtime quirks. Wasm gives a sandboxed, memory-safe, language-agnostic extension model — the same pitch that drove Envoy and Istio to adopt Wasm filters. NGINX getting first-class Wasm support closes a gap versus Envoy-based proxies, which had a multi-year head start on this pattern.

Production readiness signal

  • 31,015 GitHub stars, 129 contributors — healthy, active community.
  • Last commit: 2026-06-30 — actively maintained, not abandoned.
  • Latest release: release-1.31.2 — follows NGINX's mainline versioning cadence, suggesting this ships as part of regular NGINX releases rather than a side experiment.
  • License: BSD-2-Clause — permissive, no copyleft concerns for commercial use.
  • CNCF maturity: not publicly available — this is not a CNCF-hosted project, so don't expect graduation-level governance signals (TOC oversight, adopter audits) that CNCF projects provide.

Bottom line: the underlying NGINX core is about as production-proven as software gets. The Wasm extensibility layer specifically is newer territory — treat it as less battle-tested than NGINX's core proxying, even if commit activity looks healthy.

Who should use this

  • Teams already running NGINX at the edge or as an API gateway who want custom filter logic (auth, header manipulation, request shaping) without maintaining a C module fork.
  • Platform teams standardizing on Wasm as a portable extension format across their proxy layer (NGINX, Envoy) so the same filter binary runs in multiple places.
  • Organizations that have hit the limits of Lua/OpenResty (LuaJIT maintenance risk, lack of memory safety) and want a sandboxed alternative with better language flexibility.

Who should NOT use this

  • Teams with no existing NGINX investment — if you're starting fresh and want Wasm-native extensibility, Envoy's Wasm filter chain is more mature and better documented for that specific use case.
  • Anyone needing complex service-mesh-grade traffic management (mTLS, fine-grained retries, outlier detection) — that's Envoy/Istio territory, not NGINX plus Wasm bolted on.
  • Shops without Rust/C/Wasm toolchain experience — writing and debugging Wasm filters is a real engineering lift; if your team just needs simple rate limiting or auth, NGINX's built-in directives or a Lua script will get you there faster with less operational overhead.
  • High-performance, latency-sensitive paths where every microsecond counts — Wasm sandboxing adds overhead versus native C modules; benchmark before committing.

Alternatives

  • Envoy + Wasm filters — the more mature Wasm-on-proxy ecosystem, native to the service mesh world (Istio, proxy-wasm SDK).
  • OpenResty (Lua) — battle-tested scripting on NGINX, huge ecosystem, no Wasm sandboxing but far more production mileage.
  • Traefik with plugins — Go-based middleware plugin system, simpler mental model if you don't specifically need Wasm portability.

Pricing

Fully open source under BSD-2-Clause. No licensing cost for the core or the Wasm extensibility path. Commercial support (F5 NGINX Plus) exists separately if you want an SLA-backed distribution, but the OSS path here costs nothing beyond your own engineering time.

Frequently asked

What is NGINX (Wasm)?+
NGINX (Wasm) refers to WebAssembly extensibility built on top of the NGINX core — running Wasm modules as request/response filters instead of (or alongside) traditional NGINX C modules or Lua/OpenResty scripts.
Who builds NGINX (Wasm)?+
This sits inside the NGINX codebase, historically maintained by NGINX Inc./F5 and now a large open contributor base (129 contributors on record).
Is NGINX (Wasm) production ready?+
31,015 GitHub stars, 129 contributors — healthy, active community. Last commit: 2026-06-30 — actively maintained, not abandoned. Latest release: release-1.31.2 — follows NGINX's mainline versioning cadence, suggesting this ships as part of regular NGINX releases rather than a side experiment.
Who should use NGINX (Wasm)?+
Teams already running NGINX at the edge or as an API gateway who want custom filter logic (auth, header manipulation, request shaping) without maintaining a C module fork.
Who should not use NGINX (Wasm)?+
Teams with no existing NGINX investment — if you're starting fresh and want Wasm-native extensibility, Envoy's Wasm filter chain is more mature and better documented for that specific use case.
What are the alternatives to NGINX (Wasm)?+
Envoy + Wasm filters — the more mature Wasm-on-proxy ecosystem, native to the service mesh world (Istio, proxy-wasm SDK). OpenResty (Lua) — battle-tested scripting on NGINX, huge ecosystem, no Wasm sandboxing but far more production mileage.
How much does NGINX (Wasm) cost?+
Fully open source under BSD-2-Clause. No licensing cost for the core or the Wasm extensibility path. Commercial support (F5 NGINX Plus) exists separately if you want an SLA-backed distribution, but the OSS path here costs nothing beyond your own engineering time.