Nginx Proxy Manager Docker

The compose file used in the Nginx Proxy Manager video for setting up with docker volumes

version: "3.9"

services:
  nginx-proxy-manager:
    image: jc21/nginx-proxy-manager:latest
    container_name: nginx-proxy-manager
    ports:
      - "80:80"
      - "443:443"
      - "81:81"
    volumes:
      - npm_data:/data
      - npm_letsencrypt:/etc/letsencrypt
    restart: unless-stopped

volumes:
  npm_data:
  npm_letsencrypt:

Docker Compose for setting up with bind mounts

version: "3.9"

services:
  nginx-proxy-manager:
    image: jc21/nginx-proxy-manager:latest
    container_name: nginx-proxy-manager
    ports:
      - "80:80"
      - "443:443"
      - "81:81"
    volumes:
      - /home/lts/NGINX_Proxy_Manager/data:/data
      - /home/lts/NGINX_Proxy_Manager/letsencrypt:/etc/letsencrypt
    restart: unless-stopped


There are more options on their site

2 Likes

@LTS_Tom I think we all should be careful using NPM. It has some high unresolved CVE’s to it. I personally wouldn’t recommend it.

Ouch, so would you suggest staying with HA Proxy then? Is there any plan to remediate these CVE’s?

Security is always a concern but do you think because there were unsanitized input in the control plane for logged in users on port 81 that have been fixed it should not be used?

CVE-2024-39935 was fixed in v2.11.3
Here is the fixed issue Fix command injection when passing bash commands into the dns provide… · NginxProxyManager/nginx-proxy-manager@99cce7e · GitHub

My suggestion is not to expose the management port (81 by default) to the internet and don’t allow untrusted users access just in case there are any other unsanitized inputs.

Tom, what is the purpose of the volume for /var/run/docker.sock:/var/run/docker.sock:ro?

I didn’t do this on my set up and NPM seems to be working fine. What am I missing? Thanks.

I took it out, it’s not needed and was in there because I was not using my actual config but I had ChatGPT create a basic one real quick and it chose to add that. All the LLM’s get things wrong a lot and I usually audit before posting so that was an oversight on my part.

1 Like

Me and you know to never expose any kind of management interface to the internet. My point being this product has some higher risks than other proxies running it and knowing the majority will inevitably have bad configurations, including exposing the management port. :slight_smile:

Hi Tom, I watched and followed the video you posted on this (big thanks for creating the content) and for some reason I can NOT get my domain name to resolve. I receive a browser warning that the site can not be reached “ERR_CONNECTION_REFUSED”.

Here are my steps:

  • Create docker container for NGINX Proxy Manager
  • Set up two DNS Records for my domain at Cloudflare. An A record that points to my NGINX ip address that I would visit normally in my browser on local network, and a CNAME * pointing to my full domain name.
  • Create an SSL cert in NPM using Let’s Encrypt with the DNS challenge for Cloudflare which gets issued with no problem.
  • Set up proxy host for whatever.mydomain.com to point to the NPM dashboard as a test.
  • I checked to make sure DNS has propagated
  • Visit the url and receive an error.

One thing to note is I did choose different ports for NGINX proxy manager in my docker compose, 1880 and 18443. Is that the issue?

Really looking for some direction on how to troubleshoot this.

If I am understanding your issues then the host that the Nginx Proxy Manager is talking to is refusing the connection. Also, would fist test it on the default ports to eliminate issues and move once you know it’s working.

Ok, I updated the compose file to use ports 80, 443, and 81. This allows it to work, so is it a port forwarding issue with the router, or something different? I can definitely leave it as is, but I’m trying to increase my understanding of networking.

If you are trying to make this publicly accessible and changing the port breaks it externally but not internally, then yes, it sounds like a router port forward issue.

Ah, yea, I see what you’re saying. However, I only want the services to be accessible internally with an SSL. I don’t want the services exposed to the public at all. So I guess I still am unsure why changing the ports would be an issue.

Migrated to Nginx Proxy Manager using wildcard certificate, domain is hosted in Namecheap.

I’m using this reverse proxy behind Wireguard VPN and not exposed to internet.

So far so good, super easy to setup, thanks @LTS_Tom.

1 Like

I refuse to open ports on my firewall. I have Cloudflare tunnels to expose my websites and such. I just point the cloudflare tunnel public host name config to the internal domain name of my service. In pfSense I have host overrides pointing those domains to my Nginx instance. Works great. I have Collabora, Nextcloud, and Discourse exposed this way. At the same time, I have vault warden set up with a host override and presented internally only using the same Nginx instance. If I need to connect to vaultwarden externally I connect through tailscale.

I want to run this on my truenas (app install)

but I am not sure what to do with the ports:
ports:
- “80:80”
- “443:443”
- “81:81”

i dont think those host ports can be used?
can i change the host ports to other ports, or will this give me problems?

80 and 443 ports are reserved for truenas and cannot be changed.

I am not sure that’s true. I was able to go into my instance of TrueNAS Scale, go to system/general settings/gui and change the ports. I switched 80 to 8080 and 443 to 8443. Then I just had to update my bookmark for the web UI. I didn’t even have to update my Letsencrypt certs associated with TrueNAS.

BUT…then again, I am NOT using TrueNAS to manage my docker apps running on that same VM. I use Portainer instead, and I created my own docker compose files to use as Portainer stacks. I was tired of updates to TrueNAS breaking docker apps, so I stopped using their built in applications function/app catalog. But I can still do bind mounts directly to a desired dataset for my docker volumes, so its kind of the best of both worlds.

I also only run the portainer agent in TrueNAS scale. I have a pre-existing instance of Portainer on another VM that I use to manage docker in TrueNAS. And I use Watchtower to update my containers, so it really is disconnected from the way TrueNAS manages apps.