Loads environment variables from .env
to getenv()
, $_ENV
and
$_SERVER
automagically.
This is a PHP version of the original Ruby dotenv.
- NO editing virtual hosts in Apache or Nginx
- NO adding
php_value
flags to .htaccess files - EASY portability and sharing of required ENV values
- COMPATABILITY with PHP's built-in web server and CLI runner
Basically, a .env
file is an easy way to load custom environment
variables that your application needs without having to modify .htaccess
files or Apache/nginx virtual hosts. This means you won't have to edit
any files outside the project, and all the environment variables are
always set no matter how you run your project - Apache, Nginx, CLI, and
even PHP 5.4's built-in webserver. It's WAY easier than all the other
ways you know of to set environment variables, and you're going to love
it.
curl -s http://getcomposer.org/installer | php
php composer.phar require vlucas/phpdotenv
Add your application configuration to a .env
file in the root of your
project.
S3_BUCKET=dotenv
SECRET_KEY=souper_seekret_key
You can also create files per environment, such as .env.test
:
S3_BUCKET=test
SECRET_KEY=test
You can then load .env
in your application with a single line:
Dotenv::load(__DIR__);
Or you can load a specific file such as .env.test
Dotenv::load(__DIR__, '.env.test');
All of the defined variables are now accessible with the getenv
method, and are available in the $_ENV
and $_SERVER
super-globals.
$s3_bucket = getenv('S3_BUCKET');
$s3_bucket = $_ENV['S3_BUCKET'];
$s3_bucket = $_SERVER['S3_BUCKET'];
You should also be able to access them using your framework's Request class (if you are using a framework).
$s3_bucket = $request->env('S3_BUCKET');
$s3_bucket = $request->getEnv('S3_BUCKET');
$s3_bucket = $request->server->get('S3_BUCKET');
In more advanced setups, the .env
file is generally kept
out of version control since it can contain sensitive API keys and
passwords. A separate .env.example
file is created with all
the required environment variables defined except for the sensitive
ones, which are either user-supplied for their own development
environments or are communicated elsewhere to project collaborators. The
project collaborators then independently copy the .env.example
file to
a local .env
and ensure all the settings are correct for their local
environment, filling in the secret keys or providing their own values when
necessary. In this usage, the .env
file should be added to the project's
.gitignore
file so that it will never be committed by collaborators.
This usage ensures that no sensitive passwords or API keys will ever be
in the version control history so there is less risk of a security
breach, and production values will never have to be shared with all
project collaborators.
- Fork it
- Create your feature branch (
git checkout -b my-new-feature
) - Make your changes
- Run the tests, adding new ones for your own code if necessary (
phpunit
) - Commit your changes (
git commit -am 'Added some feature'
) - Push to the branch (
git push origin my-new-feature
) - Create new Pull Request