Skip to content

Envoy Gateway

Summary

Envoy Gateway (EG) is the Envoy project's managed control plane for running Envoy Proxy as a north-south application gateway. It implements the Kubernetes Gateway API and adds its own policy CRDs (ClientTrafficPolicy, BackendTrafficPolicy, SecurityPolicy, EnvoyExtensionPolicy, EnvoyPatchPolicy, Backend, HTTPRouteFilter, EnvoyProxy). The current release line is v1.9 (v1.9.1, 2026-08-28), built on Envoy Proxy v1.39.x and Gateway API v1.6.1. It is Apache-2.0 licensed and lives under the Envoy project, a CNCF graduated project. EG is also the base layer for Agent Router (formerly Envoy AI Gateway) and a common landing zone for teams leaving the retired Ingress-NGINX controller.

Overview

Envoy Gateway replaces annotation-heavy ingress controllers with declarative Gateway API resources. A single controller (envoy-gateway) watches GatewayClass, Gateway, the xRoute kinds, and EG policy CRDs. It translates them through an internal IR into Envoy xDS and provisions one Envoy fleet per Gateway (or one shared fleet with merged Gateways). It runs on Kubernetes by default. An experimental standalone mode runs it on hosts or containers with a file provider.

It is not a service mesh. EG handles ingress (and egress through Backend) at the edge. East-west mTLS between workloads is the job of a mesh such as Istio or Linkerd. EG is one of several conformant Gateway API implementations. The Gateway API project itself does not name an official reference implementation, so older "reference implementation" wording in this vault overstates its status.

Key Facts

Attribute Detail
Latest Version v1.9.1 (2026-08-28); v1.8.4 (2026-08-28) on the previous line
Supported lines v1.9 (EOL 2027-02-14), v1.8 (EOL 2026-11-08); v1.7 reached EOL 2026-08-05
Release cadence Minor release roughly every 3 months (v1.7.0 2026-02-05, v1.8.0 2026-05-12, v1.9.0 2026-08-14); each minor supported about 6 months
Data plane Envoy Proxy distroless-v1.39.x for EG v1.9 (one Envoy minor per EG minor)
Gateway API v1.6.1 bundled with v1.9 (TCPRoute/UDPRoute reconciled as v1)
Kubernetes v1.33 to v1.36 tested for EG v1.9
EG API group gateway.envoyproxy.io/v1alpha1 (all EG CRDs are still v1alpha1)
Language Go (control plane), C++ (Envoy data plane)
License Apache 2.0
Governance Sub-project of Envoy (CNCF graduated); community maintainers from several vendors
Website gateway.envoyproxy.io
Stars ~7k+ (2026-07 figure)

Full version matrix, release dates, CRD list, ports, and advisories: Reference.

Architecture at a Glance

The controller's runners turn Gateway API and EG policy resources into xDS and Envoy infrastructure.

flowchart LR
    subgraph K8s["Kubernetes API"]
        GWAPI["GatewayClass, Gateway,<br/>HTTPRoute, GRPCRoute, TLSRoute"]
        POL["ClientTrafficPolicy<br/>BackendTrafficPolicy<br/>SecurityPolicy<br/>EnvoyExtensionPolicy"]
    end
    subgraph EG["envoy-gateway controller"]
        PR["Provider runner"]
        GT["Gateway API translator"]
        XR["xDS translator and server"]
        IR["Infra manager"]
    end
    subgraph DP["Data plane"]
        ENV["Envoy Deployment<br/>per Gateway"]
        RL["envoy-ratelimit<br/>(optional)"]
    end
    GWAPI --> PR
    POL --> PR
    PR --> GT
    GT -->|"xDS IR"| XR
    GT -->|"Infra IR"| IR
    XR -->|"delta xDS gRPC :18000"| ENV
    IR -->|"Deployment, Service"| ENV
    ENV -->|"rate limit gRPC"| RL
    ENV --> BE["Services, Backend CRD targets"]

How each runner works, the IR pipeline, and the policy attachment model: Explanation.

Extension APIs

CRD Purpose Attaches to
ClientTrafficPolicy Downstream settings: TLS, client IP detection, HTTP/1-2-3, timeouts, header handling Gateway, listener, ListenerSet
BackendTrafficPolicy Upstream settings: load balancing, retries, circuit breaking, health checks, local/global rate limits Gateway, xRoute, ListenerSet
SecurityPolicy JWT, OIDC, API key, Basic auth, ExtAuth, authorization (incl. CEL, GeoIP), CORS, CSRF Gateway, xRoute, ListenerSet
EnvoyExtensionPolicy Wasm, External Processing, Lua (off by default since v1.9), Dynamic Modules Gateway, xRoute, ListenerSet
EnvoyPatchPolicy JSON patches on generated xDS (disabled by default) GatewayClass, Gateway
Backend FQDN, IP, Unix socket, or dynamic-resolver backends (disabled by default) Referenced from routes
HTTPRouteFilter EG-specific route filters (regex rewrite, direct response, credential injection) HTTPRoute, GRPCRoute rules
EnvoyProxy Data-plane deployment and bootstrap settings GatewayClass, Gateway

