Self-Hosting

Pangolin vs Caddy vs Traefik vs NPM: which proxy?

Pangolin is a tunnel + identity layer; Caddy, Traefik and NPM are plain reverse proxies. Pick by whether you can open ports and how you edit config.

Problem summary

Short answer: these are not four versions of the same thing, which is why head-to-head comparisons usually confuse people. Nginx Proxy Manager, Caddy and Traefik are reverse proxies — they sit on your LAN and route incoming traffic to the right service. Pangolin is a different shape: it bundles a reverse proxy (it runs Traefik internally) with an identity layer and an outbound WireGuard tunnel, so it works when you cannot open ports at all. So the first question is not 'which proxy is best' but 'can I forward ports 80 and 443?' If yes, choose between NPM, Caddy and Traefik on how you prefer to manage config. If no — CGNAT, a locked-down ISP router, a landlord's network — Pangolin or Cloudflare Tunnel is the layer you actually need, and a plain proxy will not help.

Operator snapshotEvidence first

First proof

Compare the WAN IP shown in your router against the address a public 'what is my IP' service reports.

Screen to open

curl -s https://api.ipify.org

Expected signal

They match, which means you have a routable public IP and any of the four options can work.

Stop boundary

Stop before exposing router, NAS, hypervisor or container-management UIs directly to the internet.

Layer path

1The comparison people search for — 'Pangolin vs Caddy' — compares two different layers. Nginx Proxy Manager, Caddy and Traefik are reverse proxies: they terminate TLS and route hostnames to services, and they all assume traffic can already reach your network. Pangolin is a platform that contains a reverse proxy (Traefik) and adds two things those three do not have: an identity/authentication layer in front of your services, and an outbound WireGuard tunnel so no inbound port is needed.

2That makes the decision two questions, in order. First: can traffic from the internet reach you at all — do you have a forwardable public IP? If not, no plain proxy solves your problem and you need a tunnelled option. Second, only if the first is settled: how do you want to manage configuration — a web UI (NPM), a text file (Caddy), or container labels (Traefik)?

3Pangolin's architecture explains both its strengths and its cost. Traefik handles ingress and TLS, Gerbil manages the WireGuard peers, Badger enforces authentication as a Traefik forward-auth plugin, and Newt is a connector that dials outbound from your LAN, so site connectors are deny-by-default and expose only the resources you define. The cost is that the hub must live somewhere with a public IP — usually a small VPS you now own and must maintain.

4Safety boundary: whichever you pick, publishing a service to the internet is the risky act, not the choice of proxy. Admin interfaces and anything without its own strong authentication should stay off the public listener entirely — behind the identity layer, on a VPN, or not exposed at all.

Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

Answer the port question before comparing any tools

Check: Compare your router's WAN IP with your public IP, and check for a 100.64.0.0/10 address.

Expected result: You know whether you need a tunnel or merely a proxy.

If not: If you cannot confirm, assume CGNAT and test a tunnelled option — it works either way.

Pick the layer, then the tool

Check: If a tunnel is required, shortlist Pangolin and Cloudflare Tunnel. If not, shortlist NPM, Caddy and Traefik.

Expected result: A shortlist of two or three that can actually solve your problem.

If not: If you are still comparing across layers, you will pick something that cannot work for your network.

Choose by configuration style, not by popularity

Check: Match the tool to how you work: UI (NPM), text file in git (Caddy), container labels (Traefik).

Expected result: A tool you will still be able to operate in six months.

If not: If you are unsure, start with NPM for visibility or Caddy for simplicity; both are easy to leave later.

Stand it up with one non-critical service first

Check: Publish a single low-stakes service end to end, including certificate issuance.

Expected result: A working hostname with a valid certificate, verified from outside your network.

If not: If the certificate fails, fix challenge type and DNS before adding more services.

Decide what is allowed on the public listener

Check: List every service and mark each as public, behind-auth, or VPN-only.

Expected result: Admin interfaces and anything without strong authentication are off the public listener.

If not: If you cannot justify a service being public, do not publish it.

