17

Why I should not use dotenv in production mode ?

I saw the following code on some websites. But I did not understand why they are doing this condition check.

if (process.env.NODE_ENV !== 'production') {
  require('dotenv').config();
}
console.log('Bla is :', process.env.Bla);(*)

let assume that the output of the line(*) in not production mode is-> Bla is : Bla

what is the output of line (*) if the NODE_ENV is production? (According to my knowledge I think it will be undefined )

Dipak
  • 2,248
  • 4
  • 22
  • 55
Avinash
  • 275
  • 1
  • 4
  • 12
  • 3
    when NODE_ENV is production the vars are most likely configured as environment variables :) That's why there's no need to call dotenv when not in prod :) While in development a .env file is used to keep all the vars (Connection strings, credentials, etc) and dotenv used to get the contents of that file and put them on process.env.* https://www.npmjs.com/package/dotenv – Andrei Terecoasa May 19 '21 at 13:43

5 Answers5

16

Because in production, you might want to set the environment variables directly into your virtual machine, as you might not have ssh access and you can't push .env file to your version control. In my case I'm using heroku free tier and I can't ssh to create a .env file. So I set my environment variables manually in the Config Vars settings.

Heroku vm settings

Viraj Singh
  • 1,951
  • 1
  • 17
  • 27
5

Complementing the other answers, you would also create a security issue. You would be versioning (commiting to git) informations like database connections, tokens, and passwords. In this case everyone who access the code, would be able to connect to production resources.

To solve this, on production you create the env variables directly on the instance you are running the code.

Henrique Rotava
  • 781
  • 1
  • 7
  • 13
  • 2
    Regardless of whether you are using `dotenv` or not - you should never push credentials to git, this is why most projects will have a `.env.example` that "documents" the supported environment variables with dummy values If you push credentials to git... you're probably doing something wrong – Yaron U. Dec 07 '22 at 08:37
4

The idea behind this is that dotenv is generally used on a developer workstation. It is a way of using a flat file (usually named ".env") to override environment files. The reason you dont use it in production is that in production you would usually be running the application in a docker container or a dedicated server, either of which, you wouldnt need to worry about setting conflicting environment variables.

To answer the actual question, the output for that line in this case would be whatever that local environment variable is set to. If its not set, it would just be undefined.

Sarah
  • 346
  • 1
  • 3
  • 11
  • 1
    "If its not set, it would be just an empty string" - it will actually be `undefined`. You can test this yourself using `node -e console.log(process.env.NON_EXISTANT_ENV)` – samthecodingman May 19 '21 at 13:50
1

In this example, its preference of the developer. There's nothing stopping you from using it, but in production you likely have set up all the needed environment variables.

Here, they use dotenv during testing and development. This allows the developer to define their environment variables in .env files while they write the app which would be useful for preventing working on the wrong database.

So think of it like this:

When developing or testing the code, use the test keys, otherwise, use the keys provided by the environment

If the environment variable Bla wasn't set up prior to running Node, then it would be undefined, but it is likely configured to be whatever production values this code needs like an email or API key.

samthecodingman
  • 23,122
  • 4
  • 30
  • 54
1

Since dotenv 2.0.0 (released in January 2016), we don't need the if clause anymore. From the docs:

By default, we will never modify any environment variables that have already been set. In particular, if there is a variable in your .env file which collides with one that already exists in your environment, then that variable will be skipped.

I will not answer why we shouldn't use dotenv in production since it's already answered by the other answers. I just want to add: Don't use the same database password for development and production.

M Imam Pratama
  • 998
  • 11
  • 26