I'm moving, and with that comes with going from an ISP that allows port forwarding, to one that doesn't.
I'd like to keep using a reverse proxy (Caddy, namely) on my server behind CGNAT, and forward a site with address *.example.com from an external server, to the home server.
It's fine for individual domains, like abc.example.com, with wildcard certs to do so. But there's no way to set the site URL to be a wildcard domain - the input box doesn't believe its valid.
It would be really useful if this was a feature. Thanks!
Originally created by @JackBailey on GitHub (Jun 23, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/959
I'm moving, and with that comes with going from an ISP that allows port forwarding, to one that doesn't.
I'd like to keep using a reverse proxy (Caddy, namely) on my server behind CGNAT, and forward a site with address *.example.com from an external server, to the home server.
It's fine for individual domains, like abc.example.com, with wildcard certs to do so. But there's no way to set the site URL to be a wildcard domain - the input box doesn't believe its valid.
It would be really useful if this was a feature. Thanks!
i want to keep the base domain pointing to server A but I want a specific subdomain/wildcard to point to pangolin which is on Server B and be able to use it in the panel and route resources to it.
EDIT:
I just solved this problem
basically I made an A record pointing to the ip of the vps which has pangolin on which had the domain I wanted in this case it was subdomain.domain.com
Then I added the entry in the config.yml as another domain (domain4)
I then composed 'down' and 'up', and it appeared in the list, and I just used it like it was a base domain.
So then I added the resource as you would normally and pointed the ip to the host machine (container in my case) and then the port and it all worked.
<!-- gh-comment-id:3000388385 -->
@Nafalan commented on GitHub (Jun 24, 2025):
I'm having the same issue
i want to keep the base domain pointing to server A but I want a specific subdomain/wildcard to point to pangolin which is on Server B and be able to use it in the panel and route resources to it.
**EDIT:**
I just solved this problem
basically I made an A record pointing to the ip of the vps which has pangolin on which had the domain I wanted in this case it was subdomain.domain.com
Then I added the entry in the config.yml as another domain (domain4)
I then composed 'down' and 'up', and it appeared in the list, and I just used it like it was a base domain.
So then I added the resource as you would normally and pointed the ip to the host machine (container in my case) and then the port and it all worked.
That appears to be working for individual subdomains such as test.example.com or zxy.test.example.com, but what if you want to forward the entire subdomain *.test.example.com to a second reverse proxy, while still being protected by Pangolin?
So far, the only way I’ve managed to make this work is by manually adding the route and service to the dynamic_config.yml, but it would be great if this were possible in the UI as well.
<!-- gh-comment-id:3020764076 -->
@Oc3anAri3s commented on GitHub (Jun 30, 2025):
That appears to be working for individual subdomains such as `test.example.com` or `zxy.test.example.com`, but what if you want to forward the entire subdomain `*.test.example.com` to a second reverse proxy, while still being protected by Pangolin?
So far, the only way I’ve managed to make this work is by manually adding the route and service to the `dynamic_config.yml`, but it would be great if this were possible in the UI as well.
```
http:
routers:
caddy:
rule: 'HostRegexp(`.+\.test\.example\.com`)'
service: caddy-host
entryPoints:
- websecure
middlewares:
- redirect-to-https
services:
caddy-host:
loadBalancer:
servers:
- url: "https://10.0.0.100:443"
```
@github-actions[bot] commented on GitHub (Jul 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.
<!-- gh-comment-id:3071448352 -->
@github-actions[bot] commented on GitHub (Jul 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.
That appears to be working for individual subdomains such as test.example.com or zxy.test.example.com, but what if you want to forward the entire subdomain *.test.example.com to a second reverse proxy, while still being protected by Pangolin? So far, the only way I’ve managed to make this work is by manually adding the route and service to the dynamic_config.yml, but it would be great if this were possible in the UI as well.
<!-- gh-comment-id:3071547315 -->
@Nafalan commented on GitHub (Jul 15, 2025):
> That appears to be working for individual subdomains such as `test.example.com` or `zxy.test.example.com`, but what if you want to forward the entire subdomain `*.test.example.com` to a second reverse proxy, while still being protected by Pangolin? So far, the only way I’ve managed to make this work is by manually adding the route and service to the `dynamic_config.yml`, but it would be great if this were possible in the UI as well.
>
> ```
> http:
> routers:
> caddy:
> rule: 'HostRegexp(`.+\.test\.example\.com`)'
> service: caddy-host
> entryPoints:
> - websecure
> middlewares:
> - redirect-to-https
>
> services:
> caddy-host:
> loadBalancer:
> servers:
> - url: "https://10.0.0.100:443"
> ```
Would it be okay to explain how to use routers for requests being sent to another location
Such as rabbit
Configure Your Reverse Proxy
If you’re using your own reverse proxy, configure it to:
Proxy requests to /api/* to http://localhost:3001
Proxy all other requests to http://localhost:3002
How do I setup routers to do this?
https://www.rybbit.io/docs/self-hosting-manual
@github-actions[bot] commented on GitHub (Jul 30, 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.
<!-- gh-comment-id:3134493897 -->
@github-actions[bot] commented on GitHub (Jul 30, 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.
@oschwartz10612 commented on GitHub (Aug 7, 2025):
@Nafalan we have a current open set of FR to implement path based routing. I think we will do this soon hopefully.
Otherwise I think this might be a duplicate of #139 so I am going to close. Right now thats on hold and I think the recommendation would be to create resources in pangolin for each downstream service on the 2nd reverse proxy. Its not ideal but would work.
<!-- gh-comment-id:3166004050 -->
@oschwartz10612 commented on GitHub (Aug 7, 2025):
@Nafalan we have a current open set of FR to implement path based routing. I think we will do this soon hopefully.
Otherwise I think this might be a duplicate of [#139](https://github.com/fosrl/pangolin/issues/139) so I am going to close. Right now thats on hold and I think the recommendation would be to create resources in pangolin for each downstream service on the 2nd reverse proxy. Its not ideal but would work.
@AndrewPaglusch commented on GitHub (Aug 7, 2025):
I wrote a script for my specific use case, so it's very opinionated. It will "sync" all your Traefik hosts up to Pangolin as resources that point back to Traefik as a target. It essentially gives you the next-best thing to wildcard forwarding. https://github.com/AndrewPaglusch/Traefik-to-Pangolin-Sync
<!-- gh-comment-id:3166011370 -->
@AndrewPaglusch commented on GitHub (Aug 7, 2025):
I wrote a script for my specific use case, so it's very opinionated. It will "sync" all your Traefik hosts up to Pangolin as resources that point back to Traefik as a target. It essentially gives you the next-best thing to wildcard forwarding. https://github.com/AndrewPaglusch/Traefik-to-Pangolin-Sync
@Nafalan we have a current open set of FR to implement path based routing. I think we will do this soon hopefully.
Otherwise I think this might be a duplicate of #139 so I am going to close. Right now thats on hold and I think the recommendation would be to create resources in pangolin for each downstream service on the 2nd reverse proxy. Its not ideal but would work.
My friend I would say that is a stretch
Sure other reverse proxy's have things like custom location routing but this isn't a request for another reverse proxy to be used instead of traefik.
I love pangolin and sorted out my issue with making a traefik file of rules/routes and wet traefik confik to watch it for changes.
But a native solution like routing the requests inside pangolin would be awesome.
<!-- gh-comment-id:3166098972 -->
@Nafalan commented on GitHub (Aug 7, 2025):
> [@Nafalan](https://github.com/Nafalan) we have a current open set of FR to implement path based routing. I think we will do this soon hopefully.
>
> Otherwise I think this might be a duplicate of [#139](https://github.com/fosrl/pangolin/issues/139) so I am going to close. Right now thats on hold and I think the recommendation would be to create resources in pangolin for each downstream service on the 2nd reverse proxy. Its not ideal but would work.
My friend I would say that is a stretch
Sure other reverse proxy's have things like custom location routing but this isn't a request for another reverse proxy to be used instead of traefik.
I love pangolin and sorted out my issue with making a traefik file of rules/routes and wet traefik confik to watch it for changes.
But a native solution like routing the requests inside pangolin would be awesome.
I wrote a script for my specific use case, so it's very opinionated. It will "sync" all your Traefik hosts up to Pangolin as resources that point back to Traefik as a target. It essentially gives you the next-best thing to wildcard forwarding. https://github.com/AndrewPaglusch/Traefik-to-Pangolin-Sync
That's actually really cool.
I think I'll take a look into this
<!-- gh-comment-id:3166101547 -->
@Nafalan commented on GitHub (Aug 7, 2025):
> I wrote a script for my specific use case, so it's very opinionated. It will "sync" all your Traefik hosts up to Pangolin as resources that point back to Traefik as a target. It essentially gives you the next-best thing to wildcard forwarding. https://github.com/AndrewPaglusch/Traefik-to-Pangolin-Sync
That's actually really cool.
I think I'll take a look into this
@oschwartz10612 commented on GitHub (Aug 8, 2025):
This is extremely cool! Thanks for sharing. Hopefully somebody can take some use out of this!
At some point soon we will work on a declarative resource definition for newt to create resources based off of docker labels which maybe could help as well but that's not available yet.
<!-- gh-comment-id:3166189517 -->
@oschwartz10612 commented on GitHub (Aug 8, 2025):
This is extremely cool! Thanks for sharing. Hopefully somebody can take some use out of this!
At some point soon we will work on a declarative resource definition for newt to create resources based off of docker labels which maybe could help as well but that's not available yet.
Real-world use case: GitLab Pages wildcard routing through Pangolin
We run a self-hosted GitLab instance (LXC container) behind Pangolin and needed *.git-pages.com to route to GitLab Pages — a classic wildcard domain use case where subdomains are dynamically created by users.
Setup
Pangolin Site: GitLab CT on Proxmox, connected via Newt
Individual resources work fine: git.strausmann.de, registry.strausmann.de, mattermost.strausmann.de, SSH on port 2222
Wildcard *.git-pages.com cannot be created as a Pangolin resource — the UI/API doesn't accept wildcard domains
Working workaround: Manual Traefik wildcard rule
We created a static Traefik rule file on the Pangolin server that references the existing GitLab Pages Pangolin service:
This workaround requires SSH access to the Pangolin server and knowledge of Traefik internals. A native "wildcard resource" in Pangolin would:
Make this accessible through the UI/API
Automatically handle cert generation (DNS-01)
Keep health checks and access control consistent with other resources
Support use cases like GitLab Pages, Caddy subdomains, multi-tenant apps
This is essentially the same need as #139 — not just "secondary reverse proxy" but any service that dynamically serves content on arbitrary subdomains.
<!-- gh-comment-id:4109182203 -->
@strausmann commented on GitHub (Mar 23, 2026):
## Real-world use case: GitLab Pages wildcard routing through Pangolin
We run a self-hosted GitLab instance (LXC container) behind Pangolin and needed `*.git-pages.com` to route to GitLab Pages — a classic wildcard domain use case where subdomains are dynamically created by users.
### Setup
- **Pangolin Site**: GitLab CT on Proxmox, connected via Newt
- **Individual resources** work fine: `git.strausmann.de`, `registry.strausmann.de`, `mattermost.strausmann.de`, SSH on port 2222
- **Wildcard `*.git-pages.com`** cannot be created as a Pangolin resource — the UI/API doesn't accept wildcard domains
### Working workaround: Manual Traefik wildcard rule
We created a static Traefik rule file on the Pangolin server that references the existing GitLab Pages Pangolin service:
**`/docker/stacks/pangolin/config/traefik/rules/gitlab-pages-wildcard.yml`**
```yaml
http:
routers:
gitlab-pages-wildcard:
entryPoints:
- websecure
rule: "HostRegexp(`.+\\.git-pages\\.com`)"
service: 71-GitLab-Pages-service@http # ← Pangolin-managed service ID
middlewares:
- crowdsec@file
- error-pages-errors@file
- badger@http
tls:
certResolver: letsencrypt
domains:
- main: git-pages.com
sans:
- "*.git-pages.com"
priority: 50
```
Key points:
- The `service` references the Pangolin-generated service (`{resourceId}-{name}-service@http`), so traffic still flows through Gerbil → Newt → GitLab
- TLS with wildcard cert via Let's Encrypt DNS-01 challenge
- Traefik's file provider picks up the rule automatically from the `/rules` directory
- DNS: `*.git-pages.com` CNAME → `connect.strausmann.cloud` (Pangolin endpoint)
### Why native wildcard support would be valuable
This workaround requires SSH access to the Pangolin server and knowledge of Traefik internals. A native "wildcard resource" in Pangolin would:
1. Make this accessible through the UI/API
2. Automatically handle cert generation (DNS-01)
3. Keep health checks and access control consistent with other resources
4. Support use cases like GitLab Pages, Caddy subdomains, multi-tenant apps
This is essentially the same need as #139 — not just "secondary reverse proxy" but any service that dynamically serves content on arbitrary subdomains.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @JackBailey on GitHub (Jun 23, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/959
I'm moving, and with that comes with going from an ISP that allows port forwarding, to one that doesn't.
I'd like to keep using a reverse proxy (Caddy, namely) on my server behind CGNAT, and forward a site with address *.example.com from an external server, to the home server.
It's fine for individual domains, like abc.example.com, with wildcard certs to do so. But there's no way to set the site URL to be a wildcard domain - the input box doesn't believe its valid.
It would be really useful if this was a feature. Thanks!
@Nafalan commented on GitHub (Jun 24, 2025):
I'm having the same issue
i want to keep the base domain pointing to server A but I want a specific subdomain/wildcard to point to pangolin which is on Server B and be able to use it in the panel and route resources to it.
EDIT:
I just solved this problem
basically I made an A record pointing to the ip of the vps which has pangolin on which had the domain I wanted in this case it was subdomain.domain.com
Then I added the entry in the config.yml as another domain (domain4)
I then composed 'down' and 'up', and it appeared in the list, and I just used it like it was a base domain.
So then I added the resource as you would normally and pointed the ip to the host machine (container in my case) and then the port and it all worked.
@Oc3anAri3s commented on GitHub (Jun 30, 2025):
That appears to be working for individual subdomains such as
test.example.comorzxy.test.example.com, but what if you want to forward the entire subdomain*.test.example.comto a second reverse proxy, while still being protected by Pangolin?So far, the only way I’ve managed to make this work is by manually adding the route and service to the
dynamic_config.yml, but it would be great if this were possible in the UI as well.@github-actions[bot] commented on GitHub (Jul 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.
@Nafalan commented on GitHub (Jul 15, 2025):
Would it be okay to explain how to use routers for requests being sent to another location
Such as rabbit
Configure Your Reverse Proxy
If you’re using your own reverse proxy, configure it to:
How do I setup routers to do this?
https://www.rybbit.io/docs/self-hosting-manual
@github-actions[bot] commented on GitHub (Jul 30, 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.
@oschwartz10612 commented on GitHub (Aug 7, 2025):
@Nafalan we have a current open set of FR to implement path based routing. I think we will do this soon hopefully.
Otherwise I think this might be a duplicate of #139 so I am going to close. Right now thats on hold and I think the recommendation would be to create resources in pangolin for each downstream service on the 2nd reverse proxy. Its not ideal but would work.
@AndrewPaglusch commented on GitHub (Aug 7, 2025):
I wrote a script for my specific use case, so it's very opinionated. It will "sync" all your Traefik hosts up to Pangolin as resources that point back to Traefik as a target. It essentially gives you the next-best thing to wildcard forwarding. https://github.com/AndrewPaglusch/Traefik-to-Pangolin-Sync
@Nafalan commented on GitHub (Aug 7, 2025):
My friend I would say that is a stretch
Sure other reverse proxy's have things like custom location routing but this isn't a request for another reverse proxy to be used instead of traefik.
I love pangolin and sorted out my issue with making a traefik file of rules/routes and wet traefik confik to watch it for changes.
But a native solution like routing the requests inside pangolin would be awesome.
@Nafalan commented on GitHub (Aug 7, 2025):
That's actually really cool.
I think I'll take a look into this
@oschwartz10612 commented on GitHub (Aug 8, 2025):
This is extremely cool! Thanks for sharing. Hopefully somebody can take some use out of this!
At some point soon we will work on a declarative resource definition for newt to create resources based off of docker labels which maybe could help as well but that's not available yet.
@strausmann commented on GitHub (Mar 23, 2026):
Real-world use case: GitLab Pages wildcard routing through Pangolin
We run a self-hosted GitLab instance (LXC container) behind Pangolin and needed
*.git-pages.comto route to GitLab Pages — a classic wildcard domain use case where subdomains are dynamically created by users.Setup
git.strausmann.de,registry.strausmann.de,mattermost.strausmann.de, SSH on port 2222*.git-pages.comcannot be created as a Pangolin resource — the UI/API doesn't accept wildcard domainsWorking workaround: Manual Traefik wildcard rule
We created a static Traefik rule file on the Pangolin server that references the existing GitLab Pages Pangolin service:
/docker/stacks/pangolin/config/traefik/rules/gitlab-pages-wildcard.ymlKey points:
servicereferences the Pangolin-generated service ({resourceId}-{name}-service@http), so traffic still flows through Gerbil → Newt → GitLab/rulesdirectory*.git-pages.comCNAME →connect.strausmann.cloud(Pangolin endpoint)Why native wildcard support would be valuable
This workaround requires SSH access to the Pangolin server and knowledge of Traefik internals. A native "wildcard resource" in Pangolin would:
This is essentially the same need as #139 — not just "secondary reverse proxy" but any service that dynamically serves content on arbitrary subdomains.