Nginx Proxy Manager

A reverse proxy with a GUI, honest reviewed. What you actually get when you self-host it — and when you shouldn’t.

TL;DR

• What it is: A Docker-based reverse proxy manager with a web GUI that lets you point domain names at your self-hosted services and get free SSL via Let’s Encrypt — without touching Nginx config files [README][2].
• Who it’s for: Home lab builders and non-technical self-hosters who want human-readable URLs and HTTPS for their services without learning Nginx configuration syntax [2][5].
• Cost: $0 for the software (MIT license). You need a domain (~$10–15/yr) and a server or home machine to run it on [README].
• Key strength: The lowest barrier to entry in the reverse proxy category. A working proxy with SSL can be running in under 30 minutes for someone who knows Docker [2][README].
• Key weakness: Requires open ports (80, 443) forwarded through your router and a public IP pointed at your home. That one dependency creates real setup friction and security exposure that alternatives avoid entirely [3].

---

What is Nginx Proxy Manager

Nginx Proxy Manager is a pre-built Docker image that sits in front of your self-hosted services and routes traffic based on domain names. Instead of accessing Gitea at 192.168.1.100:3000, visitors (or you) hit git.yourdomain.com over HTTPS. NPM handles the SSL certificate from Let’s Encrypt automatically, and it renews it automatically too [README][website].

The project was created by Jamie Curnow (GitHub: jc21) with an explicit goal stated in the README: “it had to be so easy that a monkey could do it.” That framing is earnest — this is not a power tool dressed up in a GUI, it’s a GUI-first tool with power features optional [README].

With 32,135 GitHub stars and millions of Docker Hub pulls, NPM is one of the most-deployed pieces of self-hosting infrastructure. The codebase is MIT-licensed and the admin interface is built on Tabler [README].

What it does in practice: you deploy one Docker container, point your router to forward ports 80 and 443 at the machine running it, configure your domain’s DNS to point at your IP, and then add proxy hosts through a web dashboard. Each proxy host is a domain → service mapping (e.g., plex.yourdomain.com → localhost:32400). Let’s Encrypt issues a cert, and your service is reachable over HTTPS with a valid certificate [1][README].

---

Why people choose it

The consistent answer across reviews is the same: no config files. Nginx by itself is genuinely powerful and genuinely annoying to configure. NPM removes the annoying part while keeping the power accessible if you want it.