Safe stop: Stop before exposing router, NAS, hypervisor or container-management UIs directly to the internet.

Back up whatever holds your configuration

Check: Version-control the Caddyfile or Traefik config; back up NPM's data volume or Pangolin's database.

Expected result: You can rebuild the whole routing layer from backup.

If not: A UI-managed proxy with no backup means rebuilding every route by hand after a failure.

Write down the decision and revisit it when the network changes

Check: Record which layer you chose and why, especially the port-forwarding assumption.

Expected result: A note that stops you re-litigating the choice, and flags when it stops being true.

If not: Moving house or changing ISP can turn a working port-forward setup into a CGNAT one overnight.

Decision tree

If: No forwardable public IP (CGNAT, ISP-locked router, shared building network)

Then: A plain reverse proxy cannot solve this on its own.

Action: Use Pangolin or Cloudflare Tunnel for entry; optionally keep a plain proxy inside the LAN for routing.

If: Public IP available, and you want a UI showing routes and certificates

Then: Nginx Proxy Manager fits how you want to work.

Action: Run NPM, and take regular backups of its data volume since the UI's store is your source of truth.

If: Public IP available, and you want the smallest readable config in git

Then: Caddy is the lightest fit.

Action: Write a short Caddyfile, keep it in version control, and reload on change.

If: Public IP available, container-native stack with services changing often

Then: Traefik's label-driven discovery earns its extra concepts.

Action: Adopt Traefik v3 and add routing labels to each service's compose definition.

If: You want authentication in front of every service without assembling it yourself

Then: Pangolin bundles the identity layer that the other three leave to you.

Action: Deploy Pangolin on a VPS with Newt connecting outbound from home, and put admin services behind it.

Safe stop: Stop before exposing any admin interface directly on the public listener, whichever tool you choose.

Evidence

Evidence table

Symptom	Evidence to collect	Likely layer	Next action
Port forwarding configured but nothing reaches the service from outside	Router WAN IP compared with your public IP, and whether the WAN address is in 100.64.0.0/10	Carrier-grade NAT upstream, not proxy misconfiguration	Switch to a tunnelled option rather than debugging the proxy further
Certificate issuance keeps failing for a wildcard hostname	Which challenge type is configured and whether your DNS provider API is supported	Wildcards require DNS-01; HTTP-01 cannot issue them	Configure DNS-01 with a supported provider, or use individual hostnames
Reverse proxy works, but you cannot remember which routes exist	Whether configuration lives in a file you can read or only in a UI database	Configuration-management style, not a technical fault	Move to file-based config if auditability matters to you
New containers do not appear in routing until you edit config by hand	Whether the proxy does label-based discovery	Static configuration model (NPM, Caddy) versus dynamic (Traefik)	Adopt Traefik if zero-touch onboarding of new services is the goal
Services are reachable publicly with no login in front of them	Which services are on the public listener and what authentication each has of its own	Missing identity layer — the real risk in any of these setups	Put an auth layer in front, or take admin services off the public listener entirely

Reference

Commands and settings paths

Detect CGNAT before choosing anything

curl -s https://api.ipify.org

Where: A shell on your LAN, compared against the WAN IP in your router UI

Expected: The two addresses match, confirming a routable public IP.

Failure means: A mismatch, or a router WAN address in 100.64.0.0/10, means CGNAT and rules out plain proxies.

Safe next step: If CGNAT is confirmed, evaluate Pangolin or Cloudflare Tunnel instead.

Confirm the proxy host can actually receive on 80 and 443

sudo ss -tlnp | grep -E ':(80|443)'

Where: A shell on the machine running the reverse proxy

Expected: The proxy process is listening on both ports.

Failure means: Nothing listening means the container is not running or is not publishing those ports.

Safe next step: Fix the listener before blaming certificates or DNS.

Verify the served certificate and hostname end to end

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -dates

Where: Any machine outside your LAN

Expected: A currently valid certificate issued for the hostname you expect.

Failure means: A self-signed or mismatched certificate means the request is not reaching the proxy you think it is.

