Feature Request: option to disable reading from .env

[jonmchan]

Similar/repeat request to #4642. New/different reason now though. Related to #6511.

Other systems use the exact same file .env for parsing and processing environment variables. With the release of 1.24.0, the feature where Compose will no longer accept whitespace in variable names sourced from environment files. This matches the Docker CLI behavior. breaks compatibility with other .env utilities. Although my setup does not use the variables in .env for docker-compose, docker-compose now fails because the .env file does not meet docker-compose's format.

I either have to make the .env file fit docker-compose's format or remove the file.

I propose that you can specify an option to ignore the .env file or specify a different .env file (such as .docker.env) in the docker-compose.yml file so that we can work around projects that are already using the .env file for something else.

[chris-crone]

Hi @jonmchan,

Thanks for your report. I would prefer to keep issues in the same place so that we can track them. Could you please add this as a comment to the relevant issue?

I'll close this as a duplicate.

[jonmchan]

hi @chris-crone , this isn't a duplicate. This is a feature request to disable reading .env file. #4642 issue was closed and it's rational for implementing that feature has already been addressed, so it didn't seem appropriate to reopen that issue. #6511 is just rational to why we need this feature, but it is not dependent or directly related.

I think evaluating this feature request independently - "can we have a config option to disable interpreting .env file?" - would be the proper approach to addressing this feature request.

[chris-crone]

Thanks for clarifying @jonmchan I'll reopen this.

[jonmchan]

I started looking into the details for implementing such a feature - the --env-file is the only option to change the .env file location. The docker-compose.yml file is not loaded until after the environment file is read. If we were to implement a feature where the .env location could be changed from docker-compose.yml, we would have to read the docker-compose.yml to peak for the parameter beforehand resulting in either 2 reads to docker-compose.yml or changing the order of loading (which may not be good because the env file needs to be set before reading docker-compose.yml). I think reading docker-compose.yml 2 times would be acceptable, thoughts?

[alecgibson]

Definitely in favour of being able to disable .env from the docker-compose.yml. I just updated Docker to the latest stable release, and it's broken my development environment because we have a .env file lurking that was never intended for Docker consumption.

[joshchernoff]

.env is such a standard outside of docker, allowing docker to dictate to me how I should be using it and given I'm not even using it to configure docker itself I feel its a complete overreach by docker.

Thank you for this feature, I hope it gets merged soon.

[rofrano]

