dotenv: Deployment to Heroku fails if dotenv is required in production

Documentation should be instructing users to require dotenv only in development. I just ran through this yesterday with the Sinatra version of dotenv as well and the same as happened in Express. Based on the change below, a simple Express scaffold will or won’t run on Heroku.

if (app.get('env') == 'development'){ require('dotenv').config(); }

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Comments: 15 (5 by maintainers)

Commits related to this issue

Most upvoted comments

We log an error if anything goes wrong reading the file, parsing it, or assigning to process.env (src). This seems to scare more people than it helps.

This has been covered many times before but it’s quicker just to type it out than find all the other references.

  1. dotenv can be used safely in any environment (development, staging, qa, production, etc.)
  2. Do not commit your .env file to source control. Don’t put any sensitive data in source control.
  3. You can conditionally silence the logged (not thrown) error with the silent option (require('dotenv').config({ silent: process.env.NODE_ENV === 'production' })). This will keep your Heroku deploy logs clean (or any other PaaS like AWS Elastic Beanstalk where environment variables are populated for you)
  4. We can’t help you if you don’t share any meaningful code

@gkatsanos, dotenv is a good tool to read a .env file and assign those variables to process.env.

process.env will contain the current environment’s env vars, so dotenv doesn’t have to be used in those cases. What this ends up looking like is that you want to use dotenv in development to load your .env file but not in production since the environment should have the env vars you need (i.e., in process.env).

A way you can keep dotenv outside your code and still benefit from it is by using this in your package.json for development:

"dev": "node -r dotenv/config ."

If you don’t want to use dotenv, you can always replace that line with the following:

"dev": "env $(cat .env | grep -v ^# | xargs) node ."

Hope this helps!

  1. We strongly recommend against committing your .env file to version control. See Heroku’s config vars for setting environment variables.
  2. dotenv can be used safely in any environment (development, staging, qa, production, etc.)

@guilsa, the reason it fails is because .env doesn’t exist and thus when dotenv tries to read it there is an error.

I still fail to see the usefulness of this module if it requires manual actions and I guess I m not the only one

@guilsa it should work no matter what environment that you use it in, maybe this is something application specific that is breaking when an incorrect env is loaded? Do you have a, shareable, stack trace of the crash that dotenv is creating?

We do have mention inside of our README that the .env file should not be committed.

No. We strongly recommend against committing your .env file to version control.

as well a deter people from using it in multiple environments

No. We strongly recommend against having a “main” .env file and an “environment” .env file like .env.test. Your config should vary between deploys, and you should not be sharing values between environments.

I would say it should run fine if ran in the other environments, and the recommending the usage of dotenv to be something like…

if (process.env.NODE_ENV !== 'production') require('dotenv').config()

would be kinda weird to put in our README.

Please use GitHub Issues to advance this project instead of venting your own frustrations. We are very open to improving the developer experience through better documentation and other messaging.

i just stumbled on to this thread and am confused with the conflicting statements here.

  1. The .env file shouldn’t be checked into git. How would i use this on heroku as it uses git to deploy onto their apps.
  2. I shouldn’t be using this on production? if (process.env.NODE_ENV !== ‘production’) require(‘dotenv’).config()

do i then set env vars manually?

Yeah, like @jcblw said, this is likely because you are committing your .env to version control @guilsa.

Going to go ahead and close this with that assumption. If that is not the case let us know and we’ll dive deeper.