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 #4804

Activity

1. amankrmj09

   added

   needs-triage🔍

   on Jul 12, 2026
2. dosubot

   added

   bugSomething isn't workingSomething isn't working

   on Jul 12, 2026
3. dosubot commented on Jul 12, 2026

   

   dosubotBot

   on Jul 12, 2026 – with DosuBot

   More actions

   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.

   
4. Siumauricio commented on Aug 9, 2026

   

   Siumauricio

   on Aug 9, 2026

   Contributor

   More actions

   Thanks for the detailed report and screenshots — they helped a lot.

   I traced and tested this path and I couldn't find a bug on Dokploy's side. A few findings:

   The env -i / HOME theory doesn't apply here. That wrapper is only used in the compose paths. For applications, the whole sequence (docker login → docker tag → docker push) is generated as a single script and runs in one SSH session on the build server, so the credentials written by the login are the same ones the push reads. I reproduced the exact generated command against an authenticated registry (with and without HOME in the environment) and the push succeeds in both cases. I also ran the full flow end-to-end (registry → app → deploy) on the latest version and got Login Succeeded → Image Tagged → Image Pushed.

   No credential-key mismatch either. docker login docker.io is normalized by the Docker CLI to https://index.docker.io/v1/, which is the same key docker push docker.io/... looks up.

   What I think is actually happening: your push targets docker.io/amankrmj/bakery-eurkeaserver-lqxodd — a repository that doesn't exist yet (Dokploy appends a random suffix to the app name). Docker Hub fine-grained access tokens / organization access tokens can authenticate (so "Login Succeeded") but cannot create new repositories on push, which returns exactly denied: requested access to the resource is denied.

   Note that your manual fix wasn't actually "the same credentials": your screenshot shows USING WEB-BASED LOGIN with a device code — that's a full account session, which can create the repo. Once the repo existed, re-triggering the deployment worked because Dokploy's token push is fine against an existing repo.

   Could you verify this outside Dokploy on the build server?

   docker logout
   printf %s '<your-token>' | docker login -u <your-username> --password-stdin
   docker tag busybox:latest <your-username>/some-brand-new-repo-name:latest
   docker push <your-username>/some-brand-new-repo-name:latest

   If that push is denied too, the fix is either to pre-create the repository on Docker Hub, or use a token/credential that is allowed to create repositories (e.g. a classic PAT with full permissions).
5. amankrmj09 commented on Aug 15, 2026

   

   amankrmj09

   on Aug 15, 2026

   Author

   More actions

   Thank you for the clarification. I’m unable to reproduce the steps and provide the additional details now, as I’ve updated to a newer version of Dokploy and haven’t encountered the issue again. Thanks again for looking into it!
6. amankrmj09 commented on Aug 15, 2026

   

   amankrmj09

   on Aug 15, 2026

   Author

   More actions

   I’ll close the issue for now. If I encounter the same problem again, I’ll reopen it with the relevant details.

   Thanks again for your help!
7. amankrmj09

   closed this as not plannedon Aug 15, 2026