\n \n \n | Priority | \n Environment | \n .gitignoreit? | \n Notes | \n
\n \n | \n development | \n test | \n production | \n | \n | \n
\n \n \n | highest | \n .env.development.local | \n .env.test.local | \n .env.production.local | \n Yes | \n Environment-specific local overrides | \n
\n \n | 2nd | \n .env.local | \n N/A | \n .env.local | \n Yes | \n Local overrides | \n
\n \n | 3rd | \n .env.development | \n .env.test | \n .env.production | \n No | \n Shared environment-specific variables | \n
\n \n | last | \n .env | \n .env | \n .env | \n Maybe | \n Shared for all environments | \n
\n
\n\n\nThese files are loaded during the `before_configuration` callback, which is fired when the `Application` constant is defined in `config/application.rb` with `class Application < Rails::Application`. If you need it to be initialized sooner, or need to customize the loading process, you can do so at the top of `application.rb`\n\n```ruby\n# config/application.rb\nBundler.require(*Rails.groups)\n\n# Load .env.local in test\nDotenv::Rails.files.unshift(\".env.local\") if ENV[\"RAILS_ENV\"] == \"test\"\n\nmodule YourApp\n class Application < Rails::Application\n # ...\n end\nend\n```\n\nAvailable options:\n\n* `Dotenv::Rails.files` - list of files to be loaded, in order of precedence.\n* `Dotenv::Rails.overwrite` - Overwrite existing `ENV` variables with contents of `.env*` files\n* `Dotenv::Rails.logger` - The logger to use for dotenv's logging. Defaults to `Rails.logger`\n* `Dotenv::Rails.autorestore` - Enable or disable [autorestore](#autorestore-in-tests)\n\n### Multi-line values\n\nMulti-line values with line breaks must be surrounded with double quotes.\n\n```shell\nPRIVATE_KEY=\"-----BEGIN RSA PRIVATE KEY-----\n...\nHkVN9...\n...\n-----END DSA PRIVATE KEY-----\"\n```\n\nPrior to 3.0, dotenv would replace `\\n` in quoted strings with a newline, but that behavior is deprecated. To use the old behavior, set `DOTENV_LINEBREAK_MODE=legacy` before any variables that include `\\n`:\n\n```shell\nDOTENV_LINEBREAK_MODE=legacy\nPRIVATE_KEY=\"-----BEGIN RSA PRIVATE KEY-----\\nHkVN9...\\n-----END DSA PRIVATE KEY-----\\n\"\n```\n\n### Command Substitution\n\nYou need to add the output of a command in one of your variables? Simply add it with `$(your_command)`:\n\n```shell\nDATABASE_URL=\"postgres://$(whoami)@localhost/my_database\"\n```\n\n### Variable Substitution\n\nYou need to add the value of another variable in one of your variables? You can reference the variable with `${VAR}` or often just `$VAR` in unquoted or double-quoted values.\n\n```shell\nDATABASE_URL=\"postgres://${USER}@localhost/my_database\"\n```\n\nIf a value contains a `$` and it is not intended to be a variable, wrap it in single quotes.\n\n```shell\nPASSWORD='pas$word'\n```\n\n### Comments\n\nComments may be added to your file as such:\n\n```shell\n# This is a comment\nSECRET_KEY=YOURSECRETKEYGOESHERE # comment\nSECRET_HASH=\"something-with-a-#-hash\"\n```\n\n### Exports\n\nFor compatability, you may also add `export` in front of each line so you can `source` the file in bash:\n\n```shell\nexport S3_BUCKET=YOURS3BUCKET\nexport SECRET_KEY=YOURSECRETKEYGOESHERE\n```\n\n### Required Keys\n\nIf a particular configuration value is required but not set, it's appropriate to raise an error.\n\nTo require configuration keys:\n\n```ruby\n# config/initializers/dotenv.rb\n\nDotenv.require_keys(\"SERVICE_APP_ID\", \"SERVICE_KEY\", \"SERVICE_SECRET\")\n```\n\nIf any of the configuration keys above are not set, your application will raise an error during initialization. This method is preferred because it prevents runtime errors in a production application due to improper configuration.\n\n### Parsing\n\nTo parse a list of env files for programmatic inspection without modifying the ENV:\n\n```ruby\nDotenv.parse(\".env.local\", \".env\")\n# => {'S3_BUCKET' => 'YOURS3BUCKET', 'SECRET_KEY' => 'YOURSECRETKEYGOESHERE', ...}\n```\n\nThis method returns a hash of the ENV var name/value pairs.\n\n### Templates\n\nYou can use the `-t` or `--template` flag on the dotenv cli to create a template of your `.env` file.\n\n```console\n$ dotenv -t .env\n```\nA template will be created in your working directory named `{FILENAME}.template`. So in the above example, it would create a `.env.template` file.\n\nThe template will contain all the environment variables in your `.env` file but with their values set to the variable names.\n\n```shell\n# .env\nS3_BUCKET=YOURS3BUCKET\nSECRET_KEY=YOURSECRETKEYGOESHERE\n```\n\nWould become\n\n```shell\n# .env.template\nS3_BUCKET=S3_BUCKET\nSECRET_KEY=SECRET_KEY\n```\n\n## Frequently Answered Questions\n\n### Can I use dotenv in production?\n\ndotenv was originally created to load configuration variables into `ENV` in *development*. There are typically better ways to manage configuration in production environments - such as `/etc/environment` managed by [Puppet](https://github.com/puppetlabs/puppet) or [Chef](https://github.com/chef/chef), `heroku config`, etc.\n\nHowever, some find dotenv to be a convenient way to configure Rails applications in staging and production environments, and you can do that by defining environment-specific files like `.env.production` or `.env.test`.\n\nIf you use this gem to handle env vars for multiple Rails environments (development, test, production, etc.), please note that env vars that are general to all environments should be stored in `.env`. Then, environment specific env vars should be stored in `.env.