Achtung! This is a v0.* version! Expect bugs and issues all around. Submitting pull requests and issues is highly encouraged!
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.
This library is meant to be used on development or testing environments in
which setting environment variables is not practical. It loads environment
variables from a
.env file, if available, and mashes those with the actual
environment variables provided by the operative system.
The easiest and most common usage consists on calling
dotenv::dotenv when the
application starts, which will load environment variables from a file named
.env in the current directory or any of its parents; after that, you can just call
the environment-related method you need as provided by
If you need finer control about the name of the file or its location, you can
from_path methods provided by the crate.
dotenv_macros also provide the
dotenv! macro, which
behaves identically to
env!, but first tries to load a
.env file at compile
.env file looks like this:
# a comment, will be ignored REDIS_ADDRESS=localhost:6379 MEANING_OF_LIFE=42
You can optionally prefix each line with the word
export, which will
conveniently allow you to source the whole file on your shell.
A sample project using Dotenv would look like this:
extern crate dotenv; use dotenv; use env;
dotenv! macro on nightly
dotenv_macros to your dependencies, and add
the top of your crate.
dotenv! macro on stable
You can use
dotenv! on stable using
syntex. You'll need to add
syntex to your build dependencies.
extern crate syntex; extern crate dotenv_codegen; use env; use Path;
- The way errors are implemented is not as nice as it could be. Now that
FromError has landed, a better design for