Higress: the Ingress controller that became an AI gateway
Envoy and Istio underneath, Wasm plugins instead of Lua, and a pivot to MCP hosting that happened in about a year
I went looking at Higress in March because I wanted one thing gone: the stack where an L7 load balancer feeds an Ingress controller which feeds an API gateway, three components, three configs, three teams to page. Higress collapsed all three into one process on top of Envoy, and that was the whole pitch.
I went back to it this month and barely recognised the front page. It now calls itself a production-grade AI gateway for agent development and LLM API management. Same project, same Envoy core, completely different sales pitch.
That gap is worth a few minutes, because it tells you something about where gateways are going - and because the original reason to look at it still holds.
What it actually is
An API gateway built on Envoy, with Istio's traffic-management model underneath, that runs as your Kubernetes Ingress controller. The important part of that sentence is the part that isn't there: you don't have to install a service mesh. You get Istio's config machinery for routing without sidecars everywhere and without the operational weight that stops most mesh rollouts halfway.
It speaks HTTP/3, gRPC and Dubbo, and it reads service registries directly - Nacos, ZooKeeper, Consul, Eureka - which matters if your services aren't all Kubernetes-native and you've been gluing registry-to-Ingress adapters together by hand.
The Wasm decision
The extension model is where Higress made its actual bet. Kong and APISIX extend through Lua. Higress extends through WebAssembly, so a plugin can be written in Go, Rust, C++ or TypeScript.
The language list gets quoted a lot, but it's the second-order effect that changed my mind: a Wasm plugin runs in a sandbox. A plugin that panics takes down a request, not the gateway. Anyone who has had a Lua filter take out an ingress tier at 3am understands why that's worth a rewrite.
Config applies without a reload, which is the other thing Nginx-based gateways make you plan around.
The AI turn
Here's what changed since March, and it's not cosmetic.
Higress now sits in front of model providers the way it used to sit in front of microservices: protocol conversion across model APIs so you write one integration instead of one per vendor, fallback to a second model when the first one errors, semantic caching, and token-level accounting so LLM spend stops being a single opaque line on the invoice.
Then the part I keep thinking about: it hosts MCP servers, and it converts existing HTTP APIs into MCP servers. Your internal APIs become tools an agent can call, and the gateway handles auth, traffic scheduling, parameter mapping and audit on the way through.
Think about what that means operationally. Every organisation that lets agents call internal services will need exactly that layer - identity, rate limits, an audit trail of which agent called what. Most teams are currently building it as bespoke glue in whatever framework their AI team picked. Higress is arguing it belongs in the gateway you already run, next to your ingress rules, and that argument is a lot stronger than it sounds at first pass.
Where it stands
The project moved out of the alibaba GitHub org into its own higress-group, which is the kind of unglamorous governance change worth noticing - single-vendor projects that survive usually make that move, and the ones that don't usually stall. It's Apache 2.0, around 8.9k stars, v2.2.3 landed at the end of June, and commits are steady.
The honest caveat is gravity. The registry integrations, the docs, the reference deployments - the centre of mass sits in the Alibaba Cloud ecosystem. That's not disqualifying, and nothing here is locked to it, but you'll spend more time on the unlit path than you would with ingress-nginx, and your search results will be in Chinese more often than not.
Would I put it in front of prod
For a plain Kubernetes ingress with nothing special going on: no. That's a boring problem with boring solutions, and boring is the correct answer for the component every request passes through.
For a team that already runs Envoy and wants extensions in a real language, or one that's about to build the auth-and-audit layer between agents and internal APIs from scratch: yes, at least as far as a proof of concept. The second case is the interesting one, because the alternative isn't another gateway - it's a pile of bespoke middleware nobody wants to own two years from now.
I'd still run it beside the existing ingress before I'd run it instead of one. Gateways are the wrong place to find out you were an early adopter.
Links
Questions? Feedback? Reply to this email. I actually read them.
- Ilia