Composer Cannot Access GitLab from Docker: Fix with SSH Agent

At first, it looked like a GitLab permission problem or an issue with the package itself. But SSH to GitLab worked from the host, so instead of changing credentials I started comparing the host environment with the Docker workspace.

In my setup, Composer runs inside a Laradock workspace. That is where I found the actual problem: the container could not see the SSH Agent that was already available on the host.

Instead of updating the package, Composer tried to access the private GitLab repository and could not authenticate over SSH.

It then offered to create credentials and asked for a username and password. That was an important clue: Composer was not necessarily the problem. It simply could not use the GitLab access method that already worked on my host.

That made the difference obvious: GitLab SSH worked on the host but failed inside the container on the same machine.

The next thing I checked was the SSH Agent. My keys were loaded correctly on the host, while SSH_AUTH_SOCK inside the Docker workspace was empty.

SSH Agent runs as a separate process on the host and provides access to loaded SSH keys. Applications communicate with it through a socket whose path is exposed through SSH_AUTH_SOCK.

A Docker container does not automatically receive that socket. Git inside my workspace therefore had no way to use the SSH Agent even though everything was configured correctly on the host.

That was the key point for me: I did not need to copy an SSH key into the container. I needed to give the container access to the SSH Agent that was already running on the host.

The host socket is mounted inside the container as /ssh-agent, and SSH_AUTH_SOCK inside the workspace points to that location.

I use several Laradock workspaces for different PHP versions, so I applied the same anchor to every CLI workspace.

After that, I repeated the same Composer command that originally failed. This time Composer could access the private GitLab repository through Git and update the package without asking for a username or password.

dcomposer itself is part of my local multi-PHP workflow with dphp, dartisan, and dcomposer, where the correct Laradock workspace is selected automatically for each project.

For me, this was a good example of why it helps to debug the problem layer by layer:

1. GitLab SSH first,

2. Docker next,

3. then SSH Agent,

4. and Composer only after that.

• Copy a private SSH key into a Docker image or container.

• Store a GitLab password inside the container.

• Enter a Personal Access Token every time Composer asks for credentials.

• Treat it as a Composer problem before checking plain Git and SSH access from the same environment.

In my case, Composer was only showing the symptom. The actual problem existed one layer lower: Git inside Docker could not access the host SSH Agent.

Once I forwarded SSH_AUTH_SOCK through Docker Compose and mounted the agent socket into the Laradock workspace, the same SSH key worked both on the host and inside the container.

That configuration is now shared by my PHP workspaces, and private Composer packages can be updated without copying SSH keys or storing separate GitLab credentials inside Docker.