Registry login succeeds but image push fails ("denied: requested access to the resource is denied") when using a remote/build server — manual docker login on the VPS fixes it

[amankrmj09]

To Reproduce

1. Configure an external registry in Dokploy (Dashboard → Registry) with valid Docker Hub (or other registry) credentials.

2. Assign a remote/dedicated Build Server (Advanced → Build Server) different from the Dokploy host, and select the registry above as the Build Registry.

3. Trigger a deployment for an application using this build server + registry.

4. Observe the logs: registry login reports success, build completes, but the push step fails with denied: requested access to the resource is denied.

5. SSH into the build server and manually run docker login with the same credentials.

6. Re-trigger the deployment — push now succeeds.

Current vs. Expected behavior

Current: Dokploy logs into the registry successfully ("Login Succeeded" / "Registry Login Success"), builds the image, but then fails to push it with denied: requested access to the resource is denied. The deployment fails at this step. Manually logging in via SSH on the build server and re-triggering the deployment makes the push succeed.

Expected: Since Dokploy reports a successful registry login in its own logs, the push immediately following it should also succeed using those same credentials — without requiring a manual docker login on the build server first.

Provide environment information

Dokploy version: 0.29.10
Host: DigitalOcean VPS, 4 vCPU / 8GB RAM, Bangalore (Bengaluru) region
OS: Ubuntu 26.04 LTS
Deployment type: Remote/dedicated Build Server (different from Dokploy host)
Registry: Docker Hub (external registry, username/password or access token auth)

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

Application

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

Remote server

Additional context

This might be related to #4401, where the env -i wrapper used internally by Dokploy strips the HOME environment variable before running docker commands, causing the CLI to look for credentials at the wrong config path (e.g. /.docker/config.json instead of /root/.docker/config.json) and silently fall back to unauthenticated access. I'm not fully sure they're the same issue though — #4401 is specifically about docker stack deploy --with-registry-auth in a Docker Swarm context, whereas my case is a build server pushing a freshly built image to the registry, which may go through a different code path entirely. Flagging it here in case it's useful context, but it may turn out to be a separate root cause.

I've confirmed:

• The Docker Hub access token used has Read & Write scope and is active.
• The image tag matches my namespace/account exactly (<user>/<image>:latest).
• No repository limits are being hit on Docker Hub.
• A manual docker login + docker push with the same credentials on the build server succeeds immediately.
  Happy to provide more logs, screenshots, or test a patched build if useful.

Will you send a PR to fix it?

No

[dosubot]

Hi @amankrmj09! I'm Dosu and I'm helping the Dokploy team.

Your suspicion is correct — this is related to the env -i wrapper stripping the HOME environment variable. The fix for #4401 was applied to the compose build command [1], which explicitly preserves HOME:

env -i PATH="$PATH" HOME="$HOME" ${exportEnvCommand} docker ${command}

However, other compose operations (start, stop, remove) still use the unfixed pattern [2] [3] [4]:

env -i PATH="$PATH" docker compose ...

A test file explicitly documents why HOME must be preserved [5]:

"The HOME variable must be preserved so docker can resolve ~/.docker/config.json for registry authentication (--with-registry-auth) when deploying to Docker Swarm stacks."

What's happening in your case: docker login succeeds and writes credentials to ~/.docker/config.json (e.g., /root/.docker/config.json). But when the subsequent docker push (or the buildx push step) runs under env -i without HOME, Docker CLI defaults to looking for credentials at /.docker/config.json instead, effectively running unauthenticated. That's why manual docker login on the VPS fixes it — it writes credentials to the path Docker happens to check under those conditions.

The fix would be to ensure HOME="$HOME" is included in any env -i invocation that runs Docker commands interacting with a registry. The build path was already fixed for #4401, but the push path on remote/build servers appears to still be affected.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.