The GUI matters more than you’d think. The XDA Developers piece [2] calls out the web-based interface as the primary advantage — not having to SSH in and edit files every time you add a service. For someone running 10–15 self-hosted services, the difference between a GUI and hand-editing /etc/nginx/conf.d/*.conf is significant. The Medium deployment article [1] describes the full journey of getting a VPS-hosted setup working, including Cloudflare DNS migration and wildcard certificate setup — and even with all that complexity, the author frames NPM as the simplification layer that made the rest tractable.

SSL automation that actually works. Let’s Encrypt certificates used to require cron jobs and certbot and config linking. NPM wraps all of that. You click a checkbox, pick your domain, optionally enter a Cloudflare API token for DNS challenges, and the certificate appears. Renewals happen automatically [1][2][README].

Home network + Docker. NPM is almost tailor-made for the home lab Docker stack. The default docker-compose is four lines. If you’re already running Portainer and a handful of containers, adding NPM is a 15-minute operation [1][2][README].

The honest counter-argument. Two separate XDA pieces [3][4] push back specifically on the NPM-as-default recommendation. The HowToGeek piece [3] argues that NPM’s fundamental requirement — port forwarding with a public IP — is the real problem. “Not all routers support port forwarding, and not all ISPs make it easy to have a fixed IP target for your websites.” The author describes spending hours at a relative’s house failing to get port forwarding working before eventually switching the recommendation to Cloudflare Tunnels. The Caddy piece [4] comes from a long-time NPM user who switched — not because NPM broke, but because a single Caddyfile is easier to back up and migrate than NPM’s database-backed configuration.

---

Features

Core proxy management:

• Proxy hosts: map a domain to an internal IP:port [README]
• Redirections: HTTP → HTTPS, domain → domain [README]
• Streams: TCP/UDP proxying (for non-HTTP services) [README]
• 404 hosts: catch-all for unmatched domains [README]

SSL:

• Automatic Let’s Encrypt certificate provisioning [README][website]
• Wildcard certificates via DNS challenge (supports Cloudflare, Route53, and others) [README][1]
• Custom certificate upload for your own certs [README]
• Auto-renewal [website]

Access control:

• Access Lists: IP whitelist/blacklist per host [README]
• Basic HTTP authentication per host [README]

Admin:

• Web UI on port 81 [README][5]
• Multiple user accounts with per-user permissions [README][website]
• Audit log [README]
• Advanced Nginx configuration blocks available per-host for power users [README]

Infrastructure:

• Ships as a single Docker image [README]
• SQLite or MySQL/MariaDB backend [docs]
• ARM support up to 2.13.7 (armv7 dropped in 2.14+) [README]

What the feature list does not include: health checks on upstream services, load balancing, rate limiting, or traffic analytics. NPM is a routing and SSL layer, not a full API gateway or monitoring solution.

---

Pricing: SaaS vs self-hosted math

NPM itself has no SaaS version and no paid tiers. The software is free and MIT-licensed. The costs are entirely infrastructure:

Component	Cost
NPM software	$0
Domain name	~$10–15/yr
VPS to run it (if not home)	$4–6/mo (Hetzner, Contabo)
Home server electricity	~$5–15/mo depending on hardware
Dynamic DNS service (if ISP changes your IP)	$0 (DuckDNS is free) or $5/yr

The comparison here isn’t “NPM vs a SaaS alternative” — there’s no direct SaaS equivalent that does what NPM does. The real cost comparison is time and complexity vs the alternatives.

If you’re currently paying for something like Ngrok Pro ($8–25/mo) to expose services, or maintaining a VPN configuration to access home services remotely, NPM plus a static IP (or DDNS) is likely cheaper. If you’re comparing it to Cloudflare Tunnels for the same job — Cloudflare Tunnels is free and requires no port forwarding, which makes the cost comparison tilt toward “why are you using NPM at all” for pure external access [3].

For a home lab running a dozen services that you want accessible over HTTPS from outside your network, the total NPM cost is the domain registration. That’s it.

---

Deployment reality check

What you actually need:

• Docker and docker-compose on a Linux machine
• A domain name with DNS you control
• Ports 80 and 443 forwarded on your router to the machine running NPM
• A static IP or a dynamic DNS service (DuckDNS, Cloudflare DDNS, Route53 DDNS) [README][1]

Quick setup from the README:

services:
  app:
    image: 'docker.io/jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '80:80'
      - '81:81'
      - '443:443'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

That’s the minimum. Run docker compose up -d, hit http://your-server-ip:81, log in with admin@example.com / changeme, and change those immediately [5][README].

What actually goes wrong:

The port forwarding step is where most failures happen [3]. If your ISP uses carrier-grade NAT (common on mobile ISPs and some cable providers), you may not have a public IP that port forwarding can reach at all. If your router firmware doesn’t expose port forwarding, or your ISP blocks inbound connections on 80/443, NPM’s architecture doesn’t have a workaround. The HowToGeek article [3] describes spending hours troubleshooting exactly this scenario.

The default credentials issue is real [5]: admin@example.com / changeme is public knowledge. If you leave port 81 accessible without changing these, you’ve published admin access to your reverse proxy. The 1gbits.com guide [5] walks through credential rotation in detail specifically because it’s a common oversight.

For wildcard certificates, you need DNS API access (Cloudflare is the smoothest path) and a few extra steps that the basic UI doesn’t fully document upfront. The Medium deployment article [1] covers this in detail — it works, but it adds 30–60 minutes to initial setup.

Realistic time estimates:

• Technical user who knows Docker: 20–45 minutes to first working proxy with SSL
• Non-technical user following a guide: 2–3 hours including router setup and DNS propagation wait
• Wildcard cert setup: add another 30–60 minutes

---

Pros and Cons

Pros

• Zero config files required. You can stand up a properly-configured Nginx reverse proxy without ever touching an nginx.conf. For non-networking people, this is genuinely transformative [2][README].
• Free SSL that actually works. Let’s Encrypt auto-provisioning and auto-renewal, including DNS challenge for wildcard certs via Cloudflare, Route53, and others [1][README].
• MIT licensed. No commercial restrictions, no “fair-code” surprises. Deploy it in a production business environment without reviewing licensing terms [README].
• 32,000+ GitHub stars. The community is large. Problems you hit have almost certainly been discussed on the subreddit or GitHub discussions [README].
• GUI migration path for Nginx refugees. If you’ve been manually managing Nginx, NPM gives you a visual interface for the 90% case without removing your ability to drop advanced config blocks for the 10% [README][4].
• Docker-native. One container, no system-level dependencies. Fits cleanly into any existing Docker stack [README][2].
• Access lists and basic auth per host. Simple IP restriction and password protection without needing external auth middleware [README].

Cons

• Port forwarding is a hard dependency. If your ISP does carrier-grade NAT, or your router doesn’t support port forwarding, NPM fundamentally doesn’t work for external access. This is not an NPM bug — it’s architecture — but it’s a blocker for a meaningful slice of home lab users [3].
• Config lives in a database, not files. Unlike Caddy or raw Nginx, your proxy configuration is stored in NPM’s SQLite/MariaDB database. Backups require dumping the database, and migrating to a new host means migrating that database. A Caddyfile is one file you can git push. NPM config is not [4].
• No built-in traffic analytics. You can see that services are running, but there’s no request logging UI, no rate limiting, no per-service traffic graphs [README/website — feature not mentioned].
• armv7 support dropped at 2.14+. If you’re running older ARM hardware (Raspberry Pi 2, some ARM32 boards), you’re stuck at 2.13.7 [README].
• Default credentials are a known attack vector. admin@example.com / changeme is documented in public guides. Anyone who doesn’t change them on first login has published admin access to their proxy [5].
• Cloudflare Tunnels solves the core problem better for pure external access. If your main use case is “I want my services accessible over the internet securely,” Cloudflare Tunnels eliminates the port forwarding requirement entirely and adds DDoS protection for free. NPM’s advantage is when you want more control, internal routing, or aren’t willing to run your traffic through Cloudflare’s infrastructure [3].
• No active development momentum on v3. The project has been around since 2019 and version 2.x has been stable for years. This is either “battle-tested stability” or “low activity” depending on your perspective. The GitHub discussions reflect occasional frustration with responsiveness to bug reports.

---

Who should use this / who shouldn’t

Use Nginx Proxy Manager if:

• You’re running a home lab or home server with a public IP (or easy port forwarding) and want multiple services accessible over HTTPS with proper domain names.
• You’re comfortable with Docker and already have a Docker-based stack — NPM fits naturally into that workflow.
• You want a GUI-managed reverse proxy without committing to learning Nginx configuration files, but want the escape hatch of advanced config blocks when you need them.
• You’re migrating from manually-managed Nginx and want to reduce ongoing maintenance overhead.
• You want a dead-simple onramp for a non-technical person who needs to manage proxy hosts occasionally.

Skip it (use Cloudflare Tunnels instead) if:

• Your router doesn’t support port forwarding, your ISP uses carrier-grade NAT, or you can’t get a reliable public IP. Cloudflare Tunnels work outbound-only — no open ports required [3].
• Security is a top concern and you’d rather not expose ports 80 and 443 on your home network. Cloudflare Tunnels never require your home IP to be a target [3].
• You want free DDoS protection and rate limiting on top of the proxying.

Skip it (use Caddy instead) if:

• You value config-as-code over a GUI. A Caddyfile is three lines per proxy, lives in Git, and migrates to a new server with scp [4].
• You’re running on a headless server and prefer not to expose another admin port (81).
• You need automatic HTTPS that’s configured as code with zero UI dependency.

Skip it (use Traefik instead) if:

• You’re running a Docker Swarm or Kubernetes cluster and want service discovery that auto-configures reverse proxy rules from container labels.
• You need load balancing, health checks, or middleware (rate limiting, auth) as first-class features.

---

Alternatives worth considering

• Caddy — config file-based reverse proxy with automatic HTTPS. Arguably better for technical users who want reproducible, version-controlled config. Learning curve is real but the payoff is a portable, auditable setup [4].
• Cloudflare Tunnels — free, no port forwarding required, DDoS protection included. The best option if you don’t need internal-only routing and are comfortable with Cloudflare in your traffic path [3].
• Traefik — Docker-native reverse proxy with service discovery. More complex to set up than NPM but significantly more powerful for container-heavy deployments.
• HAProxy — enterprise-grade load balancer and proxy. Overkill for home use, appropriate for production deployments where you need fine-grained traffic control.
• raw Nginx — if you’re willing to learn the config syntax, raw Nginx eliminates the abstraction layer entirely. Everything NPM does, Nginx does directly. The tradeoff is that you need to know what you’re doing.

For the non-technical home lab user who just wants services on the internet with HTTPS, the realistic shortlist is NPM vs Cloudflare Tunnels. If port forwarding works for you: NPM. If it doesn’t, or if you want the security of not exposing ports: Cloudflare Tunnels.

---

Bottom line

Nginx Proxy Manager delivers on its stated goal: a monkey can set it up. If your router cooperates and you have a public IP, you can have 10 self-hosted services running on proper HTTPS domains within an afternoon, no Nginx knowledge required. The 32,000 GitHub stars are earned.

The real gotcha isn’t the tool itself — it’s the architecture it requires. Port forwarding and dynamic DNS are fussier than they look in tutorials, and they become real blockers in certain network environments. Two separate XDA articles were written specifically to steer people away from NPM toward alternatives [3][4] — not because NPM is bad, but because for the specific problem of “get services on the internet securely,” newer tools have removed the port forwarding requirement entirely.

Use NPM for what it’s good at: simple home lab routing, HTTPS for internal services over Tailscale, or any setup where you control the network and port forwarding works. The moment port forwarding is your bottleneck, look at Cloudflare Tunnels. The moment you want config-as-code, look at Caddy.

If you want NPM deployed and configured properly without spending an afternoon troubleshooting port forwarding and DNS propagation, upready.dev sets this up as part of a self-hosted infrastructure deployment.

---

Sources

1. Asbed B., Medium — “What I Learned Deploying NGINX Proxy Manager” (Feb 28, 2025). https://medium.com/@asbedb/what-i-learned-deploying-nginx-proxy-manager-f47271d230d6
2. Joe Rice-Jones, XDA Developers — “5 reasons Nginx Proxy Manager is perfect for the home lab” (May 9, 2025). https://www.xda-developers.com/nginx-proxy-manager-best-reverse-proxy/
3. Patrick Campanale, HowToGeek — “Don’t set up Nginx Proxy Manager—use this instead for your Homelab” (Feb 21, 2026). https://www.howtogeek.com/dont-set-up-nginx-proxy-manager-do-this-instead/
4. Adam Conway, XDA Developers — “5 reasons I dumped Nginx Proxy Manager for Caddy” (May 11, 2025). https://www.xda-developers.com/reasons-dumped-nginx-proxy-manager-caddy/
5. Alex Morrison, 1gbits.com — “NGINX Proxy Manager Default Login: Accessing Your Dashboard Securely” (Sep 6, 2025). https://1gbits.com/blog/nginx-proxy-manager-default-login/

Primary sources:

• GitHub repository and README: https://github.com/nginxproxymanager/nginx-proxy-manager (32,135 stars, MIT license)
• Official website: https://nginxproxymanager.com
• Setup documentation: https://nginxproxymanager.com/setup/