Docker just broke my development environment too. :( As a Python developer I use autoenv extensively so all of my .env files start with:

if [ -d "venv" ]; then
  deactivate > /dev/null 2>&1
  source venv/bin/activate
fi

export FLASK_APP=service:app
... blah, blah, blach, etc.

This allows me to simply cd into a folder and have that Python virtual environment immediately activated.

We need a way to disable this behavior or at a minimum have it give a warning and keep going because my .env file is not meant for docker consumption.

[lawrencejones]

This is massively frustrating team! .env is used by so many applications and now all the docker tooling breaks whenever it tries reading what other tools consider to support full bash syntax.

The change will have made these tools unusable in people's dev environments :(

[jonmchan]

Everyone please comment on PR #6850. I don't think it properly addresses this issue, but I would love to get everyone else's feedback. Thanks!

[jelhan]

A work-a-round that is essentially the same as a --skip-env-file flag:

docker-compose --env-file /dev/null

[DominikSerafin]

Seems the /dev/null workaround stopped working after new update (https://docs.docker.com/compose/release-notes/#1286)

[rochinworks]

Still experiencing this issue. Docker compose is reading from whatever context it is given and automatically sources the .env. Any tooling is appreciated to navigate this.

[jonmchan]

Kindly request comments and help on my proposed PR #8322 to fix this issue. This PR would read the docker-compose.yml file an additional time looking for an x-env-file key. If found, and no --env-file option was passed, it would utilize the env-file defined in the docker-compose.yml file. I believe this would solve a lot or all of the problems we have with applications conflicting with docker .env files. One can simply direct docker-compose to utilize something like .env.docker from the docker-compose.yml file and avoid any conflicts.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jelhan]

Still missing a solution for the problem. No updates. But let's make the bot happy. Sorry for the spam.

[stale]

This issue has been automatically marked as not stale anymore due to the recent activity.

[jonmchan]

@jelhan I do have a proposal for a solution to the problem - #8322. It is missing tests and I don't know enough of python to feel confident that I implemented it properly. Would kindly request for someone to pick up reviewing and implementing my proposal in PR 8322.

[Daghall]

Quick and dirty workaround: alias docker-compose='docker-compose --env-file /dev/null'

[r3cha]

Same thing with my current v2.7.0
I've service in another folder and related to this folder .docker.env file, .env file at root folder and compose file like

  service_name:
    ...
    env_file:
      - project_folder/.docker.env
    ...

when run this container docker compose run service_name sh
if environment var that I have in .docker.env present inside .env file - value overrides from .env file. I think first to submit PR, but I don't know go so much :(

[terion-name]

absolutely needed feature. .env vars cannot be overriden even with services.app.environment or services.app.env_file and docker-compose --env-file=docker.env up --build also doesn't work. And .env for local launch and docker are always different, and this conflict is making development a nightmare

[jacogasp]

Still needed feature as docker compose v2.20.2.
I have the following project tree

project_dir
   |_ frontend
   |  |_ .env          # used by webapp
   |  |_ envs/dev.env  # used by docker compose 
   |_ backend
   |_ nginx

and the following docker-compose.yml

services:
  frontend-dev:
    container_name: frontend-dev
    image: frontend-dev
    build:
      dockerfile: Dockerfile.dev
      context: frontend
    volumes:
      - ./frontend/:/app/
      - node_modules:/app/node_modules
    env_file:
      - frontend/envs/dev.env

docker compose correctly picks up frontend/envs/dev.env as specified in the manifest, but it still loads frontend/.env which is not expected.

[achepukov]

It takes half a day for me to find out why compose doesn't work, such annoying.

[parkerroan]

This has affected our development as well. We have .env vars used for purposes other than docker-compose. It is surprising to me that I cannot disable this check.

We have .env files setup that are wrapped in brackets: {}

This breaks all docker compose command because of this.
I tried adding env_file to the compose yaml to point to a non-existent file or empty file, but it does not affect the error, as it seems the .env file is still loaded?

We should be able to disable OR make the env_file option be actually respected fully.

add --env-file to every docker-compose command is not an adequate solution in my opinion.

I am actually trying to figure out where in the code the .env is being added prior to calling:

compose/cmd/compose/compose.go

Line 526 in 328ca3f

envFromFile, err := dotenv.GetEnvFromFile(composegoutils.GetAsEqualsMap(os.Environ()), workingDir, options.EnvFiles)

As I am not sure why we cant set the env_file: /dev/null in docker-compose.yaml and it continues to pull .env
but we can set --env-file /dev/null and it works.

If someone can point me to the line where this is occurring, I will update and add tests to fix. I will try to find it again tomorrow.

[ajfisher]

Yep - this is still a problem that has been open for >4 years...

Similar to everyone else, I have a .env file that contains all the config for my application and no matter what I set it will not route to an alternative env file. As of v2.23.0 it seems that even passing --env-file /dev/null on command line won't even prevent it any more either so the behaviour here is getting worse.

The only thing I can think of which seems to work is to have a sub folder in my project called docker and then have all of my dockerfiles and compose file in there and reference back up. This at least means that docker-compose isn't trawling the local directory for a .env file (and also means I don't need to set it to /dev/null which feels hacky.... though I'm not sure this path is any less hacky to be honest.

[ndeloof]

@ajfisher use of --env-file /dev/null is fully supported and is the recommended approach to address this issue. Can you please provide a minimalist example demonstrating it "won't even prevent it any more" ?