Setting Up Redundant Nginx Proxy Manager on Two DietPi Nodes—Best Practices for Syncing Configs & Load-Balancing?

General Discussion
1

Hey everyone :waving_hand:,

I’m running two DietPi boards devoted to network duties (Pi-hole, Unbound, Tailscale). My primary node currently handles all reverse-proxy traffic via Nginx Proxy Manager (NPM) in Docker/Portainer and works great, but every reboot means downtime. I’d like to introduce redundancy by spinning up NPM on the secondary node and putting a load-balancer in front.

What I’ve done so far

  1. Installed Docker, Compose & Portainer on the secondary Pi.

  2. Tried deploying NPM there, but Portainer threw:

    failed to bind host port for 0.0.0.0:80 … address already in use

  3. Discovered that HAProxy, which I had just installed from dietpi-software, was already listening on :80.

  4. Removed HAProxy → redeployed NPM → stack came up fine.

The plan

  • Sync configs/certs from primary → secondary (thinking cron + rsync).
  • Re-install HAProxy (or another LB) to provide a single virtual IP in Pi-hole’s local DNS, then split traffic to whichever NPM is alive.

What I’m unsure about

  1. Config Sync: Is a simple rsync cron job the safest way to keep /docker/nginx-proxy-manager (or wherever you store your configs + LetsEncrypt certs) identical between boxes? Any gotchas with live cert renewals?
  2. Load-balancer Choice: Is HAProxy (from DietPi’s repo) the right tool here, or would you recommend something else like Keepalived, Traefik, or even Nginx itself in active-passive?
  3. Port Conflicts: After HAProxy is back, how do you cleanly avoid the :80/:443 bind clash while still off-loading TLS to NPM?

Would love to hear how others solved this or any best-practice pointers before I break production again. Thanks!

2

Personally, I don’t think this setup makes much sense, as you are placing an additional reverse proxy in front of an existing reverse proxy. In addition, HAProxy only has 1 instance. What happens if HAProxy is no longer running?

A better alternative might be keepalived + virtual IP. This gives you a virtual IP address that can switch from one SBC to the other depending on availability.

Client
  |
  | --> 192.168.1.100 (Floating IP)
            |
     +-------------+
     |             |
 +-------+     +-------+
 | Pi #1 |     | Pi #2 |
 | Nginx |     | Nginx |
 +-------+     +-------+
     |              |
     +------v-------+
            |
    +--------------------+
    | Webserver Backend  |
    | (z.B. Pi #3, #4...)|
    +--------------------+

Another option would be Docker Swarm, since you are already using Docker anyway.

1 Like
3

I will give this a try and report back. Thanks

4

Your suggestion worked well, but I skipped two-way syncing the nginx docker folders. Syncthing’s permission issues kept recurring, so I’m manually syncing for now until I find a better solution. Any ideas for reliable two-way sync that also restarts the nginx container on changes to reflect updates in the web interface?

Thanks again

5

I don’t think such a solution exists and you would need to create own scripts for this. Maybe Docker Swarm can handle this? But I’m not sure.

1 Like
6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.