# Envoy Gateway: Gateway API resources for standalone and Kubernetes deployments > Envoy Gateway turns Gateway API resources into configuration for managed Envoy Proxy instances, in Kubernetes or standalone. The README points at a quickstart, a goals document and a compatibility matrix, but says little about upgrade mechanics or rollback. **envoyproxy/gateway** — Manages Envoy Proxy as a Standalone or Kubernetes-based Application Gateway. - Repository: https://github.com/envoyproxy/gateway - Website: https://gateway.envoyproxy.io - Stars: 3,054 · Forks: 885 - Language: Go - License: Apache-2.0 - Published: 2026-08-04 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/envoyproxy-gateway ## The gap Envoy Gateway fills between Gateway API and Envoy config Envoy Proxy is configured through xDS, a set of discovery APIs that a control plane serves to the proxy over gRPC. Writing that control plane yourself is the usual cost of adopting Envoy: you translate whatever your platform team considers a route into clusters, listeners and route configuration, then keep the translation correct as Envoy's API surface moves. Envoy Gateway exists to remove that translation layer for the common case. Its README describes it as an open source project for managing Envoy Proxy as a standalone or Kubernetes-based application gateway, where Gateway API resources are used to dynamically provision and configure the managed Envoy Proxies. The audience is therefore narrow and specific: platform engineers running Kubernetes who want Gateway API as the configuration surface, and teams running Envoy outside Kubernetes who still want the same resource model rather than raw xDS. If neither of those describes you, the project is solving a problem you do not have. ## How Gateway API resources become Envoy configuration The data flow is a control loop. You apply Gateway API resources, the controller watches them, and it provisions and configures Envoy Proxy instances to match. The README states that Gateway API resources are used to dynamically provision and configure the managed Envoy Proxies, which places the project firmly on the control plane side of the split: it is not a proxy, it is the thing that tells Envoy what to be. The repository layout supports that reading. There is an api/ directory for the project's own API types, a proto/ directory, pkg/ and internal/ for the controller and translation code, cmd/ for binaries, and charts/ for Helm packaging. The go.mod lists github.com/envoyproxy/go-control-plane and its envoy, contrib and ratelimit submodules, which is the xDS machinery a control plane needs to push configuration to Envoy. The same file pulls in github.com/envoyproxy/ratelimit and cel.dev/expr, and the examples/ directory contains envoy-ext-auth, grpc-ext-proc, extension-server, simple-extension-server and otel-headers, so extension points and rate limiting are part of the shape of the project rather than add-ons bolted on later. The examples/standalone and examples/kubernetes directories map directly onto the two deployment modes the README names. ## Installing Envoy Gateway and a first Gateway API route The README does not carry install commands. It links to a Quickstart task at gateway.envoyproxy.io/latest/tasks/quickstart/, and that page is where the actual steps live, so treat the site as the source of truth rather than this article. What the README does give you is the shape of the project: charts/ holds Helm packaging, cmd/ holds the binaries, and examples/kubernetes and examples/standalone hold manifests for the two modes. Because the quickstart is versioned under /latest/, pin the URL to the release you intend to run rather than following the floating path. The Compatibility Matrix linked from the README is the page that tells you which Envoy and Kubernetes versions a given release supports; check it before you install, not after. For the developer path, the Makefile is a wrapper: every real target lives under tools/make/*.mk, and running make help is the documented way to see what is available. That is enough to orient yourself, but the install itself is a documentation task, not something the repository README walks through. ## Where Envoy Gateway is the wrong tool The clearest limitation is the one the README implies rather than states: this is a control plane for Envoy, so it is only useful if Envoy is the proxy you want. A team standardized on a different data plane gets nothing from it. The second limitation is version coupling. Envoy Gateway trails Envoy and Kubernetes releases, and the project publishes a Compatibility Matrix precisely because the combinations are not arbitrary. If your platform requires the newest Envoy feature on the day it ships, this project will lag, and the matrix is where you will see by how much. The third is scope of documentation. The README covers documentation links, contact channels, contributing, security reporting and community meetings, but it does not document upgrade or rollback procedure. For a control plane that pushes configuration into a running proxy fleet, the absence of rollback guidance in the top-level README means you should look for it in the site's task or release documentation before you treat an upgrade as routine. None of this makes the project unsuited to its purpose; it makes it unsuited to teams that need a data plane other than Envoy, or that cannot accept a release cadence tied to another project's. ## Envoy Gateway compared with running Envoy directly The real alternative is not another gateway product, it is running Envoy yourself. In that approach you own the xDS server, or you generate static configuration, and you decide what a route means. You get the full Envoy configuration surface immediately, including fields that Gateway API has no resource for, and you are not waiting on a translation layer to catch up with an upstream release. You also own the entire control loop: watching your configuration source, validating it, pushing it, and reconciling when a push fails halfway through a fleet. Envoy Gateway trades that ownership for a declarative resource model. You write Gateway API objects and the project handles provisioning and configuration of the managed proxies. The difference in practice is where bugs live. With your own control plane, a misconfiguration is your translation code. With Envoy Gateway, a misconfiguration is either your Gateway API resource or the project's translation of it, and the second case is one you cannot fix locally. Choose the first approach when you need configuration that Gateway API cannot express; choose the second when the Gateway API surface covers your routing needs and you would rather not maintain a control plane. ## Maintenance, releases and the Apache-2.0 licence The repository is not archived, and the last push was on 2026-08-28, so the project is being worked on. Three recent releases sit close together: v1.9.1 and v1.8.4 both landed on 2026-08-28, and v1.9.0 on 2026-08-15. That pattern, a patch release on an older minor line alongside the newest minor, is what a maintained branch structure looks like, and it matters for upgrade planning because it means the previous minor is still receiving fixes. Upgrading means moving between those minor lines, and the Compatibility Matrix is the document that tells you which Envoy and Kubernetes versions each supports. Budget for that check as part of every upgrade, not as an afterthought. On licensing, the project is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. The repository carries a SECURITY.md with instructions for reporting vulnerabilities or process crashes, so there is a defined channel rather than an open issue tracker. This is not legal advice; if you redistribute the project or embed it in a product, have your own counsel read the licence text in LICENSE. ## Conclusion Adopt Envoy Gateway if you already run Envoy and want Gateway API resources to drive its configuration instead of hand-written xDS or a custom control plane. Skip it if you need a proxy that is not Envoy, or if you cannot take on a control plane that trails upstream Envoy releases by some interval. Before committing, read the compatibility matrix to see which Envoy and Kubernetes versions pair with the release you plan to run, and check the quickstart task against your cluster's Gateway API CRD state. ## FAQ ### What is Envoy Gateway? It is an open source project for managing Envoy Proxy as a standalone or Kubernetes-based application gateway, in which Gateway API resources are used to dynamically provision and configure the managed Envoy Proxies. It is written in Go and licensed under Apache-2.0. ### How does Envoy Gateway work? You apply Gateway API resources; the project watches them and uses them to dynamically provision and configure the Envoy Proxy instances it manages. The go.mod dependencies on go-control-plane indicate the xDS path used to push configuration to those proxies. ### How do I install Envoy Gateway? The README does not give install commands. It links to a Quickstart task at gateway.envoyproxy.io/latest/tasks/quickstart/, and the repository provides charts/ for Helm packaging plus examples/kubernetes and examples/standalone manifests. Check the Compatibility Matrix before installing. ## Sources - [Official documentation](https://gateway.envoyproxy.io) - [Official README](https://github.com/envoyproxy/gateway#readme) - [Project repository](https://github.com/envoyproxy/gateway) - [Release notes](https://github.com/envoyproxy/gateway/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/envoyproxy-gateway