fix: ensure Compose Traefik domain labels are written to local daemons

[AlexTMjugador]

What is this PR about?

I recently upgraded the Docker daemon of a server running Dokploy to version v29. This update broke Dokploy's Traefik v3.5.0 integration due to stricter Docker daemon API version requirements. Luckily, this issue was fixed in PR #3000, which prompted me to update Dokploy to the latest canary build to get proper support for Traefik v3.6.1.

However, after I attempted to re-deploy Docker Compose projects with the newer Dokploy build, the services no longer had any associated domain routers in Traefik's dashboard and were therefore externally unreachable.

A quick docker inspect on the affected containers showed that they lacked any Traefik labels, which Dokploy should have attached, despite the "Preview Compose" button displaying the expected extra labels. Increasing Traefik's logging verbosity further confirmed that these containers were being treated as disabled.

To investigate why Dokploy had stopped applying these labels, I remote-debugged my production Dokploy container by modifying its entrypoint to node --inspect=0.0.0.0 -r dotenv/config dist/server.mjs and attaching a debugger. Stepping through the deployment logic revealed that the writeDomainsToComposeRemote function was refusing to write the modified Docker Compose file to disk for local Dokploy deployments (i.e., when serverId is null). As a result, the domain configuration labels were never applied, because the unmodified raw Docker Compose file was used instead.

After bypassing this remote server check, Traefik integration for these deployments began working again, and I have not observed any regressions so far.

Therefore, this PR includes the necessary change to resolve the regression, which I strongly suspect was introduced by #2978, as the issue only began occurring after I updated Dokploy.

Checklist

Before submitting this PR, please make sure that:

• You created a dedicated branch based on the canary branch.
• You have read the suggestions in the CONTRIBUTING.md file https://github.com/Dokploy/dokploy/blob/canary/CONTRIBUTING.md#pull-request
• You have tested this PR in your local instance.

Issues related (if applicable)

Tackles a root cause of #2682 in the latest canary builds, but it may not fix other root causes of that issue.

[Siumauricio]

Good catch! @AlexTMjugador very probably forgot this case when I was cleaning the logic of deployments thank you

[RifkiSalim]

You are a lifesaver! Thanks for the prompt patch!

[emanueldev1]

I struggled with this for a couple of days in my case, and now after updating, the problem I'm having is a Gateway Timeout error.

In this case, it's happening after installing the Plausible template with all default settings, and I'm getting a Gateway Timeout error every time.

EDIT: i try installing a wordpress template (to chech if its only on plausible) but the problem persists in wordpress too

EDIT2, i fixed it adding the network inside the composer.yml

services:
#The service needed to be exposed
 someservice: 
    networks:
      - dokploy-network

networks:
  dokploy-network:
    name: dokploy-network
    external: true

  default:

@Siumauricio