Nginx Proxy Manager vs Envoy: Compared
Quick Verdict
Nginx Proxy Manager is the obvious choice for self-hosting. Envoy is a service mesh proxy designed for cloud-native infrastructure at scale — it’s massively overengineered for routing traffic to your self-hosted apps. Use NPM unless you’re building a Kubernetes cluster or need xDS dynamic configuration.
Overview
Nginx Proxy Manager (NPM) is a GUI-driven reverse proxy built on Nginx, designed for ease of use. Create proxy hosts, manage SSL certificates, and configure access controls through a web interface. Current version: v2.13.7.
Envoy is a high-performance edge and service proxy originally built at Lyft, now a CNCF graduated project. It’s designed for microservice architectures, service meshes (Istio uses Envoy as its data plane), and cloud-native infrastructure. Current version: v1.37.0.
These are not comparable tools in practice. NPM is a car; Envoy is a jet engine. Both move things forward, but for very different purposes.
Feature Comparison
| Feature | NPM v2.13 | Envoy v1.37 |
|---|---|---|
| Configuration method | Web UI | YAML (extremely verbose) |
| Learning curve | Minutes | Days to weeks |
| SSL automation | Built-in Let’s Encrypt | No (external ACME client) |
| Service discovery | Manual (UI) | xDS API, EDS, CDS, LDS |
| Load balancing | Basic (Nginx upstream) | Advanced (ring hash, Maglev, etc.) |
| Circuit breaking | No | Yes |
| Observability | Basic access logs | Detailed metrics, tracing, logging |
| gRPC proxying | Limited | Native, first-class |
| HTTP/3 | Via Nginx | Yes |
| Rate limiting | Via Nginx config | Built-in (global and local) |
| WebAssembly extensions | No | Yes (Wasm plugins) |
| Hot restart | Config reload | Full hot restart (zero downtime) |
| Admin dashboard | Web UI (port 81) | Stats endpoint (port 9901) |
Installation Complexity
NPM
Three-minute setup:
services:
npm:
image: jc21/nginx-proxy-manager:2.13.7
ports:
- "80:80"
- "443:443"
- "81:81"
volumes:
- npm-data:/data
- npm-letsencrypt:/etc/letsencrypt
restart: unless-stopped
Envoy
A simple HTTP proxy in Envoy requires 30+ lines of typed YAML:
static_resources:
listeners:
- name: listener_0
address:
socket_address:
address: 0.0.0.0
port_value: 10000
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: ingress_http
route_config:
name: local_route
virtual_hosts:
- name: backend
domains: ["*"]
routes:
- match:
prefix: "/"
route:
cluster: service_backend
# ... more config
Every filter requires a fully qualified @type annotation. Adding a new upstream service means adding a cluster definition with health check configuration, endpoint discovery, and circuit breaker settings.
Winner: NPM. Envoy’s configuration complexity is justified for large-scale infrastructure, not for routing traffic to Nextcloud.
Performance and Resource Usage
| Metric | NPM | Envoy |
|---|---|---|
| Idle RAM | ~80-120 MB | ~30-50 MB |
| CPU under load | Low (Nginx) | Low (C++) |
| Requests/sec | ~50,000 | ~80,000+ |
| P99 latency | ~1ms | ~0.5ms |
| Binary size | ~200 MB (Node.js + Nginx) | ~60 MB |
Envoy is faster and more memory-efficient than NPM’s Node.js management layer. But the actual proxy performance (Nginx core) handles self-hosting workloads just as well.
Community and Support
NPM has a large self-hosting community with tutorials, YouTube videos, and forum posts targeting home labs. Envoy’s community is enterprise-focused — documentation assumes Kubernetes, service mesh, and cloud-native knowledge. Finding “how to proxy my Jellyfin server through Envoy” is difficult; finding “how to configure Envoy’s xDS for service mesh” is easy.
Use Cases
Choose NPM If…
- You’re self-hosting Docker containers on a single server
- You want SSL and proxy management through a web UI
- You have 5-50 services to proxy
- You don’t want to learn a complex configuration language
- You want to be up and running in minutes
Choose Envoy If…
- You’re building a Kubernetes-based infrastructure
- You need a service mesh data plane (Istio, Consul Connect)
- You need advanced observability (distributed tracing, detailed metrics)
- You need gRPC proxying with full protocol support
- You need circuit breaking and advanced load balancing
- You’re running at scale with hundreds of microservices
Final Verdict
NPM for self-hosting, Envoy for infrastructure engineering. Choosing Envoy for a homelab is like using a commercial aircraft engine to power a go-kart. It’ll work, but you’ll spend more time on configuration than on actually using your self-hosted services.
If you’re genuinely building a service mesh or Kubernetes cluster, Envoy is the right tool. For everything else in the self-hosting world, NPM (or Traefik for Docker-native auto-discovery) is the practical choice.
Frequently Asked Questions
Is Envoy better than Nginx (which powers NPM)?
For microservice communication, yes. Envoy has better gRPC support, circuit breaking, and observability. For simple reverse proxying, Nginx performs equally well with far simpler configuration.
Can Envoy manage SSL certificates automatically?
Not by itself. Envoy supports SDS (Secret Discovery Service) for dynamic certificate loading, but you need an external ACME client or control plane to actually obtain certificates. NPM handles this with one checkbox.
Would Envoy be useful if I run Kubernetes at home?
Yes. If you’re running a k8s cluster (even k3s), Envoy-based ingress controllers like Contour or Envoy Gateway make sense. But at that point you’re not comparing it to NPM — you’re in a different infrastructure paradigm.
Related
Get self-hosting tips in your inbox
New guides, comparisons, and setup tutorials — delivered weekly. No spam.