Nginx Proxy Manager: The Click-to-HTTPS Front Door for Your Self-Hosted Stack

1. The Front Door to Your Homelab

If self-hosting has a front door, it is the reverse proxy. The moment you run more than one service — a note app, a media server, a dashboard, a password vault — you stop memorizing IP addresses and ports and start giving everything clean hostnames like notes.example.com and media.example.com, all on port 443 with valid certificates. Nginx Proxy Manager, usually called NPM, is the tool that makes this accessible to people who have never written an Nginx server block. NPM wraps the battle-tested Nginx web server in a friendly admin panel. You add a "proxy host," type the domain and the container's internal address, tick a box for SSL, and it writes the configuration and requests the certificate for you. As of late 2026 it carries roughly 34,000 GitHub stars, an MIT license, and an active release line (v2.16.0 shipped in September 2026). It is one of the most recommended entry points into serious self-hosting for a reason: it removes the single biggest barrier between "I installed a container" and "my friends can reach it over HTTPS." This article is a thorough, honest examination of running NPM. We will look at what it is, how it works, what it costs, where your traffic and certificates actually go, and the limitations you should weigh before making it the gatekeeper of your entire stack.

2. Why a Reverse Proxy Matters

Without a reverse proxy, every service you self-host listens on its own port, and you reach it by IP and port number. That is fine alone on a home network, but it breaks down the instant you want external access, clean URLs, or TLS. A reverse proxy solves all three at once: it listens on ports 80 and 443, decides where each request goes based on the hostname, and terminates HTTPS so the services behind it can speak plain HTTP on a private network. The proxy also becomes a single, central place to apply policy: force HTTPS, add security headers, block bad actors, require a password on a sensitive service, or expose only what you intend. In a self-hosted world where you are your own security team, concentrating that control in one well-understood component is a major simplification. NPM's contribution is making that concentration usable through a form instead of a configuration file. There is also a quiet efficiency benefit: by terminating TLS in one place, you avoid configuring certificates inside every backend, which is where most self-hosted apps handle HTTPS badly or not at all. Centralizing termination means each service behind the proxy can stay on plain HTTP inside your private network, reducing the number of places a misconfigured certificate can break something. The proxy becomes the single component you keep patched and correctly certified, and everything behind it inherits that correctness by default.

3. NPM vs the Alternatives at a Glance

Two other names dominate the reverse-proxy conversation in 2026: Traefik and Caddy. All three are free, open source, and faster than any homelab needs. NPM wins on day-one simplicity. You click through a web form. It is the beginner's choice and remains perfectly capable for small labs with a handful of services. Traefik wins on dynamic discovery: it reads Docker labels and updates routes the moment a container starts or stops, which scales better into infrastructure-as-code and Kubernetes. Caddy wins on the simplest automatic HTTPS in two lines of config and a single Go binary. The licensing is interesting: NPM and Traefik are MIT, while Caddy is Apache 2.0; Traefik also has a paid Hub tier on top of the free proxy, whereas NPM is purely community. None of them will surprise you with a license rug-pull. The choice is really about configuration style — a web GUI, container labels, or a Caddyfile — not about cost.

4. Architecture Under the Hood

NPM is not a from-scratch proxy; it is Nginx (specifically OpenResty, the Nginx build with Lua) driven by a Node.js administration interface backed by a database. When you fill in the UI, the backend writes Nginx configuration files and reloads Nginx; it does not hand-edit text you maintain. The admin UI is a Node application, and settings are stored in SQLite by default, with MySQL or PostgreSQL as options. This hybrid design is why NPM is both easy and occasionally frustrating. Easy because you never touch config files. Frustrating because your configuration lives in a database rather than a git-tracked file, so "what did I change and when" is harder to answer than with a plain text config. Understanding this split — Nginx does the work, the database records your intent, the UI is the editor — explains nearly every strength and weakness that follows.

5. Installation via Docker Compose

