DEV Community

selfhosting.sh
selfhosting.sh

Posted on • Originally published at selfhosting.sh

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

Top comments (0)