Envoy’s configuration model doesn’t change based on where you deploy it, but where you deploy it changes what problem it’s solving. This guide covers the common deployment patterns and why one property of Envoy, being cheap enough to run as one instance per application, is what makes the most interesting of them possible.

Edge proxy: the front door to your network

Deployed at the edge, Envoy sits between the outside world and your internal services, accepting ingress traffic from external clients and, in the other direction, handling egress traffic your own services send out. This is the classic API-gateway or load-balancer position: one (or a small, redundant set of) Envoy instances doing TLS termination, routing, and rate limiting for everything crossing the network boundary, in either direction.

Front proxy: a shared internal load balancer

A simpler internal pattern: a single Envoy (or small cluster of them) that every internal service sends requests to, which then distributes them to the right backend. This looks like a conventional internal load balancer, and functionally it is one, just implemented with Envoy’s routing and health-checking instead of a purpose-built LB appliance.

Sidecar: one Envoy per service instance

This is the pattern that sets Envoy apart from most other proxies: rather than a shared instance handling traffic for many services, an Envoy instance runs alongside each instance of each service, in Kubernetes terms, as a second container in the same Pod. Every service’s inbound and outbound traffic flows through its own dedicated proxy instance rather than a shared one.

Two things follow directly from this closeness:

• The application stops needing to know about networking. Retries, timeouts, TLS, and load-balancing logic move out of application code and into the proxy sitting right next to it, which is exactly the separation of concerns Envoy’s design set out to achieve.
• Troubleshooting gets faster. When Envoy is a shared component somewhere else on the network, a problem could be in the app, in the proxy, or in the network path between them. When Envoy runs right next to the one application instance it’s serving, that ambiguity mostly disappears: if the sidecar reports a healthy connection to the app but the request still fails, the search space just got a lot smaller.

Running one Envoy per instance only works because Envoy is deliberately lightweight; a proxy with a heavy per-instance footprint couldn’t be deployed at this density without becoming the resource cost of running the application a second time over.

Service mesh: sidecars, coordinated

A service mesh is the sidecar pattern applied consistently across an entire application: every service instance gets its own Envoy, and all of those proxies are configured and observed as one coordinated system rather than as independent, individually-managed instances. This is where Envoy’s traffic-management features, retries, circuit breaking, mutual TLS, fine-grained routing, apply uniformly across every service in the mesh, without any single service’s code needing to implement them.

Configuring hundreds of individual Envoy instances by hand isn’t practical, which is why service meshes exist as their own layer on top of Envoy rather than being “just Envoy, deployed a lot.” Istio is the most prominent example: its data plane is Envoy specifically, with Istio’s own control plane, istiod, generating and pushing each sidecar’s configuration automatically as services and policies change. If you run kubectl exec into a Pod that Istio has injected a sidecar into and look at its logs, what’s actually running is a real Envoy process, configured by Istio rather than by hand.

Mixed patterns are normal

Production topologies usually combine more than one of these: Envoy at the edge handling ingress and egress for the whole cluster, and Envoy sidecars handling service-to-service traffic inside it. Nothing about Envoy forces a single pattern; picking one, or a combination, is a question of which traffic needs which kind of control, not a limitation of the proxy itself.