Duplicate docker labels breaking Pangolin #748

New Issue

MrUnknownDE · 2026-04-05T17:38:03+02:00

MrUnknownDE commented

2026-04-05 17:38:03 +02:00

Originally created by @DennisGaida on 10/20/2025

Describe the Bug

I'm trying out Pangolin and want to get away from the hidden database-method of configuring things, I want everything with docker labels - enter blueprints.

Unfortunately when you do a configuration mistake and create duplicate names, all docker labels configured resources are deleted in the database, more specifically: subDomain is nulled and fullDomain is set to the base domain.

Environment

OS Type & Version: Debian & Ubuntu
Pangolin Version: 1.11.0
Gerbil Version: 1.2.1
Traefik Version: v3.5.3
Newt Version: 1.5.2

To Reproduce

Have host1 & host2
Configure host1 as follows:

labels:
      pangolin.proxy-resources.syncthing.name: syncthing
      pangolin.proxy-resources.syncthing.full-domain: syncthing-host1.domain.example.org
      pangolin.proxy-resources.syncthing.protocol: http
      pangolin.proxy-resources.syncthing.auth.sso-enabled: "true"
      pangolin.proxy-resources.syncthing.targets[0].method: http
      pangolin.proxy-resources.syncthing.targets[0].hostname: syncthing
      pangolin.proxy-resources.syncthing.targets[0].port: 8384

Configure host2 as follows

labels:
      pangolin.proxy-resources.syncthing.name: syncthing
      pangolin.proxy-resources.syncthing.full-domain: syncthing-host2.domain.example.org
      pangolin.proxy-resources.syncthing.protocol: http
      pangolin.proxy-resources.syncthing.auth.sso-enabled: "true"
      pangolin.proxy-resources.syncthing.targets[0].method: http
      pangolin.proxy-resources.syncthing.targets[0].hostname: syncthing
      pangolin.proxy-resources.syncthing.targets[0].port: 8384

Restart newt on host1 & host2. There are no errors in either newt log and no errors in the Pangolin log
Everything is still working
Restart Pangolin on host0 - no errors in the log.
Observe that newt on host1&host2 are throwing errors:

ERROR: 2025/10/20 09:55:23 Failed to connect: failed to get token: failed to request new token: Post "https://cloud.gaida.biz/auth/resource/bdfd60bc-0193-409e-8a97-4bb0500b61ff?redirect=https%3A%2F%2Fsubdomain.example.com%2Fauth%2Fresource%2Fbdfd60bc-0193-409e-8a97-4bb0500b61ff%3Fredirect%3Dhttps%253A%252F%252Fsubdomain.example.com%252Fauth%252Fresource%252Fbdfd60bc-0193-409e-8a97-4bb0500b61ff%253Fredirect%253Dhttps%25253A%25252F%25252Fsubdomain.example.com%25252Fauth%25252Fresource%25252Fbdfd60bc-0193-409e-8a97-4bb0500b61ff%25253Fredirect%25253Dhttps%2525253A%2525252F%2525252Fsubdomain.example.com%2525252Fauth%2525252Fresource%2525252Fbdfd60bc-0193-409e-8a97-4bb0500b61ff%2525253Fredirect%2525253Dhttps%252525253A%252525252F%252525252Fsubdomain.example.com%252525252Fauth%252525252Fresource%252525252Fbdfd60bc-0193-409e-8a97-4bb0500b61ff%252525253Fredirect%252525253Dhttps%25252525253A%25252525252F%25252525252Fsubdomain.example.com%25252525252Fauth%25252525252Fresource%25252525252Fbdfd60bc-0193-409e-8a97-4bb0500b61ff%25252525253Fredirect%25252525253Dhttps%2525252525253A%2525252525252F%2525252525252Fsubdomain.example.com%2525252525252Fauth%2525252525252Fresource%2525252525252Fbdfd60bc-0193-409e-8a97-4bb0500b61ff%2525252525253Fredirect%2525252525253Dhttps%252525252525253A%252525252525252F%252525252525252Fsubdomain.example.com%252525252525252Fauth%252525252525252Fresource%252525252525252Fbdfd60bc-0193-409e-8a97-4bb0500b61ff%252525252525253Fredirect%252525252525253Dhttps%25252525252525253A%25252525252525252F%25252525252525252Fsubdomain.example.com%25252525252525252Fauth%25252525252525252Fresource%25252525252525252Fbdfd60bc-0193-409e-8a97-4bb0500b61ff%25252525252525253Fredirect%25252525252525253Dhttps%2525252525252525253A%2525252525252525252F%2525252525252525252Fsubdomain.example.com%2525252525252525252Fapi%2525252525252525252Fv1%2525252525252525252Fauth%2525252525252525252Fnewt%2525252525252525252Fget-token": stopped after 10 redirects. Retrying in 3s...

