mirror of
https://github.com/fosrl/pangolin.git
synced 2026-05-21 01:11:38 -05:00
[GH-ISSUE #602] How to install on VPS with already installed swag server #1525
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 @Barry40 on GitHub (Apr 25, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/602
Hi,
i cannot get this to work :-(
On my vps i have a swag docker already running, serving many websites with working letscrypt certs.
When using the 'normal' setup of Pangolin, it gives me the port in use error and doesnt start at all,
so i changed the (host) ports to 84:80 / 446:443 for example,
but now the browser serves me "404 page not found" on port 84 and a "502 bad gateway" on https port 446..
What to do?
Cant wait to play with Pangolin!
Thanks a lot!
@chris-coria commented on GitHub (Apr 25, 2025):
You need to edit Traefik dynamic conf and add router / service there. You cannot add it in pangolin as that resources are for isolated networks you would like to connect via wireguard or newt. So if your websites are in the actual VPS you would like to install Pangolin, then you need to edit Traefik to add manually the routers, middlewares and services.
@Barry40 commented on GitHub (Apr 25, 2025):
Okay, will try that.. Thanks for the fast response so far!
Btw, to what i have to change the router/middlewares and services then?
@Barry40 commented on GitHub (Apr 25, 2025):
I started over again, by zero, and that's giving me:
Error response from daemon:
failed to set up container networking:
driver failed programming external connectivity on endpoint gerbil (38xx):
failed to bind host port for 0.0.0.0:80:172.22.0.3:80/tcp: address already in use
how can i change these port(s) 80 and 443, and alse use the letscrypt wildcard cert that i already have (from swag instance)?
@akehir commented on GitHub (Apr 25, 2025):
You need to also change the ports in the
docker-compose.ymlfile. However, a lot of pangolin probably won't work without port 80 / 443 (for instance generating letsencrypt certificates via the http method).The easiest way just to play with it in your scenario is probably to stop the swag container while you use pangolin.
If you're already hosting the websites on the VPS itself, you don't really need pangolin at all (or alternatively, you should move swag to a different port and route from pangolin to swag).
@TuncTaylan commented on GitHub (Apr 28, 2025):
Take a look at the network requirements.
Pangolin needs TCP80, TCP443 and UDP 52820 to run.
@Barry40 commented on GitHub (Apr 28, 2025):
Thanks for answering, but there is no way to stop Swag.
It has a lot of other services depended on Swag.
Unifi Network, Omada Network, Portainer, Mailserver, Websites, etc so i really need Swag to use all services (with its own domains and certs).
Is there a possible way to NOT use the certs, or use my own certs, and change the ports?
Whatever i do, it keeps saying 502 bad gateway on https, and 80 not found..
I can deploy the swag instance really simple with the cert for vpn.myserver.com as example, and then use this cert in pangolin.
But even then, its still not working after changing the ports?
@akehir commented on GitHub (Apr 28, 2025):
Yeah, but for your use case, having both Swag and Pangolin is contradictory. They're both reverse proxies mapping domains and certs to services.
In your use case you'd probably want to replace Swag with Pangolin completely. Because even if you manage to install Pangolin with different ports, all your sites would still be accessible without authentication via Swag on their normal (current) ports.
If you don't want to use the http01 challenge on Pangolin you could probably change the setup to use the dns challenge - but your fundamental problems wont be solved by this.
@Barry40 commented on GitHub (Apr 30, 2025):
Okay, thanks..
@github-actions[bot] commented on GitHub (May 15, 2025):
This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
@github-actions[bot] commented on GitHub (May 29, 2025):
This issue has been automatically closed due to inactivity. If you believe this is still relevant, please open a new issue with up-to-date information.