dotEnv

Published on Jul 04, 2015

dotEnv keeps your configuration secrets safe, and helps you keep a clean separation between different environments.

We'll look at using ember-cli-dotenv, as well as using the regular dotenv packages for situations where ember-cli-dotenv doesn't work.

Note: why dotEnv? This was originally part of a series on ember-cli-deploy (notice deploy.js). The rest of the series has been delayed due to a caching bug.


Links

Code

npm install --save-dev ember-cli-dotenv
//.env
AWS_SECRET_ACCESS_KEY="super-secret"
STAGING_REDIS="a-little-bit-secret"
AWS_BUCKET=spark-casts
//.gitignore
.env
//config/environment.js
module.exports = function(environment) {
  var ENV = {
    AWS_BUCKET: process.env.AWS_BUCKET,
    //...
  },
  //...
}
//brocfile.js (now ember-cli-build.js)
var app = new EmberApp({
  dotEnv: {
    clientAllowedKeys: ['AWS_BUCKET'],
    path: {
      development: './path/to/.env',
      staging: './path/to/.env.staging'
  }
});
//...
//using non-secret config variables
import ENV from 'my-app/config/environment';

console.log(ENV.AWS_BUCKET)

Transcript

DotEnv is a library that lets you easily store environmental configuration variables in a file that is not watched by Git. There are two reasons you might want to use DotEnv.

The first is in order to provide a clean separation between the configurations of different environments. For example, let’s say you have an image field which is stored on s3. The article title is “Cutest thing ever” and the photo is of a cute puppy. That has a s3 key which is determined by the idea of the post. So that puppy photo is uploaded as 3 under postImages/3. Then, later, you’re working locally. You create an article called “The ISIS menace”, also posts/3 on your localhost. And then you upload a photo that is appropriate for that article. Then it gets saved to postImages/3 and propagated to your website. And now you have a public relations disaster, all because you didn’t properly separate the configuration of different environments.

The second reason to use DotEnv is to keep your secret keys a secret, safe from people like this guy, who if you zoom in on his computer screen, you can see that he’s looking at my open source GitHub repository. I almost pushed my secret AWS key this weekend before being saved by DotEnv.

So those are the two reasons we want to use DotEnv, to have a clean separation of config by environment, and to keep our keys secret. How do we make this a reality? Well, one way is to use ember-cli-dotenv. This will work for most of our needs. At the end of the episode, I’ll show another way of installing it that you can fall back on.

So first we install ember-cli-dotenv with npm, then we make our default DotEnv file. The format is the key name, then an equal sign, then the value. The value can be in quotes or not, and there are some values that do need to be in quotes. New line, and then repeat. We can set this to be ignored in our gitignore so none of your secrets will be given away, even if your code is open source. You also won’t mess up other developers’ development workflow with your own environmental quirks.

So to get those variables into our app, we use the process.env variable in config-environment.js. process.env is a node variable, so it won’t be available in our frontend files, just environment.js and other config files. As you can see when we log it out, it contains lots of system variables and our .env variables. We can use those to set variables in our Ember environment.

If these are variables that we’re wanting to use in our frontend code, we’ll have one last step to do before we can use them. In our BrocFile, we set the dotEnv configuration hash, then set the clientAlllowedKeys array. That way you can store both secret and non-secret variables in your dotEnv file and only send the non-secret ones to the frontend. If you send the secret ones, then this guy will come back, and now he’s got the Chrome inspector. To use the non-secret config variables in our Ember app, we import ENV and then access it from there.

That’s how .env works with one environment, and it’s almost as easy to make it work with multiple environments. The first step is to create another .env file. For example, .env.staging. Then you go to the BrocFile and set up variable paths. And that’s all there is to it. If you want to use the variables in the staging file, just make sure your app is run with the staging environment.

Okay. So that should work for most of your purposes, but sometimes there can be trouble when you’re trying to use stuff outside of Ember proper. For example, I had to deploy.js config file where importing was a syntax error, and where it loaded before the .env variables were added to process.env. For those situations, you can fall back on the regular .env library. This can be installed with npm. It uses the same .env files as we’ve been using, but now in our deploy.js config file, we can require and load it at the top of the file. Then our variables will show up in the process.env, just like ember-cli-dotenv does automatically in environment.js.

So that’s how you use DotEnv. You can use it for separating your development and production environments, separating the dev environments of different developers, and for keeping your secrets safe. You can use ember-cli-dotenv for most of your needs, and the regular .env library for the rest. Best of luck, and I’ll see you in the pro-episode where we use the dragEnter and dragLeave events to make our drag-and-drop file upload nicer.

Subscribe to our mailing list