Manage Configuration Values with Environment Variables

Is it a good practice to add .env file to a repo, because it may leak credential if the project is open-source.

What about security (see Environment Variables Considered Harmful for Your Secrets)?

Is the .env file not a configuration file? Even if the configuration data is stored in process.env, it is still passed as a file that has to be parsed in the used language. All the disadvantages mentioned apply IMO:

mistakenly checking in the wrong configuration in the wrong environment, coupling configuration with code, and scaling issues in larger server architectures

environment variables, whether passed by file or set within the environment, i'd consider runtime config. there needs to be a way between dev/stage/prod/whatever to use the same config files but still change specific values of the config on the fly. if things require a higher-level of security, secrets should be used.

fyi there are also situations that aren't present within this tut, such as running swarm or kubernetes. say an api key is set from an env var, and it needs to be immediately changed on my cluster of nodes. i can issue an env var update on the fly without rebuilding my entire artifact/build, and it's immediately updated.

Cannot connect to MongoDB! { MongoNetworkError: failed to connect to server [localhost:27017] on first connect [MongoNetworkError: connect ECONNREFUSED 127.0.0.1:27017] at Pool.<anonymous> (/Users/sahusoft/twelve-factor/foo/node_modules/mongodb-core/lib/topologies/server.js:503:11) at Pool.emit (events.js:127:13) at Connection.<anonymous> (/Users/sahusoft/twelve-factor/foo/node_modules/mongodb-core/lib/connection/pool.js:326:12) at Object.onceWrapper (events.js:219:13) at Connection.emit (events.js:127:13) at Socket.<anonymous> (/Users/sahusoft/twelve-factor/foo/node_modules/mongodb-core/lib/connection/connection.js:245:50) at Object.onceWrapper (events.js:219:13) at Socket.emit (events.js:127:13) at emitErrorNT (internal/streams/destroy.js:64:8) at process._tickCallback (internal/process/next_tick.js:152:19) name: 'MongoNetworkError', message: 'failed to connect to server [localhost:27017] on first connect [MongoNetworkError: connect ECONNREFUSED 127.0.0.1:27017]' }

@Rajat Have you startet a MongoDB instance? It is not shown in the video.

Yeah I was facing the same problem,

$ brew install mongodb

$ brew services start mongodb

@Rajat Have you startet a MongoDB instance? It is not shown in the video.

Correct, the video assumes you have a locally running mongodb instance.

Is it a good practice to add .env file to a repo, because it may leak credential if the project is open-source.

No, you don't want to necessarily add this file to your repo unless the environment variables do not need to be secure.

What about security (see Environment Variables Considered Harmful for Your Secrets)?

This course follows methodologies of the 12-Factor app, and does not necessarily contain opinions on what is considered secure or insecure. Storing credentials within environment variables aren't any less secure than storing them within application files. That said, there could be other methods (such as docker secrets) which are considered more secure depending on your application needs.

These black/white discussions needs to stop as there are many ways do to things, and one way isn't necessarily any more better or worse than all other ways. New methods and techniques are always created, and that doesn't necessarily mean that every single previous approach is no longer "correct". You need to look at your specific application and determine what is appropriate for your own needs.

It's unfortunate you felt the need to demonstrate this concept using mongodb (or any other database). It distracts from the concept and it assumes prior experience with the database in question

It's unfortunate you felt the need to demonstrate this concept using mongodb (or any other database). It distracts from the concept and it assumes prior experience with the database in question

Using a database is pretty common, it's a very valid use-case for env vars (probably my most-used case). The choice of Mongo vs MySQL vs whatever is pretty irrelevant.

Yeah I was facing the same problem,

$ brew install mongodb

$ brew services start mongodb

This doesn't seem to work. I recommend just following the mongodb installation instructions instead. https://docs.mongodb.com/manual/tutorial/install-mongodb-on-os-x/