fix: pin Traefik routing to the isolated network on isolated deployments - #5004
Conversation
dosubot
Bot
added
the
size:S
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| } else { | ||
| const isolatedNetwork = compose.suffix || compose.appName; | ||
| if (compose.composeType === "docker-compose") { | ||
| if (!labels.includes(`traefik.docker.network=${isolatedNetwork}`)) { | ||
| labels.unshift(`traefik.docker.network=${isolatedNetwork}`); | ||
| } | ||
| } else { | ||
| if (!labels.includes(`traefik.swarm.network=${isolatedNetwork}`)) { | ||
| labels.unshift(`traefik.swarm.network=${isolatedNetwork}`); | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
When an isolated service uses Compose's valid mapping form for labels, the surrounding Array.isArray(labels) guard skips this new network label entirely, leaving multi-network services subject to the same ambiguous Traefik backend selection and intermittent domain outages this change is intended to fix.
Knowledge Base Used: Traefik Networking
…traefik-network-label fix: pin Traefik routing to the isolated network on isolated deployments (cherry picked from commit bcab5b0) [skip ci]
|
Nice hotfix. One small follow-up question: does this also cover Compose labels written as a mapping instead of an array? Greptile called out that the current change may still skip that path. If that is still open, I can try a small follow-up PR for the mapping-form case and add a regression test around isolated deployments with multiple networks. |
2 participants
Problem
When Isolated Deployment is enabled, Dokploy intentionally skips the
traefik.docker.networklabel on domain-linked services. If the container is attached to more than one network (e.g. the isolated network plus an internal network declared in the compose file), Traefik picks the backend IP arbitrarily among the container's networks, and re-picks on every provider config rebuild (any docker event on the host).When it picks the internal network — where Traefik is not connected — the domain becomes unreachable until the next re-roll. This exactly matches the reported behavior: one successful request after redeploy, then dead, and seemingly random interference between deployments (any deploy/restart on the host triggers a re-pick for every ambiguous service).
Verified live: with two services sharing an
internalnetwork and isolation enabled, Traefik's/api/http/servicesflipped between the isolated network IP (working) and the internal network IP (dead) across consecutive config rebuilds.Fix
Emit the network hint label in isolated mode too, pointing at the isolated network (
suffix || appName) — the same networkdokploy-traefikis connected to during deploy:traefik.docker.network=<isolated network>fordocker-composetraefik.swarm.network=<isolated network>forstackAfter the fix, the selected backend IP stays pinned to the isolated network across rebuilds (verified over repeated provider refreshes, all requests 200).
Closes #4899
Closes #4040 (author confirmed it was an isolated deployment; manually adding the network label fixed it)
Related (same multi-network ambiguity class, not closed by this PR): #3945, #3313
Greptile Summary
Pins Traefik routing for isolated Compose deployments to the deployment's isolated network.
traefik.docker.networkfor Docker Compose services.traefik.swarm.networkfor Docker Swarm stacks.Confidence Score: 4/5
The mapping-form label path must be handled before merging because it bypasses the new isolated-network pin and leaves affected domains intermittently unreachable.
The new pinning logic only runs for array-form labels, while the supported mapping form skips all generated labels and therefore retains ambiguous Traefik network selection.
Files Needing Attention: packages/server/src/utils/docker/domain.ts
Reviews (1): Last reviewed commit: "fix: pin traefik routing to the isolated..." | Re-trigger Greptile
Context used: