Compose looks for .env file in current working directory, not docker-compose.yml directory

[tstirrat15]

I have a development environment setup that uses compose, and some of the environment variables are provided through a .env file. When I run docker-compose up from the folder where the .env is, everything works fine. When I run up from a subdirectory, the .env variables aren't picked up.

It would make more sense to me if the .env file was expected to be in the same directory as docker-compose.yml and that docker-compose would only look there for the .env file.

[shin-]

Thank you for the feedback! However, the feature currently works as documented, and it is not something we intend to change for the foreseeable future.

[tstirrat15]

Oh! Okay, I missed that. I'll make sure to document in my own project. Thank you for your response!

[shin-]

Just to give some context, the reason it works like that is because the .env file also allows to define the COMPOSE_FILE variable, which obviously needs to be read before we can evaluate where the Compose file is located. :)

[tstirrat15]

Ahhhh. That makes some sense. Thanks!

[t-hofmann]

I stumbled also on this.
Out of curiosity, what would be the use case for defining a COMPOSE_FILE in an .env-file?

Actually I would rather prefer if the docker-compose.yml would point to an environment-file and make the file ".env" present in the same directory as the docker-compose.yml the default. The rationale would be that users of docker-compose seem to be trained that the default entrypoint for looking up the configuration by docker-compose is the first docker-compose.yml found if going up the directory structure. Surprisingly this behaviour suddenly changes if an .env-file comes into play. Without a strong use case for the deviation from the intuitively anticipated behaviour it feels like a flaw in the user interface.

Still I understand that it might be problematic to change from that, therefore after some thoughts on this:
It would be nice if the .env file would be looked up the same way the docker-compose.yml is looked up. In other words, if .env is not present in the current-directory, climb up until the first of .env or docker-compose.yml is found. This would almost preserve the current behaviour. Additionally an output that states which .env-file is actually in effect would provide the user with some information on the effective configuration.

[t-hofmann]

In addition to the .env file search mechanism as describe above. It would help to have a commandline option like "--env-file FILENAME", - a file specified that way should have precedence over any other environment-file.

[sir-gon]

@shin- Sorry... but I found this feature first in this page https://docs.docker.com/compose/environment-variables/#the-env-file and is not really well documented, due is not explicit about the "current directory" of execution. In addition, is not linked to the previous page...

I think @t-hofmann solution works for our use case.

+1 to --env-file FILENAME parameter.

[paslandau]

Just had the same problem as @sir-gon - a note in https://docs.docker.com/compose/environment-variables/#the-env-file would be helpful. (Yes, I "could have just clicked the link to "environment file" - but the fact that I'm not the only one who run into this seems to justify the request somewhat ;))

[lonix1]

This is not user friendly.

Please implement --env-file FILENAME

[frederikheld]

[...]
Actually I would rather prefer if the docker-compose.yml would point to an environment-file and make the file ".env" present in the same directory as the docker-compose.yml the default. The rationale would be that users of docker-compose seem to be trained that the default entrypoint for looking up the configuration by docker-compose is the first docker-compose.yml found if going up the directory structure. Surprisingly this behaviour suddenly changes if an .env-file comes into play. Without a strong use case for the deviation from the intuitively anticipated behaviour it feels like a flaw in the user interface.
[...]
It would be nice if the .env file would be looked up the same way the docker-compose.yml is looked up. In other words, if .env is not present in the current-directory, climb up until the first of .env or docker-compose.yml is found. This would almost preserve the current behaviour.
[...]

I totally agree with @t-hofmann's thought sabout what user would expect. I was actually trying to specify the path to the .env file in docker-compose.yml and would never had expected that I should do it the other way round.

The solution he proposes (looking up in the directory tree until an .env file is found) would be the perfect solution imho as it is aligned with the logic of .gitignore and (in my case) package.json of npm.

[Redsandro]

Ahh, I finally understand why things weren't working the last couple of hours. The behavior deviates from env_file lookup. Who would have guessed. I actually did read the docs a couple of times. I guess I skipped over the the very first line where it reads:

... placed in the folder where the docker-compose command is executed (current working directory).

My suggestion would be when deviating from expectation (namely similar behavior to env_file specified files), the doc should have a big different colored section with an exclamation mark. No one reads the docs; we all scan the docs.

[axelitus]

I know this issue is old but I stumbled upon it because I was having the same issue. There's no --env-file option but you can use the --project-directory to set the current working dir to the directory where the .env file is located along with the docker-compose.yml and it works that way.

For my use case the command looks like this:

docker-compose -f .my_docker_folder/docker-compose.yml --project-directory=.my_docker_folder config

[Redsandro]

@axelitus thank you for sharing. This helps me out.

[jrbecart]

@axelitus 🥇 I was looking for that today, it's very helpful when building in CI

[Samuel-B-D]

Would be nice if there was a way to specify it in docker-compose.yml...

I realized that I've been always using docker-compose commands from a sub-directory, which worked fine.

I have a project containing a docker-compose configuration to launch a development environment, which seems a pretty common use-case.

I recently added a private git repo as a project dependancy. The dockerfile build process now require ssh credentials to do npm install to be able to access the private repo.

After looking around, the only way for the differents dev to be able to specify the path to their own ssh private key would be to have it in a .env, and pass it as a build ARG. However, doing so means that now, if docker-compose commands are ran in a subfolder, it will now crash...

[TUISTERa]

--env-file PATH Specify an alternate environment file
docker-compose --env-file /opt/docker/.env -f /opt/docker/docker-compose.yml config
Command is added to docker-compose, working as desired.
docker-compose version 1.25.4, build 8d51620

[giovanni-nabil]

I'd like to know if this was changed at any point of time,
I'm working with and old version of Docker 20.10.2 and Compose version 2.17.2, I have .env file in project root directory (where I run commands from) and another .env file in sub-directory where docker-compose.yml live ... the one in the sub-directory is always picked. but when I switched to later version of Docker and Compose 2.24.2, this behavior changed and is now looking for .env file in the current working directory (root).

was it documented somewhere? I looked at the release notes from 2.17 to 2.24 and couldn't find it

[ndeloof]

@giovanni-nabil I tried to reproduce using latest codebase, seems this has been either fixed or I misunderstood your setup:

 ~ cat .env 
BAR=bar
 ~ cat truc/.env
BAR=TEST
 ~ cat truc/compose.yaml 
services:
  test:
    image: hello-world
    environment:
      FOO: $BAR
 ~ docker compose -f truc/compose.yaml config
name: truc
services:
  test:
    environment:
      FOO: TEST
    image: hello-world
    networks:
      default: null
networks:
  default:
    name: truc_default

or maybe related to #11405