Cloud Parts

Envoy

A C++ proxy for the edge and between services, configured live through the xDS APIs; the data plane under Istio, Envoy Gateway, Consul’s mesh and many others.

What it is
Service discovery & mesh,Load balancers
Type
Open source
Made by
Envoy project (CNCF), started at Lyft
License
Apache 2.0
Facts checked
6 October 2026
Website Source code

What it is

Envoy is one C++ binary that sits in the path of network traffic. It accepts connections on listeners and passes each through a chain of network filters (raw TCP, TLS, HTTP, Redis, Postgres and others). For HTTP there is a second chain of HTTP filters that can rate-limit, check authorization, transcode or route a request. Routes send traffic to clusters, groups of backends that Envoy health-checks actively and ejects when they misbehave (outlier detection), with retries, timeouts and circuit breaking. A main thread handles configuration, statistics and the admin port, while worker threads, usually one per CPU core, each keep the connections they accept, so the busy path needs almost no locking. It speaks HTTP/1.1 and HTTP/2, translates between them (HTTP/3 is still alpha), and handles gRPC natively. Every subsystem keeps counters, which the local admin port serves in Prometheus format.

Configuration can be a static YAML file, changed by a hot restart that hands the listening sockets to a new process. More often a control plane streams it in through the xDS APIs: listeners, routes, clusters, endpoints and TLS secrets, sent as Protobuf messages over gRPC, so backends and routes change without a restart. Envoy doesn’t include a control plane. Istio, Consul, Envoy Gateway, Contour and Google’s Cloud Service Mesh are control planes that program fleets of Envoys as sidecars next to each service, as shared waypoint proxies, or as edge gateways. Envoy is free under Apache 2.0, a CNCF graduated project, and ships a major release every quarter, each maintained for 12 months.

Why teams pick it

  • Routes, backends and certificates change at runtime through xDS, with no restart and no dropped connections
  • First-class HTTP/2 and gRPC: it handles trailers, which many proxies don’t, and has filters for gRPC-Web from browsers and JSON-to-gRPC transcoding
  • Detailed statistics for every listener, cluster and route, a Prometheus endpoint, access logs and distributed tracing
  • One proxy for the edge, ingress and service-to-service calls, so the same load balancing, retries and metrics apply everywhere
  • Apache 2.0 under neutral CNCF governance, and the data plane that most meshes and gateways already use

Watch out for

  • No control plane included: hand-written configs are long, Protobuf-shaped YAML, so in practice you also choose and run Istio, Envoy Gateway, Consul or similar
  • Native extensions are C++ compiled into your own build with Bazel (about 2 GB of RAM per build core); the Wasm filter is still marked experimental, leaving Lua, dynamic modules (C++, Go, Rust) or an external gRPC processor
  • As a sidecar it costs something on every pod: Istio measured about 0.20 vCPU and 60 MB of memory per sidecar at 1,000 requests per second
  • Some features are not production-ready: HTTP/3 is alpha, and the OpenTelemetry tracer is marked work in progress, not intended for production use
  • Each quarterly release gets security fixes for only 12 months, so you upgrade at least once a year; official Windows support ended on August 31, 2023

Alternatives

What all service discovery & mesh have in common →
HashiCorp ConsulCommercialA service registry with health checks and a DNS interface, plus a service mesh that configures Envoy proxies for mTLS between services.IstioOpen sourceThe Kubernetes service mesh started by Google, IBM and Lyft: mutual TLS, traffic routing and telemetry between services, through Envoy sidecars or the sidecar-less ambient mode.

How it fits with other technologies

A static front proxy: route, timeout, retries, health checks · yaml

# envoy.yaml; run with: envoy -c envoy.yaml (or the envoyproxy/envoy image)
static_resources:
  listeners:
  - name: ingress
    address:
      socket_address: { address: 0.0.0.0, port_value: 8080 }
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: ingress
          route_config:
            virtual_hosts:
            - name: api
              domains: ["*"]
              routes:
              - match: { prefix: "/orders" }
                route:
                  cluster: orders
                  timeout: 2s
                  retry_policy:
                    retry_on: "5xx,reset,connect-failure"
                    num_retries: 2
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
  clusters:
  - name: orders
    type: STRICT_DNS            # re-resolves the name; xDS (EDS) replaces this in a mesh
    connect_timeout: 1s
    lb_policy: LEAST_REQUEST
    load_assignment:
      cluster_name: orders
      endpoints:
      - lb_endpoints:
        - endpoint: { address: { socket_address: { address: orders.internal, port_value: 9000 } } }
    health_checks:
    - timeout: 1s
      interval: 5s
      unhealthy_threshold: 2
      healthy_threshold: 1
      http_health_check: { path: /healthz }
admin:
  address:
    socket_address: { address: 127.0.0.1, port_value: 9901 }
# curl localhost:9901/stats/prometheus   # counters for Prometheus

Who programs the Envoys#

Most people run Envoy through a control plane that writes its configuration for them.

