Skip to content
Envoy Proxy logo

Envoy Proxy

Cloud-native proxy and service mesh sidecar

4.2(0 reviews)freeFounded 2016United States
free tieropen source

Integrates with

Envoy is an open source L7 proxy and service mesh foundation. Used as the data plane in Istio, AWS App Mesh, and Consul Connect. High performance, built for microservices and Kubernetes.

Envoy is an open source layer-7 proxy written in C++, best known as the data plane underneath Istio and a long list of commercial service meshes and API gateways. It is not a product you buy or a platform you rent — it is software you run, licensed under Apache 2.0, hosted by the Cloud Native Computing Foundation, and deployed wherever you already have infrastructure. We carry it in our load balancers and container-platforms coverage because for a large class of Kubernetes shops, Envoy is the load balancer, edge proxy and traffic manager, whether or not the team knows it is there.

What Envoy Proxy actually is

Envoy began life at Lyft in May 2015 — deployed in production there from September 2015 — when the company's growing microservice fleet needed a network layer that application developers did not have to think about. Lyft released Envoy 1.0 as open source in September 2016, it joined the CNCF as an incubating project a year later, and in November 2018 it became the third CNCF graduated project after Kubernetes and Prometheus. That pedigree matters operationally: governance is neutral, the contributor base spans many companies, and no single vendor's roadmap can strand you.

Architecturally Envoy is a single high-performance process (C++), driven entirely by a JSON/YAML or protobuf configuration, with a dynamic configuration API called xDS — Listener, Route, Cluster, Endpoint and Secret discovery — so that control planes can push configuration changes without restarting the proxy. It speaks HTTP/1.1, HTTP/2, gRPC and HTTP/3 (QUIC), plus TCP and UDP proxying, and it handles the modern application-layer checklist: retries, timeouts, circuit breaking, outlier detection, global rate limiting, external authentication and authorization, TLS termination with hot certificate rotation, rich observability (stats, distributed tracing headers, access logs in multiple formats), and protocol support for Redis, Thrift and MongoDB among others. In practice Envoy shows up in three roles: as a sidecar beside each workload in a mesh, as a standalone edge or ingress proxy fronting a cluster, and as an internal gateway between tiers. The configuration and the operational worries differ by role — an edge deployment frets about TLS and attack surface at the boundary, a sidecar fleet frets about aggregate memory and rollout mechanics — and most of the pain we see teams hit comes from treating the three as interchangeable. The xDS API is the piece that made an industry: Istio, AWS App Mesh, Consul Connect, Cilium's service mesh and numerous commercial gateways all drive Envoy as their data plane, which is why "learning Envoy" is often really "learning whichever control plane sits in front of it".

The project is actively maintained on a published release cadence. At the time of writing the stable line is v1.40 (v1.40.0, released 13 October 2026), with four minor versions supported (v1.40 through v1.37 all still receiving patches in October 2026) and older lines archived — a real, checkable security-maintenance policy rather than a vibe. The repository shows roughly 28,000 GitHub stars, and the codebase is large and heavily tested; this is infrastructure that carries production traffic at many of the largest technology companies in the world.

Pricing: what you really pay

Software: free. Apache 2.0, no usage fees, no seats, no per-node licence, no support contract required to run it. minPrice is zero and stays zero no matter how much traffic you push.

What is not free is the operating cost, and we would be doing you a disservice pretending otherwise. Envoy configuration is famously verbose and unforgiving; the reference documentation is thorough but it is reference documentation for people who already know what a cluster manager does. In practice, teams pay in one of three currencies: engineering time to learn and operate raw Envoy, the licence fee of a managed control plane (Istio distributions, API gateway vendors, service mesh products — all of which sell you the control plane around the free proxy), or a commercial support contract from a vendor who will answer the phone. None of those costs appear on Envoy's pricing page because there isn't one. If your traffic profile is one reverse proxy in front of a monolith, nginx or a managed cloud load balancer is cheaper in every sense. If you are standardising a mesh across dozens of clusters, the free data plane is exactly why the economics work.

Performance & infrastructure

We have not benchmarked Envoy ourselves — our benchmark programme measures servers, not proxies — so this section is engineering analysis plus what the project publishes. The performance characteristics are well understood in the industry: event-driven C++ with careful memory and buffer management, designed for high connection counts and low per-request overhead, with TLS handled off the hot path where possible. In mesh deployments, Envoy sidecar overhead (latency per hop, memory per sidecar) is the number platform teams track, and it is predictable enough to plan around — but it is not zero, and sidecar sprawl in large clusters is a real resource cost on top of your workloads.

Reliability track record is Envoy's strongest card. It has carried production traffic at Lyft since 2015 and at a substantial fraction of the cloud-native world since; failure modes are documented, the security response process is mature (release notes routinely carry upstream security fixes, and supported versions get patches as a matter of policy), and the xDS protocol is now effectively an industry standard. When we weigh "reliability track record" in our rubric, very few tools in any category have a longer or more public evidence base. What you do not get is an SLA: this is community-supported software. Your uptime guarantee is whatever your own architecture and your own on-call provide.

