fix: bump dokploy-traefik to pinned version on update (#4324)

[apotema]

Problem

Fixes #4324. Docker Compose apps with configured domains return 404 on Docker Engine 28+, even though containers are healthy and Dokploy correctly injects the Traefik labels.

The popular "no dynamic config file is generated" diagnosis in the thread is a misdiagnosis: Compose domains route via Traefik's docker/swarm provider (container labels — see utils/docker/domain.ts), not the file provider. No .yml file in /etc/dokploy/traefik/dynamic/ is expected for Compose. Applications use the file provider, which is why only Compose breaks.

The real cause (confirmed by multiple reporters): Traefik releases older than the pinned version are incompatible with Docker Engine 28+ — the docker/swarm provider stops discovering containers, so label-based routing silently yields no routes. Both reported workarounds corroborate it: downgrade Docker to 27, or bump Traefik to v3.6.7.

Why existing installs are stuck

The repo already pins TRAEFIK_VERSION = "3.6.7" (traefik-setup.ts:23), so new installs are fine. But on existing installs nothing ever bumps the Traefik image:

• reloadTraefik → docker service update --force dokploy-traefik (restart only, same image)
• the dokploy self-update only updates the dokploy image
• the pinned version is applied only by initialize*Traefik, which run at install time (setup.ts) — not on upgrade or restart

Note: setting the TRAEFIK_VERSION env var does not fix an existing install on its own — nothing recreates the running dokploy-traefik container on a dokploy restart, and the default is already correct. The missing piece is a recreate-trigger.

Fix

Add ensureTraefikUpToDate() (services/settings.ts): read the running dokploy-traefik image tag and, if below the pinned TRAEFIK_VERSION, recreate it via the existing writeTraefikSetup path (env/ports preserved; handles both Swarm service and standalone). It is a no-op when Traefik is already at or above the configured version, and it never downgrades.

It compares against the same TRAEFIK_VERSION constant used everywhere else, so it respects a user-configured version (treats it as a floor, not a hard-coded 3.6.7).

Invoked from the updateServer mutation, awaited before the dokploy service update restarts the container, so existing installs auto-heal on their next Dokploy update.

Verification

• tsc --noEmit clean on both @dokploy/server and apps/dokploy (run in a node:24.4.0-slim build with the real workspace).
• Version-gate logic checked against realistic image tags: v3.1.2 / v3.6.6 → bump; v3.6.7, v3.6.7@sha256:…, v3.7.0 → no-op; unparseable/latest → safe no-op.
• biome check clean.

Scope / notes

• Targets the local dokploy-traefik; remote-server Traefik bumping is out of scope here.
• Because the bump runs from the new code, a user upgrading into the first version that includes this gets the Traefik bump on their next update (the accepted trade-off of hooking the self-update flow rather than boot).