mirror of
https://github.com/fosrl/pangolin.git
synced 2026-07-13 11:44:41 -05:00
Best Practice for running Pangolin both locally and for tunneling? #492
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @silverjerk on GitHub (Jul 15, 2025).
Read through the docs, but still unclear on best practice for running Pangolin both locally and remotely with tunneling.
Running a 3-node Proxmox Cluster along with 2 local NAS devices. Running Pihole along with NPM for managing all local DNS and proxy to both the PVE nodes and NAS devices, along with Cloudflare for tunnels and certs when needed.
Deployed a Hetzner VPS with Pangolin to manage tunneling for the local services that require external access, mostly a few of my development services (accessed rarely) across both the PVE nodes and one of the NAS devices. Using two domains for this; one is almost always used for internal services, the other is outward facing -- but there is overlap.
Is the best practice to spin up a separate instance of Pangolin locally on my cluster and replace NPM with Pangolin for proxy management? How best to handle provisioning certs with this sort of setup, where I'm pointing my A records and wildcards to the VPS?
@oschwartz10612 commented on GitHub (Jul 16, 2025):
Yeah this is a hotly requested thing for us to figure out. I dont have a good answer right now unfortunately. It sounds like you could be on the right track and if anyone else who had done this had any thoughts please jump in!
You could definitely have 2 Pangolins but as you say the certs would not be synced across it and you would just need to manage the DNS locally but it sounds like that is covered.
You might be fine with the 2 certs - I dont know if the browsers will really complain at all but would be interested to know it that does cause you a problem.
@afunworm commented on GitHub (Jul 19, 2025):
Apologies. I don't quite understand the question. If you have Pangolin front, why do you need NPM? You can easily have everything point to Pangolin as the router. Pangolin will relay remote requests through tunnelling, and get everything else locally. Certs will be handled through Pangolin, so domain records point to Pangolin server.
Let me know if I misunderstood your question.
@silverjerk commented on GitHub (Jul 19, 2025):
I don't need or want everything running through a tunnel, as stated in my original post. I have a mixed use environment with multiple domains. When you deploy Pangolin, you have a binary choice to make, either through a VPS using tunneling, or locally via your local network. It is currently an all-or-nothing scenario unless you're running two instances.
With NPM, I can still apply certs to local services, and then use Cloudflare tunnels only for services I want to expose. With Pangolin, effectively everything runs through the tunnel unless I have a separate local instance, along with a separate domain as one domain can't have two roots applied.
Edit: to be clear, what is likely the best case scenario is that Pangolin runs locally like NPM currently does, but can connect to its secondary VPS instance if/when you need tunneling for a specific service. That's likely the feature that others are requesting. You'd get the benefit of local DNS management with proxy hosts, along with tunneling if/when needed. I'm running probably a dozen or so services per node, with a handful of others running in Coolify and Docker instances; close to 50+ services total. Every one of those would need to be tunneled in the current paradigm.
@oschwartz10612 commented on GitHub (Jul 22, 2025):
Yeah I think this is the best way forward for the project. It may take some time to get to but I think it would be good.
I do think you can get what you want though with two instances of pangolin having read your latest comment. One on the cloud and one locally. Run newt next to Pangolin locally that connects to the cloud instance. Just delegate your domains wisely between the two.
@silverjerk commented on GitHub (Jul 24, 2025):
The blocker for me is that my use case is truly mixed; both domains are used for local services and some require tunneling. What I'd need to do, but unfortunately not prepared for just yet, is to (like you said) delegate domains, one pointing to the VPS, and the other to my local services. Definitely a lack of foresight on my part, planning out my development and homelab environment, but the effort it would take to make that change is herculean at the moment. I've strongly considered the nuke option, but I'm not sure I'm ready to jump -- or fall -- of that cliff.
To be fair, I absolutely love everything the Pangolin team has done with the service -- just having ownership over the remote VPS and not having to rely on CloudFlare is enough of a selling point for me; if we can get to a place where a mixed use environment has that local/remote variability, I will migrate permanently.