envoyproxy/envoy

Envoy is worth your time if you operate service-to-service or edge traffic and need one programmable hop between clients and backends. It is less appealing if you want something you can hand-wire in an afternoon without a control plane.

The problem

A team running many services wants consistent routing, retries, telemetry and access policy instead of reimplementing them in each application. Traditionally that logic lives in libraries or per-service config, so a routing change or a new observability requirement becomes a code change and a deployment per service. With Envoy, that logic moves into a separate proxy process in front of workloads; operations changes become proxy configuration rather than application releases. The result is a uniform traffic layer, at the cost of running and configuring another component in the path.

What's different

Envoy's distinguishing idea is a universal, dynamic data-plane API: configuration can be pushed to the proxy instead of edited by hand and restarted. The README points to the universal data plane API design write-up and a related data-plane-api project, which is what lets control planes drive many proxies consistently. The proxy also exposes a documented stats architecture and hot restart, both explained in linked design posts, so traffic handling and process lifecycle are treated as first-class operational concerns. These matter when you change routes or roll proxies while traffic is live.

That design has a real price. Envoy is an infrastructure component with its own configuration model, and the interesting work usually involves a separate control plane to generate and push config. The project also documents that ppc64le builds are best-effort and outside the security policy, so choosing an unusual architecture changes your support expectations. It is a proxy, not an application framework: if your problem is writing business logic, this is the wrong layer.

Who should try it

Good fit: platform or infrastructure teams that already accept a sidecar or gateway model and want one proxy behaviour across services, with config driven by a control plane and telemetry collected centrally. Also a fit for edge gateway use where you need routing and policy ahead of backend services. Poor fit: a small application team that wants a single binary for local development routing, or anyone unwilling to own proxy configuration and upgrades. Teams without a control plane should check whether the documented static configuration path covers their needs before investing.

Requirements and limitations

You need to operate a proxy in the traffic path, which means capacity planning, config validation and an upgrade routine for a component whose failure affects requests. Dynamic configuration assumes tooling to produce and deliver it; the README links the data-plane API rather than an all-in-one management server. Platform support is uneven: ppc64le builds are explicitly best-effort and not covered by the security policy, while other builds are listed separately. Security response is organised through GitHub Security Advisories and a documented release process, so you should track security announcements and plan upgrades rather than treating a deployed version as finished.

HotRepo's take

HotRepo's recorded sample is tiny: Envoy appeared on the daily board on 2026-10-24 and 2026-10-25, at 29,124 and 29,127 stars (+9 and +11). That is a snapshot of a long-established project, not evidence about momentum, so persistence cannot be judged from it. Before adopting, verify the specific platform and configuration path you need against the official documentation and the FAQ.