Observe that synthing is now infinitely redirecting - I'll spare you the log, it looks similar to the newt log

The infinite redirect may be my specific use case as the base domain domain.example.org is the domain where Pangolin lives. Checking the database, I see that that several entries are nulled and I have to manually fix them in the database

(I anonymized the base domain in the above screenshot - so syncthing in this example has set the base domain of domain.example.org instead of the example of syncthing-host1.domain.example.org). Since there are now multiple entries in traefik with the same base domain, I assume that is why I get infinite redirects.
Given the above example from the screenshot, I need to set the subdomain for n8n, as well as the fullDomain (i.e. n8n.domain.example.org) in the database and the same goes for the other three nulled entries. Secondly the newt instances can't "fix themselves", since the newt endpoint as per documentation is https://domain.example.org and that right now is infinitely redirecting.

After fixing everything in the database and restarting Pangolin, everything is back in order. Of course I need to fix the non-unique names in host1 and host2 otherwise I can recreate the same problem when restarting.

Expected Behavior

A misconfiguration of newt / docker-labels should not result in a catastrophic failure. Documentation doesn't specify that the name needs to be unique (it makes sense, of course) - Pangolin should actually just add e.g. -1 suffix if the name already exists and not delete things.
Secondly when playing around with the docker labels, I figured out that the name within the key is also important, i.e. pangolin.proxy-resources.<name>.name: something. When having multiple pangolin.proxy-resources with the same <name> across multiple hosts, things also go awry. So the best practice seems to be (not documented) to have unique a <name> within the docker label key, as well as a unique name as the actual name. I guess you should always suffix your names with the host names or something like that and then again this could be something newt could be automatically doing.

As for newt not being able to "fix itself" due to the Pangolin endpoint being broken - can't i use another internal endpoint, so that newt <-> Pangolin always works? Right now I am using the public domain as the endpoint, but newt <-> Pangolin could also talk via VPN IP (e.g. Tailscale/Zerotier etc.), so the "safer" endpoint could be <VPN-IP>, couldn't it?