The standard install is a short Compose file: `` services: app: image: 'jc21/nginx-proxy-manager:latest' restart: unless-stopped ports: - '80:80' - '443:443' - '81:81' volumes: - ./data:/data - ./letsencrypt:/etc/letsencrypt ` Ports 80 and 443 are for the proxy itself; port 81 is the admin interface. Run docker compose up -d, open port 81, and since version 2.13 a setup wizard asks you to create the first admin account instead of shipping a default login. You can also preset that account with INITIAL_ADMIN_EMAIL and INITIAL_ADMIN_PASSWORD environment variables for unattended provisioning. The two volumes — data and letsencrypt — are the only state you need to back up.

6. First-Run Setup and the Admin Account

Historically, NPM shipped with a well-known default admin login, which caused no end of "I got hacked" stories when people exposed port 81 to the internet. Modern versions fixed this with a first-run wizard and the ability to preseed credentials, so a fresh install no longer has a guessable password. Still, the admin port is the keys to your kingdom: anyone who logs in can reroute or expose any service. Treat it accordingly. Best practice is to never expose port 81 publicly. Keep the admin UI on your LAN or behind a VPN, or place it behind an authenticating reverse proxy or an access list. The proxy's own admin should be the most protected thing on your network, because compromising it compromises everything behind the proxy. A strong, unique admin password and 2FA where available are non-negotiable.

7. Adding a Proxy Host: The 60-Second Tour

The core workflow is adding a "Proxy Host." You enter the domain (e.g., notes.example.com), the forward hostname or IP (the container name or internal IP), the forward port (e.g., 5230), and toggle SSL on. NPM writes the Nginx config and, if you enabled it, obtains a Let's Encrypt certificate automatically. Within a minute, the service is reachable on HTTPS at its hostname. You can also set options per host: enable WebSocket support for apps that need it, force SSL redirection, apply an access list, add custom headers, or block common exploits via the built-in "Block Exploits" toggle. The UI surfaces the most common needs without opening a config file. For the long tail of edge cases, there is a custom configuration field that injects raw Nginx directives into the server or location block, bridging the gap between GUI convenience and full Nginx power.

8. Let's Encrypt and Automatic SSL

NPM's killer feature is frictionless certificates. It integrates with Let's Encrypt (and other ACME providers) and requests, installs, and auto-renews certificates through either the HTTP-01 challenge (it proves control of the domain by serving a token on port 80) or a DNS-01 challenge via one of many supported DNS providers. Renewals are handled automatically, so you rarely think about certificates again. The HTTP challenge requires ports 80 and 443 open and the domain pointed at your IP. The DNS challenge is preferable when you cannot open port 80 (some ISPs block it) or when you want wildcard certificates. Either way, the certificate private keys are stored on your host in the letsencrypt volume — they never leave your machine to a third party except the ACME handshake with the certificate authority. For a privacy-minded self-hoster, that means your TLS keys are yours to protect, not sitting in someone else's certificate dashboard.

9. Wildcard Certificates via DNS Challenge

A wildcard certificate for *.example.com lets you bring up new subdomains without requesting a new certificate each time, and NPM supports this through the DNS challenge with providers like Cloudflare, Route53, and many others. You supply API credentials for your DNS host, NPM proves domain control by creating a temporary TXT record, and it issues a certificate covering every subdomain. The caveat is that those DNS API credentials are powerful — they can modify your entire zone. Store them carefully, scope them if your provider allows, and consider a dedicated zone or subdomain for self-hosted services so a leaked credential cannot rewrite your primary domain's mail or apex records. This is a case where convenience (one cert for everything) trades against blast radius (one credential for everything), and the right call depends on your DNS provider's permission model.

10. Access Lists and Basic Auth

Beyond certificates, NPM can gate individual hosts with access lists — rules that allow or deny by IP range or require HTTP basic authentication. This is how you safely expose a service that has no built-in login, or add a second factor in front of one that does. You define an access list once and apply it to any host. Basic auth is crude but effective: a username and password prompt before the request even reaches the backend. IP-based allowlists are even stronger for services meant only for you — permit only your VPN range or home IP and everyone else gets denied at the edge. These controls live in NPM, so they apply consistently regardless of what the backend supports. For sensitive tools, layering NPM access control over the app's own auth is a sensible defense in depth.

11. Custom Nginx Configuration

When the GUI does not cover a need, NPM provides custom configuration fields that inject Nginx directives into the server or location block. This is where you add rate limiting, client body size limits, specific proxy headers, or rewrite rules. It preserves the GUI for the routine while still giving you the full power of Nginx for the exceptional. The discipline here is to keep custom snippets small and documented, because they live in the database, not in a git repo. A good habit is to paste the effective need into the field and note in your own docs what you changed and why, since NPM will not show you a diff history. For most users, the custom field is rarely needed; for advanced ones, it is the escape hatch that prevents NPM from ever feeling limiting.

12. Streams: TCP and UDP Proxying

NPM is not only for HTTP. The "Streams" feature proxies raw TCP and UDP connections, which lets you route game servers, SSH, VPN endpoints, or other non-HTTP services through the same host on distinct ports. You define a listening port and a forward target, and NPM passes the bytes through. This is genuinely useful for consolidating ingress: one machine fronts both your web apps and, say, a Minecraft server. The limitation is that streams are matched by port, not hostname, since there is no hostname in a TCP handshake. So you cannot multiplex ten TCP services on one port the way you can with HTTP virtual hosts; each needs its own listening port. For UDP-heavy workloads like some game or VoIP servers, verify the stream handles your protocol's connection model, as naive proxying can break stateful UDP.

13. The 404 Host and Default Behavior

NPM lets you define a "404 Host" — the page served when someone hits your IP or an unknown hostname. This matters because, by default, an unmatched request might land on the first host or show a default page, which can leak information about what you run. Setting a neutral 404 host means unknown names get nothing useful, reducing reconnaissance value. Good hygiene is to point the default and 404 responses at a blank page and to avoid responding on the IP directly for named services. Combined with not exposing the admin port, this shrinks your attack surface so a scanner learns as little as possible. It is a small setting with outsized privacy value, and worth configuring on every install.

14. Multiple Instances and Redundancy

For a home lab, a single NPM instance is usually enough. For higher availability, you can run multiple NPM instances behind a floating IP or a separate load balancer, though this introduces coordination complexity because each instance has its own database and certificate store. The simplest resilience is a single instance with automated backups and a fast restore path, since the proxy going down only affects ingress, not the data behind it. If you need true multi-instance, consider a database backend shared across instances (MySQL/Postgres) and a synchronized letsencrypt volume, or move to Traefik, which is designed for dynamic, multi-node environments. NPM can scale to moderate needs but was built for the single-node homelab, and pretending otherwise leads to painful manual syncing.

15. Database Backends

NPM stores its configuration in SQLite by default — a single file in the data volume. For most users this is perfect: it is portable, easy to back up, and has no extra service to run. MySQL and PostgreSQL are supported for those who want a shared, more robust store, particularly in multi-instance setups. The practical takeaway is that your entire proxy configuration — hosts, access lists, certificates metadata — is a database you control. There is no proprietary format and no cloud account. Backing up the data and letsencrypt volumes captures everything needed to rebuild the proxy elsewhere. That portability is part of why NPM fits a self-hosted, data-sovereign philosophy even though it is infrastructure rather than an application.

16. Honest Limitations

NPM is beloved but not flawless, and the limitations matter when it is the front door to everything you run. First, configuration lives in a database, not a file. This makes git-based change tracking and code review of your routing awkward. You cannot easily diff "what changed" the way you can with a Caddyfile or Traefik labels. Second, there is no load balancing in the UI. You can write custom Nginx config for upstream pools, but the point-and-click experience assumes one backend per host. If you need real load balancing, Traefik or raw Nginx is a better fit. Third, NPM is fundamentally a GUI tool. Power users who prefer declarative, version-controlled infrastructure may find the click-ops model slow and error-prone at scale. Fourth, like any web admin, the UI itself is an attack surface. Past default-credential incidents show what happens when port 81 is exposed; the lesson is to protect the admin ruthlessly, but the risk remains inherent to having a privileged web UI. Fifth, NPM updates Nginx and the UI on its own cadence, which can lag upstream Nginx security releases. You are trusting the project to package patches promptly. For most home labs that is acceptable; for high-security environments, track upstream Nginx separately or use a proxy you patch directly.

17. Real Self-Hosting Cost Numbers

The proxy is almost free to run because it is lightweight. NPM's own footprint is modest: a small Node process plus Nginx, comfortably under 100MB RAM at idle for a typical homelab. The real costs are the surrounding necessities, not the proxy itself.

• Domain name: $10–15 per year for a standard TLD; some privacy-minded registrars cost a bit more.
• VPS to host it (if you do not run at home): $4–7 per month for a small instance, though NPM usually shares that host with your other containers, so the marginal cost is near zero.
• Home internet with a public IP: already paid; a static IP or dynamic DNS service adds $0–3 per month if your provider charges.
• DNS provider: free for basic zones at Cloudflare and others; API access for DNS challenges is included.
• Electricity for a home server: $10–30 per year depending on hardware.

Against a commercial tunnel or ingress service that might charge $5–20 per month, self-hosting NPM is effectively free beyond the domain. The honest cost is operational: you maintain the host, the DNS, and the certificates. The dollar figure is tiny; the responsibility is the real line item.

18. Where Your Data Goes / Data Sovereignty

A reverse proxy sits in the path of every request to your services, so its data-sovereignty story deserves precision. What NPM handles: it terminates TLS, routes requests, can log access, and stores your routing config and certificate private keys on your host. What it does not do: it does not send your traffic to a third party, does not require a cloud account, and does not phone home. Your certificates and keys stay in your letsencrypt volume. The sovereignty nuance is that the proxy necessarily sees unencrypted traffic between itself and your backends (that is the nature of TLS termination), and if you enable access logging, it records who connected to what. That is data you generate and store, on your machines, under your control — not data handed to a vendor. The privacy consideration is to decide deliberately whether you log, and where those logs go. Disable or tightly control access logging if you do not need it, and treat the certificate keys as the sensitive assets they are by encrypting the volume and restricting file permissions. There is a genuine tension here: logging is both a privacy cost and a security asset. Detailed access logs let you detect intrusions, spot credential stuffing, and audit who reached a sensitive host — but they also record your users' IP addresses and the services they touched, which is exactly the kind of metadata a privacy-focused self-hoster might prefer not to keep. The balanced approach is to log at the proxy only what you will actually review, rotate and expire logs on a short schedule, and keep them on encrypted storage. Separately, the ACME account key NPM uses to talk to Let's Encrypt is also stored locally; it identifies your instance to the CA but does not expose your traffic. The throughline is that self-hosting the proxy moves the privacy and security decisions onto your shoulders — you decide what is recorded, where it lives, and who can read it, rather than accepting a vendor's defaults.

19. Security Hardening

Because NPM is the front door, harden it first. Do not expose port 81 publicly; keep the admin on your LAN, a VPN, or behind an authenticated proxy. Use a strong, unique admin password and enable 2FA if available. Put the proxy itself behind fail2ban or CrowdSec to slow brute-force and credential-stuffing against both the admin and your exposed hosts. Enable the "Block Exploits" toggle per host to apply a set of common Nginx hardening rules. Add security headers (HSTS, X-Content-Type-Options, etc.) via the UI or custom config. Restrict sensitive hosts with access lists so only your IP or VPN range can reach them. Keep NPM updated, because the bundled Nginx and the admin code both receive security fixes. None of this is exotic, but the unencrypted-at-the-edge nature of TLS termination means your host firewall and the proxy's access rules are doing real work.

20. Integrating Authentik for Single Sign-On

For self-hosters running several services, authenticating each one individually gets old. NPM pairs well with an identity provider like Authentik: you can place Authentik's forward-auth in front of selected hosts so a single login governs access across your stack. The user hits the service, NPM forwards an auth check to Authentik, and only authenticated sessions pass through. This turns NPM from a dumb router into a policy enforcement point, which is exactly what you want when the proxy is the only thing the internet can see. Combining Authentik's SSO with NPM's access lists gives you centralized login, optional MFA, and per-service rules, all without modifying the backends. It is one of the highest-leverage upgrades to a self-hosted setup and a natural next step once NPM is stable.

21. Combining with CrowdSec or a WAF

Beyond fail2ban's simple ban-on-repeat-offense model, CrowdSec offers a collaborative, behavior-based threat intelligence layer that NPM can feed and be fed by. You can run CrowdSec on the NPM host to detect and block malicious patterns — scanners, known attack signatures, credential stuffing — and share signals with a community blocklist. For heavier needs, NPM can sit behind or in front of a Web Application Firewall. The point is that NPM terminates TLS and routes, but security filtering can be layered around it rather than expecting NPM to be the entire defense. Used this way, the proxy becomes the clean, manageable front end of a defended perimeter rather than the perimeter itself.

22. Backups

Backing up NPM is tiny and critical. The two volumes — data (configuration database) and letsencrypt (certificates and keys) — capture your entire proxy state. Copy them regularly, encrypt the copy if it leaves your network, and store it off-site. With those two folders, rebuilding the proxy on a new host is a Compose file plus a volume restore. Test the restore occasionally, because a proxy you cannot rebuild quickly is a single point of failure for every service's ingress. Note that Let's Encrypt rate limits mean you should not blindly re-request dozens of certificates on every rebuild; restoring the letsencrypt volume preserves your issued certs and avoids hitting issuance limits. Backups are therefore not just about data loss but about staying under ACME's weekly request caps during a recovery.

23. Common Pitfalls

A few mistakes recur. Port conflicts: if something else already binds 80/443 on the host, NPM cannot start; use a different host or stop the conflicting service. DNS not pointed at your IP: the HTTP challenge fails until the A/AAAA record resolves to the right place. Certificate rate limits: requesting and deleting certs repeatedly can temporarily block issuance for a domain; restore the letsencrypt volume instead of re-issuing. Another is exposing the admin UI by mapping port 81 publicly, which invites compromise. And the custom-config escape hatch can break a host if you paste invalid Nginx, so validate snippets carefully. Finally, forgetting that streams are port-based leads people to expect hostname routing for TCP services that simply is not possible. Most NPM pain is DNS, ports, or cert limits — all solvable with patience.

24. When to Pick Traefik or Caddy Instead

Choose Traefik if you run many containers and want automatic discovery from Docker labels, git-friendly declarative config, native load balancing, and Kubernetes readiness. Choose Caddy if you want the simplest possible automatic HTTPS in a single static binary with a two-line config and no GUI. Choose NPM if you want a point-and-click UI, you are comfortable with a database-backed config, and your scale is a handful to a few dozen services. The three are not enemies; plenty of people run NPM at home and Traefik at work. The right tool is the one matching how you like to configure. NPM's enduring appeal is that it lowers the entry barrier so dramatically that a complete beginner can put their whole stack on HTTPS in an afternoon — and that is worth more than ideological purity about configuration files.

25. Wiring NPM into Docker Networks

The cleanest NPM setup puts the proxy and your services on a shared Docker network so they reach each other by container name instead of fragile IP addresses. You create a network, attach NPM to it, and attach each backend container to the same network. Then in the proxy host form you enter the service name (e.g., memos) as the forward hostname and its internal port as the forward port. Docker's internal DNS resolves the name, and the traffic never leaves the host's virtual network. This pattern avoids publishing backend ports to the host at all. A service can be on the proxy network only, with no host port mapping, meaning it is reachable solely through NPM and never directly from the internet. That is a meaningful security win: the only publicly listening processes are NPM's 80, 443, and (ideally unexposed) 81. Everything else is private by construction. The only gotcha is that NPM must be on every network it proxies for, so plan a single shared network or attach NPM to each as needed.

26. Handling WebSockets and Tricky Apps

Some self-hosted apps — chat servers, live dashboards, code editors, and many admin UIs — use WebSockets, which require specific proxy headers to function. NPM handles this with a "WebSocket Support" toggle per host that adds the Upgrade and Connection headers automatically. For apps that still misbehave, the custom configuration field lets you set client_max_body_size for large uploads, proxy_read_timeout for long-lived connections, or additional header passes. A common failure mode is a service that loads but live updates never arrive, which is almost always a missing WebSocket upgrade. Enabling the toggle fixes the majority; the rest need a targeted custom snippet. Knowing this one setting saves hours of "why is my app half-broken" debugging and is the difference between NPM feeling limited and feeling complete for real-world apps.

27. Certificate Management Internals

Under the hood, NPM talks to Let's Encrypt (or another ACME CA) using the DNS or HTTP challenge and stores the resulting fullchain and private key in the letsencrypt volume, while metadata about issuance and renewal lives in the database. Renewals are attempted automatically before expiry, so a healthy install rarely shows a browser certificate warning. Understanding this split helps when things go wrong: if a cert fails to renew, the keys and the config are in two places, and restoring both volumes together is what makes a rebuild seamless. One subtlety worth knowing is certificate transparency and the public log. When NPM issues a certificate for notes.example.com, that hostname appears in public Certificate Transparency logs. That is normal for any public TLS certificate and is not a leak of your network — but it does mean your subdomain naming is publicly observable. If you want to hide which services you run, consider not issuing individual public certs and instead using a wildcard with the DNS challenge, or keeping sensitive hostnames on a VPN rather than the public DNS.

28. Monitoring and Observing the Proxy

Because NPM is the ingress for everything, watching it pays off. At minimum, ensure access and error logs are available and rotate them so they do not fill the disk. You can ship NPM's logs to a central logger, or simply periodically review them for repeated failed auth or scanning patterns. Pairing NPM with an uptime monitor that checks each proxied hostname tells you not just whether the proxy is up but whether each backend still responds through it. For deeper visibility, the underlying Nginx status and request metrics can be exposed or scraped, and a dashboard can show request rates, TLS handshake counts, and error ratios across hosts. The takeaway is that the proxy is both a control point and an observation point: it is where you can see, in one place, who is knocking on every door you have opened. Treating its logs as a security sensor rather than noise is one of the cheapest improvements to a self-hosted perimeter.

29. Upgrading, Version Pinning, and Safe Rollbacks

NPM ships as a container image, so upgrading is normally a docker compose pull && docker compose up -d away. Because your configuration and certificates live in mounted volumes, the container remains disposable and the state survives the swap. The discipline that matters is deciding whether to track :latest` or pin a specific version. For a proxy that gates your entire stack, blindly riding latest is risky: a regression could take down ingress for everything behind it. A safer pattern is to pin to a known-good tag, watch the project's release notes for the next version, and upgrade deliberately after a backup. Before any upgrade, snapshot the data and letsencrypt volumes so a bad release is a one-command restore rather than an incident. If you run many services, consider staging the new image on a test host or a cloned stack to confirm your proxy hosts still generate valid configs. NPM's config-generation is stable across versions, but custom snippets occasionally need adjustment when the bundled Nginx jumps a major version. The few minutes spent pinning and backing up are cheap insurance for the component whose failure is most visible — the one your users hit first.