Safe next step: Trace DNS and the tunnel or port-forward path before changing proxy configuration.

Check what a Pangolin site connector is actually exposing

docker logs newt

Where: The machine on your LAN running the Newt connector

Expected: The connector reports a healthy outbound tunnel and only the resources you defined.

Failure means: Errors here mean the tunnel is down, so nothing behind it is reachable regardless of proxy config.

Safe next step: Restore the tunnel first; resource-level troubleshooting is pointless while it is down.

Hardware boundary

Hardware and platform boundary

Change only when

You cannot forward ports and are currently reaching services by ad-hoc means — a tunnelled option is the upgrade.
You are adding services often enough that hand-editing routes has become the bottleneck.
You want authentication in front of everything and are currently relying on obscurity.

Evidence that matters

Whether you have a forwardable public IP — this decides the layer before anything else.
DNS provider API support, if you want wildcard certificates via DNS-01.
For Pangolin, a small always-on VPS with a public IP and the willingness to maintain it.

Evidence that does not matter

Raw proxy throughput — all four saturate a home connection comfortably.
Memory footprint differences at home scale; they are small next to the services being proxied.

Avoid

Avoid choosing a tunnelled platform when a plain proxy would do — it adds a public VPS you must maintain.
Avoid publishing admin interfaces on the public listener regardless of which tool you pick.
Avoid running a UI-managed proxy with no backup of its configuration store.

Related tool

Use the linked tool to turn this runbook into a guided check for your exact setup.

Device setup troubleshooter

Last reviewed

2026-08-04 · Reviewed by HomeTechOps. Written to correct the framing in the underlying search demand: 'Pangolin vs Caddy' compares a tunnelled identity platform against a plain reverse proxy, so the page leads with the layer question (can you forward ports?) before any tool comparison. Pangolin's component model is taken from its own architecture documentation rather than third-party summaries, and the page is explicit that Pangolin needs a public VPS you must maintain — the cost most comparisons omit. No winner is declared; the safety guidance about admin interfaces applies equally to all four.

Sources/assumptions

Pangolin's component model (Traefik as ingress, Gerbil as WireGuard tunnel manager, Badger as the forward-auth plugin, Newt as the outbound site connector) is taken from Pangolin's own architecture documentation.
Pangolin is dual-licensed: a free AGPL-3.0 Community Edition plus a commercially-licensed Enterprise Edition and a hosted cloud tier. Verify the current licence terms and any hosted-tier limits on Pangolin's own site before committing.
Pangolin requires a host with a public IP (typically a small VPS) to act as the hub; it is not a pure mesh VPN, so it is not a like-for-like Tailscale replacement.
This is a fit decision, not a ranking. All four are actively maintained and none of them is the wrong answer for the setup it suits.
Nginx Proxy Manager, Caddy and Traefik all obtain Let's Encrypt certificates automatically; the differences discussed here are about configuration style and operational fit, not TLS capability.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

Pangolin Docs: System architecturePrimary source for Pangolin's component model — Traefik as the ingress/reverse proxy, Gerbil as the WireGuard tunnel manager, Badger as the forward-auth Traefik plugin, and Newt as the outbound-only site connector — plus the deny-by-default behaviour of site connectors.Pangolin (fosrl/pangolin) on GitHubUsed for Pangolin's AGPL-3.0 licensing, project maturity, and the split between the free Community Edition and the commercially-licensed Enterprise Edition / Pangolin Cloud tiers.Caddy: Automatic HTTPSUsed for Caddy v2.11's automatic-HTTPS-by-default, the Caddyfile reverse_proxy directive, and the .ts.net special-case; DNS plugins need an xcaddy custom build.Traefik Proxy documentationUsed for Traefik v3.x label-driven Docker routing (routers/services/middleware), exposedbydefault=false, and the api@internal dashboard handling.Let's Encrypt: Rate limitsUsed for cert-issuance rate-limit math: 5 duplicate certs per identical SAN set per 7 days, 50 certs per registered domain per 7 days, 300 new orders per account per 3 hours, 5 failed validations per identifier per hour. Wildcard avoids the duplicate limit during iteration.Nginx Proxy ManagerUsed for NPM (GUI on nginx + certbot): beginner-friendly but config lives in a DB (no git), admin runs on port 81 (keep LAN/VPN-only).