Istio

CNCF graduated

Sidecar mode puts an Envoy next to every pod. Ambient mode uses a per-node ztunnel for mTLS and adds Envoy-based waypoint proxies only where L7 features are needed.

Envoy Gateway

Envoy project

Runs Envoy as an API gateway, standalone or on Kubernetes, configured with the Kubernetes Gateway API. Version 1.0 shipped in March 2024.

Contour

CNCF incubating

A Kubernetes ingress controller that serves as Envoy’s control plane, with its own HTTPProxy API for delegating routes between teams.

Consul

BUSL

Configures Envoy sidecars over xDS with certificates from Consul’s CA (built in or Vault), and enforces intentions such as “web may call payments”.

Google Cloud Service Mesh

managed

A managed control plane that serves xDS to Envoy proxies, or directly to gRPC apps with no proxy at all.

AWS App Mesh

retired

AWS’s Envoy-based mesh reached end of support on September 30, 2026; AWS points users to ECS Service Connect.

Envoy and open-source NGINX as a load balancer#

Both are fast, free proxies. The main difference is how configuration changes reach them.

EnvoyNGINX (open source)
LicenceApache 2.0BSD 2-Clause
Changing configurationStreamed in over xDS, or a static file and a hot restartEdit the file and run nginx -s reload
Adding backends at runtimeYes, through the endpoint API (EDS)Only with NGINX Plus’s API; open source can re-resolve a DNS name
Active health checksBuilt inNGINX Plus only
gRPCNative, plus gRPC-Web and JSON transcoding filtersgrpc_pass since 1.13.10
MetricsCounters for every subsystem, Prometheus format at /stats/prometheusBasic counters from stub_status; detailed metrics through NGINX Plus’s API

See it in a real stack

No architecture uses Envoy yet. Drop it into the playground and wire it up yourself.Open playground →

Worth exploring

Slides· September 2025How and Why Datadog moved from cloud-managed to self-managed PostgresNick Canzoneri, Datadog, at PGConf NYC 2025Slides from a talk on why a company running hundreds of Postgres clusters across several clouds left managed services for its own Postgres platform on Kubernetes, how it moved a whole region, and what got better and worse. The stack is Patroni (with ZooKeeper for leader election), WAL-G backups, a Helm chart rather than an operator, and Temporal workflows for automation. Useful before you weigh RDS-style convenience against running Postgres yourself.
All resources →
Where it came from2015–2026

In 2015 Lyft had about 30 services, mostly PHP and Python, talking through Amazon ELBs and a mix of per-language libraries, with HAProxy in a few places. Calls failed now and then, and no one could tell whether the fault lay in the service code, EC2 networking or the load balancer. Most developers, Matt Klein later wrote, “were afraid to have high volume service calls in critical paths”.

Klein’s answer, built at Lyft over about a year and a half, was Envoy: a C++ proxy that runs next to every service, so each app talks only to localhost while the proxies handle discovery, load balancing, retries and statistics. It started as Lyft’s front proxy and gradually replaced the ELBs between services. Lyft open-sourced it on September 14, 2016, when it ran on thousands of nodes and handled over 2 million requests per second.

What made it spread was configuration by API. Users wrote their own discovery servers instead of adapters, so in 2017 Envoy and Google moved those APIs to typed proto3 schemas served over gRPC streams: xDS. Istio was built on Envoy that May, Envoy joined the CNCF in September, and in November 2018 it became the foundation’s third graduated project, after Kubernetes and Prometheus.

Why it’s built this way

A separate process next to every app, not a library
Lyft ran PHP, Python and more. A proxy works with any language, and it can be upgraded across the fleet without redeploying every service, which library upgrades never allowed.
Native C++ instead of a garbage-collected language
Klein argued that a component in every request path “should get out of the way as much as possible”; native code keeps tail latency low, and C++11 was more productive than the C used by other native proxies.
Features as pluggable L4 and L7 filters
TCP proxying, TLS, HTTP routing, rate limiting, even MongoDB and DynamoDB statistics were written as filters in a chain, so new protocols and features slot in without changing the core.
Configuration pushed over typed gRPC streams
The first REST APIs were untyped JSON and polled. Proto3 schemas over gRPC made generic control planes safe to write, and pushing updates could cut propagation from 30–60 seconds to 250–500 ms.

Timeline

  1. 2015

    Lyft starts building Envoy, first as its front proxy

  2. 2016

    1.0 tagged September 12; open-sourced September 14

  3. 2017

    Istio launches on Envoy; xDS v2 APIs; joins the CNCF

  4. 2018

    Graduates from the CNCF on November 28, third after Kubernetes and Prometheus

  5. 2023

    Official Windows support ends August 31

  6. 2024

    Envoy Gateway 1.0 brings the Kubernetes Gateway API

  7. 2026

    AWS App Mesh, built on Envoy, reaches end of support

Sources37 · facts checked 6 October 2026

Improve this page on GitHub