Envoy vs Caddy: Which Proxy to Self-Host?

Quick Verdict

Caddy wins for self-hosting by a landslide. Automatic HTTPS with zero configuration, a two-line Caddyfile per service, and 20-40 MB of RAM make it the simplest reverse proxy available. Envoy is far more powerful — native gRPC, advanced load balancing, built-in observability — but its configuration complexity is unjustifiable for typical homelabs. Use Envoy only when you have specific infrastructure requirements Caddy cannot meet.

Overview

These proxies sit at opposite ends of the complexity spectrum. Caddy optimizes for simplicity — automatic everything, minimal config. Envoy optimizes for control — explicit everything, maximum observability.

Caddy (v2.10.2) is a modern web server and reverse proxy with automatic HTTPS built in. Point it at a domain and it handles TLS certificates, HTTP/2, HTTP/3, and OCSP stapling without any SSL-related configuration. The Caddyfile format is the simplest config language of any proxy.

Envoy (v1.37.0) is a CNCF graduated cloud-native proxy built at Lyft. It provides L3/L4/L7 traffic management with first-class gRPC support, circuit breaking, distributed tracing, and Prometheus metrics. It powers Istio, AWS App Mesh, and Google Cloud’s traffic infrastructure.

Feature Comparison

FeatureEnvoyCaddy
Automatic HTTPSNoYes (zero config)
HTTP/2YesYes
HTTP/3 (QUIC)YesYes
Static file servingNoYes (native)
gRPC proxyingNative (first-class)Basic (pass-through)
gRPC-JSON transcodingYesNo
Load balancing5+ algorithmsRound Robin, IP Hash, etc.
Circuit breakingYes (detailed)No
Automatic retriesYesNo
Rate limitingYes (local + global)Via plugin
CachingNoVia plugin
Prometheus metricsBuilt-in (detailed)Via plugin
Distributed tracingBuilt-inNo
Config formatYAML (verbose, typed)Caddyfile (2 lines per service)
Config complexityHighVery low
Plugin ecosystemFilters + WASMGo modules
Docker auto-discoveryNoVia plugin (caddy-docker-proxy)
Kubernetes supportYes (Istio, native)Via Ingress Controller
TCP/UDP proxyingYes (native)Via plugin
WebSocketYesYes
Reverse proxyYesYes
Web serverNoYes
LicenseApache 2.0Apache 2.0

Installation Complexity

Caddy: One container, one Caddyfile. Adding a new proxied service:

app.example.com {
    reverse_proxy app-container:8080
}

That is the entire configuration. Caddy obtains and renews the SSL certificate automatically.

Envoy: One container, one YAML config. Adding a new proxied service requires defining a listener, filter chain, HTTP connection manager, route config, virtual host, route, and cluster — minimum 30 lines with fully-qualified typed_config annotations.

Winner: Caddy. It is not close. Caddy’s configuration is 2 lines vs Envoy’s 30+.

Performance and Resource Usage

MetricEnvoyCaddy
Idle RAM50-100 MB20-40 MB
Under load RAM200-500 MB50-100 MB
Written inC++Go
Static file throughputN/AVery fast
Proxy throughputVery highHigh

Caddy is lighter at idle and under typical homelab load. Envoy has higher peak throughput under extreme concurrency, but no homelab will reach that threshold.

Winner: Caddy for resource efficiency. Both are more than fast enough.

Community and Support

MetricEnvoyCaddy
GitHub stars26K+61K+
First release20162015
Backed byCNCFIndividual + sponsors
DocumentationComprehensive (infra-focused)Excellent (user-focused)
Self-hosting guidesFewMany

Caddy’s documentation is exceptional — clear, well-organized, and written for people actually using the tool. Envoy’s docs are thorough but target infrastructure engineers building service meshes.

Winner: Caddy for self-hosting documentation and community guides.

Use Cases

Choose Envoy If…

  • You run gRPC services needing native proxying and JSON transcoding
  • Circuit breaking with configurable thresholds is a requirement
  • Built-in Prometheus metrics and distributed tracing matter
  • You are integrating with Istio or a service mesh
  • Dynamic configuration via xDS APIs is needed
  • You have infrastructure engineering experience and specific needs

Choose Caddy If…

  • You want the simplest possible reverse proxy setup
  • Automatic HTTPS with zero configuration is appealing
  • You serve static sites alongside proxied services
  • You prefer minimal, readable configuration
  • You want the lightest resource usage
  • You run a typical homelab with HTTP/HTTPS services
  • You value a clean, well-documented tool

Final Verdict

Caddy wins for self-hosting. For a typical homelab, Caddy does everything you need in two lines of config with automatic HTTPS. There is no reason to use Envoy’s 30-line YAML configuration, manual certificate management, and steep learning curve for HTTP/HTTPS reverse proxying.

Envoy wins for specialized infrastructure. gRPC-native proxying, Maglev load balancing, circuit breaking, and built-in observability are capabilities Caddy does not offer. But these are capabilities most self-hosters do not need.

The recommendation is simple: use Caddy. If you find yourself needing something Caddy cannot do, that is when you evaluate Envoy, Traefik, or HAProxy.

FAQ

Can Caddy handle gRPC like Envoy?

Caddy can proxy gRPC traffic, but as a basic pass-through. It does not understand gRPC at the protocol level — no transcoding, no per-method routing. If gRPC is central to your setup, Envoy is the better choice.

Is Envoy faster than Caddy?

Under extreme load (thousands of concurrent connections), yes. For a homelab with a handful of users, performance is identical. Your internet connection is the bottleneck, not the proxy.

Can I start with Caddy and switch to Envoy later?

Yes. Both use config files that are independent of each other. Switch your port mappings and deploy. Your backend services do not change.