504 gateway timeout on first request after container restart on multi-network stacks

[orey-aajaamu]

To Reproduce

1. Create a stack with a service that has two networks — one internal (for inter-service communication) and the external dokploy network
2. Deploy the stack
3. Let it sit idle for a day or two, or manually restart the service container
4. Hit the site — first request gives 504
5. Reload Traefik — works fine after

Current vs. Expected behavior

Current:
After a container restart Traefik picks the internal network IP for routing instead of the external dokploy network IP. Since Traefik can't reach the internal network, all requests time out with 504 until Traefik is reloaded.

Expected:
Traefik should always route via the external dokploy network IP. Auto-injecting traefik.docker.network=<dokploy_external_network> on any service that has Traefik labels would ensure this.

Provide environment information

OS: Ubuntu 25.04
Dokploy: V0.28.7

Which area(s) are affected? (Select all that apply)

Docker Compose

Are you deploying the applications where Dokploy is installed or on a remote server?

Same server where Dokploy is installed

Additional context

When a service is on multiple networks, Traefik's network selection is non-deterministic. It picks whichever Docker reports first, which can change between restarts. Manually adding traefik.docker.network=<external_network> to the service labels fixes it permanently. Dokploy should inject this automatically when generating Traefik labels for multi-network services.

Will you send a PR to fix it?

No

[dosubot]

Hi @orey-aajaamu! I'm Dosu and I’m helping the dokploy team.

This is a known issue! Dokploy already implements automatic traefik.docker.network=dokploy-network label injection in domain.ts, but only when isolatedDeployment is disabled. The real problem is that Traefik's global config may be missing the network directive.

Most reliable fix: Edit /etc/dokploy/traefik/traefik.yml and add the network to the docker provider:

providers:
  docker:
    exposedByDefault: false
    watch: true
    network: dokploy-network   # ADD THIS LINE

Then reload Traefik via Server Settings → Server → Reload.

This forces Traefik to always use dokploy-network for IP resolution, regardless of how many networks a container is connected to.

Related issues: #778, #821, #3200 — all describe similar multi-network 504 problems.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[orey-aajaamu]

++ This is an isolated deployment. Manually adding traefik.docker.network=app-network to the frontend service labels fixed it. Looks like the label injection doesn't happen for isolated deployments.

[dosubot]

Thanks for confirming! You've identified a real bug in the isolated deployment implementation.

Looking at the code in domain.ts, the traefik.docker.network label injection is explicitly skipped when isolatedDeployment is true. However, Dokploy still creates a custom network and connects Traefik to it — but never tells Traefik which network to use via the label.

The fix should inject traefik.docker.network=<app-name> for isolated deployments instead of skipping injection entirely. Without it, Traefik can't determine which network IP to use when the container is on multiple networks, causing the 504s you experienced.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Siumauricio]

Confirmed and fixed in #5004: isolated deployments skipped the traefik.docker.network label, so with the container on multiple networks Traefik picked the backend IP arbitrarily on every provider config rebuild (any container restart/deploy on the host) — exactly the 504-after-restart you described. The fix injects traefik.docker.network=<isolated network> (or traefik.swarm.network for stacks) automatically, so the manual label workaround will no longer be needed. Will ship in the next patch release.