Project post originally published on Envoy’s blog by Matt Klein

Today we are thrilled to announce Envoy Gateway, a new member of the Envoy Proxy family aimed at significantly decreasing the barrier to entry when using Envoy for API Gateway (sometimes known as “north-south”) use cases.


Envoy was released as OSS in the fall of 2016, and much to our amazement quickly gained traction throughout the industry. Users were drawn to many different aspects of the project including its inclusive community, extensibility, API-driven configuration model, powerful observability output, and increasingly extensive feature set.

Although in its early history Envoy became synonymous with “service mesh,” its first use at Lyft was actually as an API gateway / edge proxy, providing in-depth observability output that aided Lyft’s migration from a monolithic to a microservice architecture.

Over the last 5+ years, we have seen Envoy adopted by a tremendous number of end users, both as an API gateway and as a sidecar proxy in “service mesh” roles. At the same time we have seen a large vendor ecosystem spring up around Envoy, providing a multitude of solutions both in the OSS and proprietary domains. Envoy’s vendor ecosystem has been critical to the project’s success; without funding for all of the employees that work part or full-time on Envoy the project would certainly not be what it is today.

The flip side of Envoy’s success as a component of many different architecture types and vendor solutions is that it is inherently low level; Envoy is not an easy piece of software to learn. While the project has had massive success being adopted by large engineering organizations around the world, it is only lightly adopted for smaller and simpler use cases, where nginx and HAProxy are still dominant.

The Envoy Gateway project was born out of the belief that bringing Envoy “to the masses” in the API gateway role requires two primary things:

We strongly believe that if the community converges around a single Envoy branded API gateway core, it will:

Project outline

At a high level, Envoy Gateway can be thought of as a wrapper around the Envoy Proxy core. It will not change the core proxy, xDSgo-control-plane, etc. in any way (other than potentially driving features, bug fixes, and general improvements!). It will provide the following functionality:

On the topic of APIs, we believe that one area that has led to significant confusion is the effective reimplementation of Envoy’s xDS APIs in other projects when targeting advanced use cases. This pattern causes users to have to learn multiple sophisticated APIs (which ultimately translate back to xDS) in order to get their job done. As such, Envoy Gateway is committed to a “hard line in the sand” in which the Kubernetes Gateway API (and any permissible extensions within that API) is the only additional API that will be supported. More advanced use cases will be served by an “xDS mode” in which existing API resources will be automatically translated for the end user, who can then switch to utilizing the xDS APIs directly. This will lead to a crisper primary API while allowing an escape hatch for organizations that might outgrow the expressiveness of the primary API and wish to utilize the full power of Envoy via xDS.

On API standardization

Although a goal of Envoy Gateway is to provide a reference implementation for easily running Envoy in Kubernetes as an ingress controller, possibly the most important contribution of this effort will be standardizing the APIs that are used for this purpose. As the industry converges on specific Envoy Kubernetes Gateway API extensions, it will allow vendors to easily provide alternate SaaS implementations that may be preferable if a user outgrows the reference implementation, wants additional support and features, etc. Clearly, there is much work to do around defining the API extensions, determining which APIs are required versus optional for conformance, etc. This is the beginning of our standardization journey and we are eager to dive in with all interested parties.

Next steps

Today we are thankful for the initial sponsors of Envoy Gateway (Ambassador LabsFidelityTetrate, and VMware) and are excited to start on this new journey with all of you. The project is very early with the focus so far having been to agree on goals and high level design, so it’s a great time to get involved, either as an end user or as a system integrator.

We also want to make it extremely clear that existing users of Contour and Emissary will not be left behind. The project (and VMware and Ambassador Labs) is completely committed to ensuring a smooth eventual migration path for users of those projects to Envoy Gateway, either via translation and replacement, or via those projects becoming wrappers around the Envoy Gateway core.

We are extremely excited about bringing Envoy to a larger group of users via the Envoy Gateway project, and we hope you will join us on our journey!