Apache APISIX vs Envoy Gateway

The extensibility and identity model decides most shortlists between these two gateways. APISIX ships more than 100 built-in plugins covering authentication, security, traffic control, observability and AI gateway functions, and the openid-connect plugin is attached to routes like any other plugin. An OIDC flow, token introspection or a rate limit is therefore configured in the same catalog and the same route definitions, which suits a team that wants authentication and traffic policy managed through one vocabulary. Envoy Gateway takes a different route: it expresses JWT, OIDC, external authorization, mutual TLS, IP allow and deny lists, CORS and rate limiting through its own policy resources attached to Gateway API objects, and it reaches custom logic through Wasm, Lua, external processing or an extension server. That suits a team that already standardizes on Gateway API policy objects and wants a single extension model for custom behavior.

Whichever platform you choose, the identity provider work stays with your team. Confirm how each gateway handles the things that break in production: token lifetimes and refresh behavior, claim mapping into upstream headers or authorization decisions, and the choice of rate limit keys (client, consumer, IP or a claim), since a poorly keyed limit can throttle a whole tenant or let one caller bypass it. APISIX documents support for identity providers such as Keycloak, Microsoft Entra ID and Okta, and Envoy Gateway's OIDC and JWT support should be checked against your own provider's discovery document and key rotation. Build a test matrix with expired tokens, revoked sessions, missing claims and bursts from a single client, and run it against your actual IdP and not a lab stub. The APISIX openid-connect plugin documentation lists the supported flows to compare against your requirements.

Both gateways are free to download and run. Apache APISIX is Apache-2.0 and Envoy Gateway is Apache-2.0, so the license line on a quote should be zero for either one. What you pay for is everything around the software: the infrastructure that holds configuration, the people who operate it, the upgrades you take, and any external support you buy. For APISIX, the configuration store is the main infrastructure line. In traditional and decoupled modes, etcd is a stateful cluster you must size, back up and keep healthy, and the decoupled topology shares one etcd cluster across the data and control planes. For Envoy Gateway, the control plane runs as a workload in your Kubernetes cluster, so its cost falls mostly on cluster capacity and on the Gateway API resources your team must write and review. Standalone APISIX removes etcd entirely, which lowers that line but moves change control onto files or API calls you own.

The skills line is where the two platforms diverge most. Customizing APISIX means Lua for in-process plugins, or running an external plugin runner in Java, Go or Python, so you pay for engineers who can debug worker-level behavior in NGINX and ngx_lua. Envoy Gateway customization means knowing the Gateway API resources and the extension options the project documents, such as external processing or an extension server, which is a different and often more Kubernetes-native skill set. Upgrade effort recurs on both sides. Confirm the release cadence and support windows you will accept, then budget for regression testing against your own routes and plugins with each minor release. Certificate and secret rotation, monitoring of the gateway and its data path, and on-call coverage recur indefinitely and usually cost more than the first deployment.

Plan the one-time work separately from the recurring work. One-time items include the design of routes and authentication, the build-out of custom plugins or extensions, identity integration (for example, the openid-connect plugin against your identity provider, or Envoy Gateway's JWT and OIDC policies), and migration from existing ingress. Ask any vendor or integrator for a written quote that lists the plugins or extensions in scope, each identity provider to integrate and the flows you need, the number and type of test environments, the upgrade windows and rollback expectations, and who handles on-call. Ask whether the quote covers etcd or control plane operation, certificate handling and documentation. Fixed-scope quotes make these lines comparable across the two platforms.

Implementing Apache APISIX on Kubernetes means building the platform before any route goes live: the cluster, the chart or GitOps pipeline that deploys the gateway, TLS certificates, DNS records and the Admin API access model. Choose the deployment mode early, because traditional mode puts etcd in the configuration path, decoupled mode shares one etcd cluster between data and control planes, and standalone mode reads conf/apisix.yaml or conf/apisix.json instead. On the Envoy Gateway side, the same platform work centers on Gateway API resources, Helm or Argo CD or Flux CD installation, and the controller's own certificates and namespaces. In both cases, the team that owns the cluster should own the pipeline, and the reader should confirm with the vendor how each component is upgraded in place.

Most of the effort after the platform is identity, policy and testing. For OIDC, confirm that the identity provider's claim names match what the gateway expects for roles, audiences and subjects, since claim mismatches are a frequent cause of delayed go-lives on both sides. Rate limiting is another common source of rework: counters kept per gateway instance will not match the intent of a per-client limit once you run several replicas, so confirm how each option keys and shares limit state before you write policies. Custom extension code needs its own tests on both platforms. APISIX plugins can be written in Lua or run through external plugin runners, and Envoy Gateway supports Wasm, Lua, external processing and an extension server, so budget for test suites, build pipelines and upgrade checks for that code. Load and failover tests should run against the real identity and rate limit paths, not a stub.

Version compatibility is the delay teams most often underestimate. Envoy Gateway publishes a compatibility matrix across its own releases, Envoy Proxy and Kubernetes versions, so check that matrix against your cluster before choosing a release, and confirm your Gateway API CRD version with the controller. APISIX and its Ingress Controller ship on separate release lines, so track both, and confirm which APISIX Ingress Controller release matches your APISIX version and your Kubernetes version. Build these checks into the change process so that a routine cluster upgrade does not become an unplanned gateway upgrade.