I used docker to containerize the node.js express app and used GitHub action to add the .env file in the container. I googled this method when I was doing the DEV project. But I think that if someone gets the docker image then they can easily find out the .env file. So I wanted to know what’s the industry standard used to deploy this .env file.


        name: Make envfile
        uses: SpicyPizza/create-envfile@v1
          envkey_DB_USER: ${{ secrets.DB_USER }}
          envkey_DB_PASS: ${{ secrets.DB_PASS }}
          envkey_DB_NAME: ${{ secrets.DB_NAME }}
          directory: /home/runner/work/IMDb-MongoDb/IMDb-MongoDb
          file_name: .env

“The .env file should never be pushed to your github repo !”

What is the standard way to use or recreate this env file after we pull the code from GitHub or when the app is deployed in a container?

  • 5
    You don't recreate the .env file. The point of it is to recreate locally what you have in production, which is: an actual environment. You set the environment variables, according to the specific platform you're using.
    – jonrsharpe
    Jan 17, 2022 at 15:54
  • 1
    just wanted explicitly add that .env are a development tool, only to be used during development, should never be shared and always excluded from version control and never be expected to be used in any environment above local
    – Goku
    Nov 11, 2023 at 17:23

2 Answers 2


Secrets can be stored in some sort of vault. For example, for AWS it's a secrets manager service. What this does is move the secrets from your environment file to a central location. That way no one (but an admin) knows the secrets and you can have a rotation on passwords. If you need to change it, it's done once and then all the services/APIs use the new value from the vault. You don't have to deploy any code for that change. If you have a lot of services, this makes sense otherwise those credentials could be in multiple locations.

You can still use your ENV file for environment specific stuff, or application specific configuration. These items are not sensitive. At higher levels, this should be controlled by your CI/CD process, but you can still have a ENV file locally for debugging and testing.

I would strive for a vault approach for secrets, if you can't do that, just make sure those passwords are controlled outside of development and are applied during the CI/CD process when deploying. In that case, an admin will need to update the CI/CD process and re-deploy if a password needs to be changed.


.env files are used by developers to hold sensitive (e.g., passwords) and/or critical application data (e.g., API keys), that can then be safely stored in source control with the project – avoiding accidental exposure – and not need to be distributed through a client-facing portal like an app store. Players: Unless you're looking to open yourself up for potential vulnerability, it's best practice to encrypt and decrypt your .env file on both development machines and production servers while either remembering or having a system in place that allows you to keep only the decryption key out of said source control repositories, based on context/phase of deployment pipeline.

One common way this is done is via environment variables, which .env files are used to hold. When developers deploy their application, they would also need to make sure the .env file gets copied over as well. Some applications make use of something like a "config" or "secrets" package that help with this process. Because it doesn't hurt for this information to be stored in source control, some teams opt to store it there, completely encrypted using tools like BoxCryptor , VeraCrypt , etc., and decrypting only at specific points in time where absolutely necessary (e.g., on first run).

  • 1
    I disagree with them being safe to store in source control. In my experience they are specifically for data that is not stored in source control because it needs to be kept private (i.e. mostly passwords).
    – user253751
    Mar 17, 2023 at 15:30
  • 1
    .env files should always be excluded from version control, it is the 3rd tenant in a twelve-factor app 12factor.net
    – Goku
    Nov 11, 2023 at 17:27

Not the answer you're looking for? Browse other questions tagged or ask your own question.