Higress v2.2.4 combines an API gateway with AI and MCP policy
Higress v2.2.4 is an Envoy data plane with an Istio-derived control plane, an administrative console, and a library of Wasm plugins. It can operate as a Kubernetes ingress controller or Gateway API implementation, route ordinary microservices, and apply authentication or traffic rules. The AI gateway adds provider routing, token-aware limits, caching, and observability. MCP support can publish tools behind the same authentication, rate limiting, and audit layer. That combination is useful when these jobs already belong to one platform team.
The scale of the source matches that ambition: our commit ce209a2 checkout held 24,353 files, roughly 3,366,577 lines of source, and 311.9 MB before dependency installation. Higress also points to separate repositories for its console, standalone package, plugin server, and Go Wasm SDK. This is a family of components, even though the all-in-one image makes the first screen look like one product. An evaluation should map which repositories, images, registries, and release versions will enter the production supply chain.
The 29 CI workflows cover a platform, not a small proxy
Our scan found 29 CI workflow files and a tests directory. The README offers three jobs that could each justify a dedicated project: ingress, a microservice gateway connected to registries such as Nacos or Consul, and an AI gateway for model APIs and MCP servers. Consolidation can reduce duplicated policy, but it also couples release and failure domains. A routing change, plugin update, or control-plane problem deserves the same review as any other edge infrastructure change because all downstream APIs may share it.
The repository contained about 3.37 million source lines in our 311.9 MB checkout, yet no root Dockerfile was detected. That is not a contradiction with the documented Docker quick start: the README tells users to pull a published all-in-one image from a Higress registry. For production Kubernetes use, it points to Helm and supports overriding the image hub. Operators who require private registries should mirror every chosen component and Wasm plugin image, then pin versions instead of treating the quick start's latest tag as a deployment plan.
What happened when we ran it
Our sandbox install ran for 78 seconds and failed with exit code 1. Go first attempted to download toolchain 1.26.0, then resolved a dependency replacement for github.com/envoyproxy/go-control-plane to the local path ./external/go-control-plane. Installation stopped because external/go-control-plane/go.mod was absent. The log does not say that the upstream Go module is broken, and it does not show a network or compiler failure. It shows that the checkout was not prepared with the local module expected by its own go.mod.
Because the install failed, our 3-CPU, 8 GB unprivileged container did not reach a build or test step. The repository explains the missing preparation outside the top-level quick start: the Makefile's prebuild target initializes Git submodules, and tools/hack/prebuild.sh copies Istio and Envoy trees into external/ before go mod tidy. That is a valid source workflow, but it differs sharply from running the published image. A contributor should follow the Makefile path and budget for nested upstream code rather than beginning with a generic Go dependency command.
Open v2.2.4 reports show why plugin combinations need tests
Open issue 4606 describes a specific v2.2.4 filter sequence where a custom Wasm plugin pauses a single-frame streaming response while a downstream external-processing filter resumes. The reporter receives an empty response body after the stream ends before the plugin's asynchronous callback returns. This is not evidence that normal streaming fails. It is evidence that filter ordering, pause and resume behavior, single-frame delivery, and external processors need an integration test built from the exact chain a team intends to deploy.
Our 78-second install failure meant we did not run the console, proxy traffic, MCP sessions, or a Kubernetes control plane. Issue 4609 adds a separate operating concern: its reporter says Ingress resources from several namespaces routed correctly, while the console displayed only resources from higress-system. A team using Git as its source of truth may accept that limitation. A team expecting the console to inventory every live route should reproduce it before letting operators depend on the screen during an incident.
The August 27 push and v2.2.4 release show active maintenance
GitHub recorded a push on August 27, 2026, and release v2.2.4 was published on August 13. That release covers the core gateway and console, including Gateway API work, MCP protocol examples, plugin release evidence, routing changes, and security checks. The repository had 9,216 stars and 1,082 open issues and pull requests when fetched. The combined count is not a bug count. Recent issue updates, design discussions, and release work show a busy project whose buyers need disciplined version selection.
The 24,353-file checkout and 29 CI workflows explain both Higress's appeal and its cost. Envoy Gateway is the cleaner comparison when Kubernetes Gateway API support is the main requirement. Apache APISIX and Kong suit teams whose existing plugin and operating models already match those gateways. Higress is the better trial when model providers and MCP tools genuinely need the same policy plane as ordinary APIs. Start with the all-in-one image for learning, then evaluate the submodule build, Helm topology, registry policy, console coverage, and custom filter chain separately.