WASM extensibility support

[anyflow]

kgateway version

latest

Context

Following a recent discussion with @yuval-k in Slack channel, I’m opening this issue to gather broader community feedback before exploring a concrete design.

Is your feature request related to a problem? Please describe.

Yes.
When evaluating kgateway as a replacement for Istio Ingress Gateway or Istio Waypoint, I run into a limitation around extensibility. In particular, there is currently no supported mechanism to execute custom request-level logic (e.g. operation-level inspection, enrichment, or transformation) beyond what static configuration allows.

In my current Istio-based production environment, this gap is addressed using WASM extensions — for example, with the openapi-endpoint-filter (https://github.com/anyflow/openapi-endpoint-filter
) — to achieve OpenAPI operation-level observability and advanced request processing.

Describe the solution you'd like

I’d like kgateway to offer some form of extensibility that allows custom logic to be executed at the request level. One possible approach is supporting WASM-based extensions, similar to what exists in Istio, but the exact mechanism is open for discussion.

Describe alternatives you've considered

I’ve considered alternatives such as:

• Relying purely on routing-level constructs (e.g. route splitting or regex-based matching)
• Using transformation filters where applicable

However, these approaches either reintroduce duplicated matching logic or fall short for more complex scenarios. They also don’t fully cover cases where dynamic inspection or extensible processing is required.

Additional Context

From production experience, WASM does introduce real challenges (debuggability, memory behavior, maintenance cost). However, when used carefully and with a constrained scope, it has proven stable and valuable in practice.

This limitation currently prevents me from adopting kgateway, even though I’d like to, and it is something I would also need to keep in mind for AI Gateway–style use cases. I’m opening this issue primarily to gather community feedback and understand whether others see similar needs, and whether there’s interest in exploring a design that balances value with long-term maintainability.