Reverse proxies · edge · ingress

Four proxies,
one job?

Caddy, Nginx, Traefik and Envoy get lumped together — but they're not really competing for the same slot. Where you put the proxy decides everything. A working tour, with the trade-offs nobody puts on the landing page.

Nginx Caddy Traefik Envoy
01 / FRAMING

They aren't the same kind of thing

The single most useful idea before you compare specs: these four sit at different layers of abstraction. Treat them as interchangeable and you'll either over-build or fight the tool.

Nginx

C · since 2004
"I write a config file, it serves traffic." The boringly reliable default.

Caddy

Go · since 2015
Same shape as Nginx, but HTTPS configures itself. Optimised for "just work".

Traefik

Go · since 2015
Built around discovery: it watches Docker / K8s and wires routes live.

Envoy

C++ · since 2016
A data-plane building block for service meshes. You rarely hand-write it.

So the real question is almost never "which is best" in the abstract — it's where does this proxy live. A single host? A Docker Compose box? A Kubernetes cluster? Behind Cloudflare? Each answer reshuffles the ranking completely.

02 / AT A GLANCE

The shape of each tool

Rough, opinionated scores — higher is better, including for resource cost (a full bar = lighter). Use them to feel the silhouette, not as benchmarks.

Nginx

battle-tested default
throughput5
light footprint5
dynamic config1
auto-HTTPS1
ecosystem5

Caddy

HTTPS just works
throughput3.5
light footprint4
simplicity5
auto-HTTPS5
ecosystem3

Traefik

discovery-native
throughput3.5
light footprint4
dynamic config5
auto-HTTPS4
ecosystem4

Envoy

mesh-grade power
throughput4.5
light footprint2
dynamic config5
observability5
simplicity1
Axis Nginx Caddy Traefik Envoy
Config modelStatic file + reloadCaddyfile / JSONLabels · CRDs · filexDS via control plane
Auto HTTPS (ACME)No — bolt on certbotYes · headlineYes · built inVia control plane
Container discoveryNoNoYes · headlineVia control plane
Kubernetesingress-nginx EOLWeakGood (Gateway API)Strong (mesh)
Operational weightLowLowestLow–mediumHigh
Sweet spotRaw speed, ubiquity"HTTPS just works"Dynamic containersgRPC · mesh · control

Scores and grades are deliberately coarse. Real throughput depends on workload, kernel tuning and TLS settings far more than on the logo.

03 / SAME TASK, FOUR DIALECTS

One job: TLS reverse-proxy to a backend

Terminate HTTPS for example.com and proxy to an app on :4000 (Phoenix-style, so WebSockets must pass through). Watch the line count — it's the whole philosophy in miniature.

Caddyfile3 lines

  
04 / THE KUBERNETES SHIFT

"Just use nginx ingress" stopped being safe

If your comparison is really an AKS/ingress decision, there's a current-state fact that flips the default. Worth knowing before you pick.

End of life · March 2026

The community ingress-nginx controller is retired

Kubernetes SIG Network moved kubernetes/ingress-nginx to best-effort maintenance that ended in March 2026 — after which there are no releases, bug fixes, or CVE patches. Existing installs keep running, but new ones are explicitly discouraged. Its planned successor, InGate, never matured and was dropped too.

Two clarifications that save a lot of confusion: this is only the Kubernetes controller — the Nginx web server that runs half the internet is completely unaffected. And F5's separate commercial nginxinc/kubernetes-ingress is a different project that lives on.

The official direction is the Gateway API — the successor to Ingress, GA since late 2023. So on Kubernetes the choice quietly changes from "which proxy" to "which Gateway API implementation". The same four names reappear wearing different hats:

Nginx

as ingress
Community controller is a dead end. F5's commercial NIC remains, but it's a second migration later.

Caddy

as ingress
A controller exists but isn't mainstream. Caddy shines on single hosts, not as cluster ingress.

Traefik

as ingress
First-class Gateway API support + its own CRDs. The low-friction migration target for many.

Envoy

as ingress
Via Envoy Gateway / Istio / Contour. The most future-aligned path — and the most moving parts.

Azure-first? Application Gateway for Containers is Azure's managed Gateway API implementation — worth weighing if you'd rather not run the data plane yourself.

05 / DECIDE

Three questions, one pick

Answer honestly about where this lives. The recommendation updates live.

Q1Where does the proxy run?
Q2Is something already terminating TLS in front (Cloudflare, cloud LB)?
Q3Do you need a service mesh, heavy gRPC, or advanced traffic control?
06 / FOR THIS STACK

Phoenix + Next.js · Compose now · AKS soon · Cloudflare in front

A solo-owned infra heading from Docker Compose toward AKS, with Cloudflare already out front, narrows things considerably.

Today · Docker Compose

Traefik, with Caddy as the simpler alternative

Traefik fits how you already run Compose — label a service and it auto-registers, no reload, certs handled. The honest cost is a real learning curve in its provider/middleware model.

Caddy wins if you'd rather have a dead-simple, readable config and don't need much dynamism. Note: behind Cloudflare you may not want origin ACME at all — which removes Caddy's biggest selling point.

Plain Nginx is still right if you mostly want a stable proxy you write by hand and everyone can debug.

Soon · AKS

A Gateway API implementation — not ingress-nginx

Traefik's Gateway API buys conceptual continuity: one mental model from Compose to cluster. For a one-person team optimising for minimal surface, that's worth a lot.

Envoy via Envoy Gateway is the most future-aligned CNCF path and the best gRPC/observability story — keep it on the radar for when the agent/service topology grows. Don't hand-write raw Envoy.

Since you're Azure-first, Application Gateway for Containers trades some control for not running the data plane yourself.

The opinionated take

Don't reach for Envoy directly unless you have a concrete need — for your scale it's operational weight carried for features you may never use. Use Traefik as the through-line if you value Compose-to-AKS continuity, and keep Envoy Gateway as the thing you graduate into when the topology actually justifies it. And whatever you do on AKS, don't deploy ingress-nginx fresh.