fix: handle optional authConfig in mechanizeDockerContainer function

[Siumauricio]

• Updated the mechanizeDockerContainer function to conditionally use authConfig when creating a Docker service, ensuring proper service creation based on authentication settings.

What is this PR about?

Please describe in a short paragraph what this PR is about.

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. If you have not tested it yet, please do so before submitting. This helps avoid wasting maintainers' time reviewing code that has not been verified by you.

Issues related (if applicable)

closes #4003

Screenshots (if applicable)

Greptile Summary

This PR fixes Docker service creation for applications using private registry images by conditionally passing authConfig as the first argument to Dockerode's docker.createService(auth, opts) overload, ensuring the auth token is correctly sent as the X-Registry-Auth HTTP header.

• Fix is correct: The core change properly resolves the missing authentication header during service creation for private registries.
• Redundant authconfig in settings: settings still contains authconfig: authConfig (line 129), so auth is now passed twice in the truthy branch — once correctly as the first arg and once harmlessly in the body. Removing it from settings would clean up the intent.
• service.update not addressed: The existing-service update path (lines 175–182) spreads settings (including authconfig) but does not apply the same (auth, opts) pattern. If Dockerode's Service.update also requires auth as a separate argument for private registry re-pulls, this path could have the same latent authentication issue for service updates.

Confidence Score: 4/5

• Safe to merge — the fix is correct and addresses a real authentication bug for private registry service creation.
• The change is minimal and targeted, correctly using the Dockerode createService(auth, opts) overload. The only concerns are a minor redundancy in settings.authconfig and a pre-existing inconsistency in the service.update path that is not made worse by this PR.
• packages/server/src/utils/builders/index.ts — review the service.update path (lines 175–182) for the same auth-header concern.

Comments Outside Diff (2)

1. packages/server/src/utils/builders/index.ts, line 175-182 (link)

   service.update has same auth issue as createService

   The fix correctly passes authConfig as a separate first argument to docker.createService, which maps to the X-Registry-Auth header in the Docker API. However, the service.update call on this path uses ...settings which spreads authconfig into the request body — but Docker's service update API also requires X-Registry-Auth as a header (not a body field) for private registry images.

   Depending on how Dockerode's Service.update handles the authconfig field within the options object, updates of existing services that use private registry images may still silently fail to re-authenticate. If Dockerode's Service.update supports an (auth, opts) overload similar to createService, the same conditional auth pattern should be applied here for consistency.

2. packages/server/src/utils/builders/index.ts, line 128-129 (link)

   authconfig in settings is now redundant for the createService path

   settings still includes authconfig: authConfig at this line. After the fix, when authConfig is truthy, docker.createService(authConfig, settings) passes auth both as the dedicated first argument (correct, maps to X-Registry-Auth header) and inside the settings body as authconfig (which Docker ignores for service creation). This is harmless but redundant.

   Consider removing authconfig from the settings object and relying solely on the explicit first-argument form to keep the intent clear:

   _{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

_{Last reviewed commit: e7af2c0}