Where it falls short

Complexity is the headline. A minimal static configuration is manageable, but anything production-grade — distributed tracing, outlier detection, global rate limiting via an external service, JWT validation, Wasm filters — adds configuration surface where a wrong field is silently ignored or, worse, honoured. The debugging story is better than it used to be (admin interface, detailed stats, config dumps), yet a wrong route table at 3am is still your problem.

Second, the control plane gap. Envoy the binary does not discover your services; something has to push xDS at it. Istio brings its own complexity budget, and lighter options still mean you own a control plane's lifecycle. Teams adopt "Envoy" and discover they actually adopted a mesh project.

Third, C++ is a double-edged choice: it delivers the performance profile, and it makes building from source and contributing a specialist skill. Most teams consume official builds and never touch the code — fine, but it narrows the pool of people who can debug a core-level problem. Finally, the ecosystem's success has fragmented the knowledge: Envoy docs explain the proxy, but your actual configuration is generated by Istio or a gateway, so troubleshooting bounces between two documentation worlds.

Who should pick this

Platform engineering teams standardising traffic management on Kubernetes — our pick when you want one data plane across ingress, mesh and egress, backed by neutral governance and a documented support window. It is the right default if you are already in an Istio-style mesh, if you need protocol depth (HTTP/3, gRPC-aware load balancing, sophisticated retry and circuit-breaking policy), or if you care that the thing carrying your traffic is open source with multiple vendors able to support it.

We would not pick Envoy for a simple public-facing site needing a reverse proxy, for a team without Kubernetes or platform experience, or when a managed cloud load balancer solves the problem with zero maintenance. If you want mesh outcomes without operating a mesh, evaluate managed offerings — and if you want our read on the servers to run any of this on, see our benchmarks.

Key takeaways

  • Free, open source (Apache 2.0) C++ layer-7 proxy; CNCF graduated in November 2018, created at Lyft in 2015, open-sourced September 2016.
  • xDS configuration APIs are the industry-standard control-plane interface — Istio, App Mesh, Consul Connect and others run Envoy as their data plane.
  • Protocol and feature depth is the best in the category: HTTP/1.1, HTTP/2, gRPC, HTTP/3, TCP/UDP, retries, circuit breaking, rate limiting, external auth, hot certificate rotation, deep observability.
  • Real maintenance policy: four supported minor versions with patches (v1.40–v1.37 at the time of writing), published security fixes.
  • Costs show up as operational complexity and control-plane ownership, not licence fees — no SLA, community support only.
  • Best fit: platform teams running mesh or sophisticated traffic management on Kubernetes; overkill for a single reverse proxy.

Sources

Pros

  • Free forever: Apache 2.0, no seats, no per-node licence, no usage metering
  • CNCF graduated with neutral governance and multi-vendor support options
  • xDS APIs are the de facto standard control-plane interface for service meshes and gateways
  • Depth of features: HTTP/3, gRPC-aware load balancing, circuit breaking, external auth, rate limiting, hot cert rotation
  • Documented support window (four minor versions patched) and a decade of production track record
  • Extensive observability hooks: stats, tracing headers, structured access logs

Cons

  • Configuration complexity is high; production-grade setups need a control plane or serious in-house expertise
  • No SLA or commercial support bundled — community support only
  • Sidecar overhead (latency and memory per proxy) is a real cost in large mesh deployments
  • C++ codebase narrows the pool of people who can debug core-level issues
  • Troubleshooting spans both Envoy docs and whatever control plane generates your config

Best For

Platform engineering teams on Kubernetes standardising ingress, mesh and egress traffic management on one open data plane, with the in-house or vendor expertise to own a control plane.

Pricing

Free Forever

Free
  • Core features included

Reviews (0)

No reviews yet. Be the first to share your experience!

Sign in to leave a review.

Sign In →

Articles about Envoy Proxy

Alternatives to Envoy Proxy

L

LinuxServer.io

Curated Docker images for self-hosted apps

Container PlatformsFree tier
4.2 ()
View Tool →
P

Podman

Docker-compatible rootless container runtime

Container PlatformsFree tier
4.2 ()
View Tool →
P

Portainer

GUI for managing Docker and Kubernetes

Container PlatformsFree tier
4.1 ()
View Tool →
T

Traefik

Cloud-native reverse proxy for microservices

Load BalancersFree tier
4.1 ()
View Tool →
G

GitHub Container Registry

Container registry integrated with GitHub Actions

Container PlatformsFree tier
4.1 ()
View Tool →
N

Northflank Containers

Container deployments with built-in CI/CD

Container PlatformsFree tier
3.9 ()
View Tool →

Stay in the loop

Get weekly updates on the best new hosting and infrastructure providers, deals, and comparisons.

No spam. Unsubscribe anytime.