Diagnostic rule

1. Check the simplest signal first.
2. Change one thing at a time.
3. Confirm the layer (app, container, network) before deep config.
4. Prove the restore; don't assume it.

FAQ

Pangolin vs Caddy — which should I use?

They solve different problems, so the honest answer is 'probably not the same one'. Caddy is a single-binary reverse proxy with a short, readable config file and automatic HTTPS; it is the lightest way to put your services behind clean hostnames when you can forward ports 80 and 443. Pangolin is a tunnelled platform: it runs Traefik internally, adds a login/SSO layer in front of your services, and reaches your home over an outbound WireGuard tunnel from a VPS, so it works behind CGNAT with no ports open. Pick Caddy if you can port-forward and want minimal moving parts. Pick Pangolin if you cannot open ports, or you want authentication in front of every service without bolting on Authelia or Authentik.

Pangolin vs Traefik — isn't Pangolin just Traefik?

Pangolin uses Traefik as its ingress component, so in a sense you get Traefik either way. The difference is everything wrapped around it: Pangolin adds a dashboard, an identity and access layer (its Badger plugin enforces auth via Traefik's forward-auth), a WireGuard tunnel manager, and the Newt site connector that dials out from your LAN. Running Traefik directly gives you Docker-label auto-discovery and full control, but you configure auth, remote access and TLS routing yourself. Choose raw Traefik if your stack is container-native and you want to own the configuration; choose Pangolin if you want the tunnel and the login page to come as part of the package.

Caddy vs Nginx Proxy Manager — which is better for a first home setup?

Nginx Proxy Manager if you want to see and click what you are configuring; Caddy if you are comfortable editing a text file. NPM gives you a web UI showing every route, which certificate is active, and which renewal failed — genuinely useful when you are learning what a reverse proxy does. Its downside is that the UI and its database become the source of truth, which is harder to back up and version than a file. Caddy's config is a handful of lines you can keep in git, and it does automatic HTTPS with almost no ceremony. Many operators start on NPM and move to Caddy once the model clicks.

Do I need Pangolin if I already use Cloudflare Tunnel?

No — they occupy the same slot, and Pangolin is essentially the self-hosted equivalent. Both get traffic into a network you cannot port-forward into. The reasons to move from Cloudflare Tunnel to Pangolin are wanting to own the whole path, avoiding Cloudflare's proxy terms around large media streaming, and not being bound to a third party's edge. The cost is that you now run and maintain the public-facing VPS yourself, including its updates and its security. If Cloudflare Tunnel is working for you and you are comfortable with the terms, there is no urgent reason to switch.

Which of these works behind CGNAT?

Only the tunnelled options. Nginx Proxy Manager, Caddy and Traefik all assume traffic can reach your network from the internet, which requires a forwardable public IP — behind CGNAT you do not have one, so none of them can help on their own. Pangolin, Cloudflare Tunnel and a mesh VPN like Tailscale all work because the connection is established outbound from your network. Confirm you are actually behind CGNAT first rather than assuming, using the check on our CGNAT page; a surprising number of 'CGNAT' problems turn out to be a router in bridge mode or a firewall rule.

Can I run a plain reverse proxy and a tunnel together?

Yes, and it is a common and sensible setup. The tunnel answers 'how does traffic from the internet reach my network', and the reverse proxy answers 'once it is inside, which service does each hostname go to'. Running Cloudflare Tunnel or Pangolin at the edge and Caddy or NPM inside the LAN is a clean split, and it means your internal routing does not change if you swap the remote-access layer later.

Planning a purchase?

We keep a source-backed, price-free comparison so you can buy once and right. No star ratings, every spec cited.

Mini PC for a Home Server: N150 vs MS-01 vs Tiny →