Skip to content

Latest commit

 

History

History
95 lines (61 loc) · 2.59 KB

README.md

File metadata and controls

95 lines (61 loc) · 2.59 KB
Raw

dotenv Build Status

Dotenv loads environment variables from .env into ENV.

Storing configuration in the environment is one of the tenets of a twelve-factor app. Anything that is likely to change between deployment environments–such as resource handles for databases or credentials for external services–should be extracted from the code into environment variables.

But it is not always practical to set environment variables on development machines or continuous integration servers where multiple projects are run. Dotenv load variables from a .env file into ENV when the environment is bootstrapped.

Installation

Rails

Add this line to your application's Gemfile:

gem 'dotenv-rails', :groups => [:development, :test]

And then execute:

$ bundle

Sinatra or Plain ol' Ruby

Install the gem:

$ gem install dotenv

As early as possible in your application bootstrap process, load .env:

require 'dotenv'
Dotenv.load

To ensure .env is loaded in rake, load the tasks:

require 'dotenv/tasks'

task :mytask => :dotenv do
    # things that require .env
end

Usage

Add your application configuration to your .env file in the root of your project:

S3_BUCKET=YOURS3BUCKET
SECRET_KEY=YOURSECRETKEYGOESHERE

You can also create files per environment, such as .env.test.

S3_BUCKET=tests3bucket
SECRET_KEY=testsecretkey

An alternate yaml-like syntax is supported:

S3_BUCKET: yamlstyleforyours3bucket
SECRET_KEY: thisisalsoanokaysecret

Whenever your application loads, these variables will be available in ENV:

config.fog_directory  = ENV['S3_BUCKET']

Capistrano integration

In your config/deploy.rb file:

require "dotenv/capistrano"

It will symlink the .env located in /path/to/shared in the new release.

Should I commit my .env file?

It is recommended that you store development-only settings in your .env file, and commit it to your repository. Make sure that all your credentials for your development environment are different from your other deployments. This makes it easy for other developers to get started on your project, without compromising your credentials for other environments.

Contributing

  1. Fork it
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Added some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create new Pull Request