*Originally created by @DennisGaida on 10/20/2025* ### Describe the Bug I'm trying out Pangolin and want to get away from the hidden database-method of configuring things, I want everything with docker labels - enter blueprints. Unfortunately when you do a configuration mistake and create duplicate names, **all** docker labels configured resources are deleted in the database, more specifically: `subDomain` is nulled and `fullDomain` is set to the base domain. ### Environment OS Type & Version: Debian & Ubuntu Pangolin Version: 1.11.0 Gerbil Version: 1.2.1 Traefik Version: v3.5.3 Newt Version: 1.5.2 ### To Reproduce 1. Have host1 & host2 2. Configure host1 as follows: ``` labels: pangolin.proxy-resources.syncthing.name: syncthing pangolin.proxy-resources.syncthing.full-domain: syncthing-host1.domain.example.org pangolin.proxy-resources.syncthing.protocol: http pangolin.proxy-resources.syncthing.auth.sso-enabled: "true" pangolin.proxy-resources.syncthing.targets[0].method: http pangolin.proxy-resources.syncthing.targets[0].hostname: syncthing pangolin.proxy-resources.syncthing.targets[0].port: 8384 ``` 3. Configure host2 as follows ``` labels: pangolin.proxy-resources.syncthing.name: syncthing pangolin.proxy-resources.syncthing.full-domain: syncthing-host2.domain.example.org pangolin.proxy-resources.syncthing.protocol: http pangolin.proxy-resources.syncthing.auth.sso-enabled: "true" pangolin.proxy-resources.syncthing.targets[0].method: http pangolin.proxy-resources.syncthing.targets[0].hostname: syncthing pangolin.proxy-resources.syncthing.targets[0].port: 8384 ``` 3. Restart newt on host1 & host2. There are no errors in either newt log and no errors in the Pangolin log 4. Everything is still working 5. Restart Pangolin on host0 - no errors in the log. 6. Observe that newt on host1&host2 are throwing errors: ``` ERROR: 2025/10/20 09:55:23 Failed to connect: failed to get token: failed to request new token: Post "https://cloud.gaida.biz/auth/resource/bdfd60bc-0193-409e-8a97-4bb0500b61ff?redirect=https%3A%2F%2Fsubdomain.example.com%2Fauth%2Fresource%2Fbdfd60bc-0193-409e-8a97-4bb0500b61ff%3Fredirect%3Dhttps%253A%252F%252Fsubdomain.example.com%252Fauth%252Fresource%252Fbdfd60bc-0193-409e-8a97-4bb0500b61ff%253Fredirect%253Dhttps%25253A%25252F%25252Fsubdomain.example.com%25252Fauth%25252Fresource%25252Fbdfd60bc-0193-409e-8a97-4bb0500b61ff%25253Fredirect%25253Dhttps%2525253A%2525252F%2525252Fsubdomain.example.com%2525252Fauth%2525252Fresource%2525252Fbdfd60bc-0193-409e-8a97-4bb0500b61ff%2525253Fredirect%2525253Dhttps%252525253A%252525252F%252525252Fsubdomain.example.com%252525252Fauth%252525252Fresource%252525252Fbdfd60bc-0193-409e-8a97-4bb0500b61ff%252525253Fredirect%252525253Dhttps%25252525253A%25252525252F%25252525252Fsubdomain.example.com%25252525252Fauth%25252525252Fresource%25252525252Fbdfd60bc-0193-409e-8a97-4bb0500b61ff%25252525253Fredirect%25252525253Dhttps%2525252525253A%2525252525252F%2525252525252Fsubdomain.example.com%2525252525252Fauth%2525252525252Fresource%2525252525252Fbdfd60bc-0193-409e-8a97-4bb0500b61ff%2525252525253Fredirect%2525252525253Dhttps%252525252525253A%252525252525252F%252525252525252Fsubdomain.example.com%252525252525252Fauth%252525252525252Fresource%252525252525252Fbdfd60bc-0193-409e-8a97-4bb0500b61ff%252525252525253Fredirect%252525252525253Dhttps%25252525252525253A%25252525252525252F%25252525252525252Fsubdomain.example.com%25252525252525252Fauth%25252525252525252Fresource%25252525252525252Fbdfd60bc-0193-409e-8a97-4bb0500b61ff%25252525252525253Fredirect%25252525252525253Dhttps%2525252525252525253A%2525252525252525252F%2525252525252525252Fsubdomain.example.com%2525252525252525252Fapi%2525252525252525252Fv1%2525252525252525252Fauth%2525252525252525252Fnewt%2525252525252525252Fget-token": stopped after 10 redirects. Retrying in 3s... ``` 8. Observe that synthing is now infinitely redirecting - I'll spare you the log, it looks similar to the newt log The infinite redirect may be my specific use case as the base domain `domain.example.org` is the domain where Pangolin lives. Checking the database, I see that that several entries are nulled and I have to manually fix them in the database <img width="999" height="214" alt="Image" src="https://github.com/user-attachments/assets/9bdd09d0-6943-4439-88f6-6b982f6908a9" /> (I anonymized the base domain in the above screenshot - so syncthing in this example has set the base domain of `domain.example.org` instead of the example of `syncthing-host1.domain.example.org`). Since there are now multiple entries in traefik with the same base domain, I assume that is why I get infinite redirects. Given the above example from the screenshot, I need to set the subdomain for n8n, as well as the `fullDomain` (i.e. `n8n.domain.example.org`) in the database and the same goes for the other three nulled entries. Secondly the newt instances can't "fix themselves", since the newt endpoint as per documentation is `https://domain.example.org` and that right now is infinitely redirecting. After fixing everything in the database and restarting Pangolin, everything is back in order. Of course I need to fix the non-unique names in host1 and host2 otherwise I can recreate the same problem when restarting. ### Expected Behavior A misconfiguration of newt / docker-labels should not result in a catastrophic failure. Documentation doesn't specify that the name needs to be unique (it makes sense, of course) - Pangolin should actually just add e.g. `-1` suffix if the name already exists and not delete things. Secondly when playing around with the docker labels, I figured out that the name within the key is also important, i.e. `pangolin.proxy-resources.<name>.name: something`. When having multiple `pangolin.proxy-resources` with the same `<name>` across multiple hosts, things also go awry. So the best practice seems to be (not documented) to have unique a `<name>` within the docker label key, as well as a unique name as the actual name. I guess you should always suffix your names with the host names or something like that and then again this could be something newt could be automatically doing. As for newt not being able to "fix itself" due to the Pangolin endpoint being broken - can't i use another internal endpoint, so that newt <-> Pangolin always works? Right now I am using the public domain as the endpoint, but newt <-> Pangolin could also talk via VPN IP (e.g. Tailscale/Zerotier etc.), so the "safer" endpoint could be `<VPN-IP>`, couldn't it?

MrUnknownDE closed this issue

2026-04-05 17:38:03 +02:00

MrUnknownDE added the bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug labels 2026-04-05 17:38:05 +02:00

Sign in to join this conversation.

Branches Tags

main

dev

dependabot/npm_and_yarn/dev-minor-updates-b4e5d6b9c5

revert-2766-feature/systemd-install-instructions

dependabot/npm_and_yarn/prod-patch-updates-05702d39f2

dependabot/npm_and_yarn/next-16.2.1

dependabot/npm_and_yarn/recharts-3.8.1

alerting-rules

private-site-ha

dependabot/docker/docker/library/node-25-slim

ssh

delete-account

msg-delivery

org-only-idp

cicd

patch

site-targets-auto-login

No Label bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/pangolin#748