Evaluation

Pros Cons
Conformant Gateway API implementation, backed by the Envoy project All EG CRDs are still v1alpha1; breaking changes land in most minor releases
Full Envoy feature set through typed policy CRDs instead of annotations Envoy config complexity is still underneath (EnvoyPatchPolicy and egctl help)
JWT, OIDC, API key, ExtAuth, mTLS, CORS, CSRF built in Not a mesh; no east-west mTLS between workloads
Wasm, ExtProc, Lua, Dynamic Modules, and extension-server hooks Short support window (about 6 months per minor) forces regular upgrades
Base layer for Agent Router (AI and MCP traffic) CRD upgrades are manual (Helm does not upgrade CRDs)
Standalone (non-Kubernetes) mode for hosts and containers Standalone mode is experimental and not for production

Fits well: platform teams standardizing on Gateway API, teams migrating off Ingress-NGINX who want Envoy features without Istio, and AI gateway deployments through Agent Router. Fits poorly: clusters that need a mesh for east-west traffic only, or teams that cannot keep up with a quarterly upgrade cycle.

Recent Developments (2025-2026)

  • v1.9.0 (2026-08-14): Gateway API v1.6.1, TCPRoute/UDPRoute via v1, ListenerSet as a policy target, native CSRF protection, CEL authorization rules, remote infrastructure provider, xdsNACKTotal metric, Lua disabled by default. v1.9.1 (2026-08-28) reverted the v1.9.0 0s SDS/RDS initial fetch timeout and fixed CVE-2026-47775 (OIDC cookie padding oracle); users on v1.8.x should skip v1.9.0. (v1.9 announcement, v1.9.1 notes)
  • v1.8.0 (2026-05-12): Envoy Dynamic Modules, multiple chained extension managers, mergeType for EnvoyProxy defaults, GeoIP authorization, retry budgets, admission control, cross-namespace policy attachment. (v1.8 announcement)
  • Envoy AI Gateway is now Agent Router (2026-09-10): the project joined the Agentic AI Foundation (AAIF). CRDs (aigateway.envoyproxy.io), the aigw CLI, images, and Helm charts are unchanged. v1.0 shipped in June 2026 and v1.1 in August 2026. Agent Router v1.0.x requires EG v1.8.1 or later. (announcement, compatibility)
  • Ingress-NGINX retirement: Kubernetes announced the retirement on 2025-11-11, and maintenance ended in March 2026. ingress2gateway 1.0 (2026-03-20) has an envoy-gateway emitter that outputs EG policy resources. See How-to: migrate from Ingress-NGINX.

Ecosystem and Alternatives

  • Downstream products: Tetrate Enterprise Gateway (TEG) and Calico Ingress Gateway are built on EG. See Calico.
  • AI gateway: Agent Router (formerly Envoy AI Gateway) runs its control plane on top of EG.
  • Alternatives: Istio's Gateway API support (Istio), kgateway, Cilium Gateway API, NGINX Gateway Fabric, Traefik. See the Service Mesh Comparison.
  • Lock-in: Core routing uses portable Gateway API resources. EG policy CRDs and EnvoyPatchPolicy are EG-specific.

Topic Map

  • How-to Guides: install, upgrade, routing, TLS, rate limiting, auth, Ingress-NGINX migration, standalone mode, egctl debugging, troubleshooting
  • Reference: compatibility matrix, release history, CRDs and targets, EnvoyGateway flags, ports, egctl commands, security advisories
  • Explanation: runners and IR pipeline, deployment modes, policy attachment and merging, rate limiting and extension architecture, security model, AI gateway relationship

Sources

Questions

Open

  • When will the EG policy CRDs graduate from v1alpha1 to a beta or v1 API? No public date as of 2026-09.
  • When will standalone mode leave experimental status? The v1.9 docs still say not to use it in production.
  • Which EG version does Agent Router v1.1 require? The compatibility page lists v1.0.x (EG v1.8.1+) but no v1.1 row yet.

Answered

  • Does EG replace Istio? No. EG handles north-south (ingress/egress) traffic. Istio and Linkerd handle east-west mesh traffic. They are complementary, and a common pattern runs EG at the edge with a mesh inside.
  • Is EG the official Gateway API reference implementation? No. It is one of many conformant implementations listed by the Gateway API project.