30. Related

NPM rarely stands alone. These already-published deep dives pair naturally with it in a self-hosted stack:

• Traefik — the label-driven alternative if your lab grows beyond what a GUI fits.
• Caddy — the simplest automatic-HTTPS single-binary alternative.
• Authentik — add single sign-on in front of the hosts NPM exposes.
• CrowdSec — behavioral threat blocking for the proxy host.
• Uptime Kuma — monitor that your proxied services stay reachable.

31. Bottom Line

Nginx Proxy Manager is the friendliest on-ramp to serious self-hosting: a web UI over proven Nginx that turns "I installed a container" into "it is on HTTPS at a clean hostname" in minutes. It is MIT-licensed, ~34k stars, actively maintained, and effectively free to run beyond the cost of a domain and the host you already pay for. Automatic Let's Encrypt certificates, access lists, custom config escape hatches, and TCP/UDP streams cover the vast majority of homelab needs. The honest limitations are real: config lives in a database rather than a git file, there is no UI load balancing, the admin UI is itself an attack surface that must be protected, and upstream Nginx patching depends on the project's release cadence. None of these are disqualifying for the typical self-hoster, and all are manageable with basic hygiene. If you want a click-to-HTTPS front door you fully own, NPM remains one of the best first investments in a data-sovereign home infrastructure.