Env variables getting overwritten

[bendebury]

I've got a compose file that looks like this:

services:
  gateway:
    image: docker/mcp-gateway:local
      #    pull_policy: never
    depends_on:
      dind:
        condition: service_healthy
    environment:
      - DOCKER_HOST=tcp://dind:2375
    command:
      - --servers=duckduckgo,exa
      - --secrets=/run/secrets/mcp_secret
      - --transport=streaming
    secrets:
      - mcp_secret

  # Docker-in-Docker sidecar to provide a Docker API without mounting the host socket
  dind:
    image: docker:27-dind
    privileged: true
    environment:
      - DOCKER_TLS_CERTDIR=
    command: ["--host=tcp://*******:2375", "--host=unix:///var/run/docker.sock"]
    healthcheck:
      test: ["CMD", "docker", "info"]
      interval: 5s
      timeout: 3s
      retries: 10

secrets:
  mcp_secret:
    file: .env

When I run this, I get errors that look like this:

gateway-1  | - Listing MCP tools...onfig   w Enable Watch
gateway-1  |   - Running mcp/exa with [run --rm -i --init --security-opt no-new-privileges --cpus 1 --memory 2Gb --pull never -l docker-mcp=true -l docker-mcp-tool-type=mcp -l docker-mcp-name=exa -l docker-mcp-transport=stdio -e EXA_API_KEY]
gateway-1  |   - Running mcp/duckduckgo with [run --rm -i --init --security-opt no-new-privileges --cpus 1 --memory 2Gb --pull never -l docker-mcp=true -l docker-mcp-tool-type=mcp -l docker-mcp-name=duckduckgo -l docker-mcp-transport=stdio]
gateway-1  | - exa: docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

It seems that the culprit may be in this line: It seems that when cmd.Env is set to c.env, the DOCKER_HOST env variable is dropped. Changing this line to cmd.Env = append(os.Environ(), c.env...) fixes my issue, but I'm not sure if that's a desirable fix. Regardless, it does seem like losing DOCKER_HOST is probably not the intended outcome.

[slimslenderslacks]

I think the intent here was to keep the MCP container environments isolated from the gateway environment. Is this a special case where we don't want DOCKER_HOST propogated to the duckduckgo, or exa containers but we do want the gateway to use DOCKER_HOST when it selects the engine?

[bendebury]

I'm a bit confused by the question--are you saying that the suggested change breaks the isolation, or are you saying that I should be passing DOCKER_HOST in such a way that duckduckgo and exa also have this env var and that would solve the problem I am having?

Basically, I need DOCKER_HOST to be present inside the gateway environment, but it doesn't need to be present in the MCP containers.

[slimslenderslacks]

In general, we don't want the gateway environment to be exported to the containers. But in this case, DOCKER_HOST is special. We should be observing that when doing engine discovery. So maybe it makes sense to copy just DOCKER_HOST into mcp container environment. The MCP containers won't be running privileged but by default, they have access to the host network when running in compose.

[bendebury]

What's the change you're proposing?