DEV Community: Dotenv

From dotenv to dotenvx: Next Generation Config Management

Dotenv — Tue, 25 Jun 2024 14:52:48 +0000

The day after July 4th 🇺🇸, I wrote dotenv's first commit and released version 0.0.1 on npm. It looked like this.

In the 11 years since, it's become one of the most depended-upon packages worldwide 🌎 – adjacent ubiquitous software like TypeScript and ESLint.

It's an example of "big things have small beginnings". The README was short and the code was humble, but today it's beloved by millions of developers.

It's one of the few security tools that improve your security posture with minimal fuss.

a single line of code - require('dotenv').config()
a single file - .env
a single gitignore append - echo '.env' > .gitignore

It's aesthetic, it's effective, it's elegant.

But it's not without its problems! And that's what I want to talk about.

The problems with `dotenv`

In order of importance, there are three big problems with dotenv:

leaking your .env file
juggling multiple environments
inconsistency across platforms

All three pose risks to security, and the first does SIGNIFICANTLY.

But I think we have a solution to all three today - with dotenvx. In reverse problem order:

Run Anywhere -> inconsistency across platforms
Multiple Environments -> juggling multiple environments
Encryption -> leaking your .env file

Let's dig into each. I'll do my best to show rather than tell.

Run Anywhere

dotenvx works the same across every language, framework, and platform – inject your env at runtime with dotenvx run -- your-cmd.

$ echo "HELLO=World" > .env
$ echo "console.log('Hello ' + process.env.HELLO)" > index.js

$ node index.js
Hello undefined # without dotenvx

$ dotenvx run -- node index.js
Hello World # with dotenvx
> :-D

The .env parsing engine, variable expansion, command substitution, and more work exactly the same. Install dotenvx via npm, brew, curl, docker, windows, and more.

This solves the problem of inconsistency across platforms. ✅ You'll get the exact same behavior for your python apps as your node apps as your rust apps.

Multiple Environments

Create a .env.production file and use -f to load it. It's straightforward, yet flexible.

$ echo "HELLO=production" > .env.production
$ echo "console.log('Hello ' + process.env.HELLO)" > index.js

$ dotenvx run -f .env.production -- node index.js
[dotenvx][info] loading env (1) from .env.production
Hello production
> ^^

While everything in dotenvx is inspired by community suggestions, this multi-environment feature particularly is. There were suggestions many times for something similar before I came to understand its usefulness. I'm convinvced now it cleanly solves the problem of juggling multiple environments when built into the command line. ✅

You can even compose multiple environments together with multiple -f flags.

$ echo "HELLO=local" > .env.local
$ echo "HELLO=World" > .env
$ echo "console.log('Hello ' + process.env.HELLO)" > index.js

$ dotenvx run -f .env.local -f .env -- node index.js
[dotenvx] injecting env (1) from .env.local, .env
Hello local

Handy! But it's the next feature, encryption, that is the real game changer (and I think merits dotenvx as the next generation of configuration management).

Encryption

Add encryption to your .env files with a single command. Run dotenvx encrypt.

$ dotenvx encrypt
✔ encrypted (.env)

#/-------------------[DOTENV_PUBLIC_KEY]--------------------/
#/            public-key encryption for .env files          /
#/       [how it works](https://dotenvx.com/encryption)     /
#/----------------------------------------------------------/
DOTENV_PUBLIC_KEY="03f8b376234c4f2f0445f392a12e80f3a84b4b0d1e0c3df85c494e45812653c22a"

# Database configuration
DB_HOST="encrypted:BNr24F4vW9CQ37LOXeRgOL6QlwtJfAoAVXtSdSfpicPDHtqo/Q2HekeCjAWrhxHy+VHAB3QTg4fk9VdIoncLIlu1NssFO6XQXN5fnIjXRmp5pAuw7xwqVXe/1lVukATjG0kXR4SHe45s4Tb6fEjs"
DB_PORT="encrypted:BOCHQLIOzrq42WE5zf431xIlLk4iRDn1/hjYBg5kkYLQnL9wV2zEsSyHKBfH3mQdv8w4+EhXiF4unXZi1nYqdjVp4/BbAr777ORjMzyE+3QN1ik1F2+W5DZHBF9Uwj69F4D7f8A="
DB_USER="encrypted:BP6jIRlnYo5LM6/n8GnOAeg4RJlPD6ZN/HkdMdWfgfbQBuZlo44idYzKApdy0znU3TSoF5rcppXIMkxFFuB6pS0U4HMG/jl46lPCswl3vLTQ7Gx5EMT6YwE6pfA88AM77/ebQZ6y0L5t"
DB_PASSWORD="encrypted:BMycwcycXFFJQHjbt1i1IBS7C31Fo73wFzPolFWwkla09SWGy3QU1rBvK0YwdQmbuJuztp9JhcNLuc0wUdlLZVHC4/E6q/K7oPULNPxC5K1LwW4YuX80Ngl6Oy13Twero864f2DXXTNb"
DB_NAME="encrypted:BGtVHZBbvHmX6J+J+xm+73SnUFpqd2AWOL6/mHe1SCqPgMAXqk8dbLgqmHiZSbw4D6VquaYtF9safGyucClAvGGMzgD7gdnXGB1YGGaPN7nTpJ4vE1nx8hi1bNtNCr5gEm7z+pdLq1IsH4vPSH4O7XBx"

# API Keys
API_KEY="encrypted:BD9paBaun2284WcqdFQZUlDKapPiuE/ruoLY7rINtQPXKWcfqI08vFAlCCmwBoJIvd2Nv3ACiSCA672wsKeJlFJTcRB6IRRJ+fPBuz2kvYlOiec7EzHTT8EVzSDydFun5R5ODfmN"
STRIPE_API_KEY="encrypted:BM6udWmFsPaBzlND0dFBv7R55JiaA+cZnbun8DaVNrEvO+8/k+lsXbZQ0bCPks8kUsdD2qrSp/tii0P8gVJ/gp+pdDuhdcJj91hxJ7nzSFf6h0ofRb38/2WHFhxg77XExxzui1s3w42Z"

# Logging
LOG_LEVEL="encrypted:BKmgv5E7/l1FnSaGWYWBPxxagdgN+KSEaB+va3PePjwEp7CqW6PlysrweZq49YTB5Fbc3UN/akLVn1RZ2AO4PyTVqgYYGBwerjpJiou9R2KluNV3T4j0bhsAkBochg3YpHcw3RX/"

A DOTENV_PUBLIC_KEY (encryption key) and a DOTENV_PRIVATE_KEY (decryption key) are generated using the same public-key cryptography as Bitcoin.

Now, even if you leak your .env file, it's ok. An attacker needs the DOTENV_PRIVATE_KEY to make sense of things. This effectively solves the problem of leaking your .env file ✅.

Bonus: This approach additionally makes it possible for contributors to add config while simultaneously being unable to decrypt config. I anticipate this will be useful for open source projects where you want to allow for contribution of secrets without decryption of prior secrets.

1.0.0 Release

With that, we're pleased to announce the release of dotenvx version 1.0.0 🎉.

It is the next generation of configuration management, and I'm looking forward to what you do with it. The next decade (like the last) is bright for dotenv! 🌟

If you enjoyed this post, please share dotenvx with friends or star it on GitHub to help spread the word.

Community Spotlight: David Cochrum

Dotenv — Mon, 13 Nov 2023 00:00:00 +0000

Meet David Cochrum, the creator of dotenv-vault-laravel. He’s a full stack software engineer that specializes in PHP and JavaScript.

In this spotlight post, I ask him some questions about Laravel, as well as the .env.vault file format.

Question 1: Laravel Ecosystem

Having worked with Laravel for some time, what significant changes have you observed in the framework and its ecosystem? How have these changes influenced your development approach?

Over the years of working with Laravel, I have seen the level of convenience grow while the learning curve shrunk. Obviously, Laravel is quite opinionated in its approach, but those opinions cover the vast majority of use cases and generally make the framework a breeze to work with.

Take create, read, update, and delete (CRUD) operations, for example. So much of web apps are CRUD operations against resource models. Laravel added a great convenience when it introduced resource controllers and route model binding to go with it. So long as you’re following the Laravel conventions, much of the boilerplate work is handled for you. That in turn empowers developers to crank out more functionality without dying of boredom along the way.

I believe the popularity of Laravel has grown largely due to of these opinionated conveniences. As such, there’s a package to add on just about any common functionality these days directly through Packagist and GitHub. Third-party packages also benefit from auto discovery to the point where most can be added just by including the Composer dependency. The integration and configuration of these auto-discovered packages within your app is effortless and often requires no further modification than the installation.

Now, the Computer Science purists will also tell you that some of Laravel’s conventions and conveniences come at the cost of breaking certain programming paradigms and principles. While this is undeniably true, in my humble opinion, Laravel does a pretty decent job of balancing principles with practicality. Sure, Facades are an example of an anti-pattern, but I think, when used responsibly, the benefits can outweigh the penalty of broken rules.

Early on when I first started real app development, the seniors above me decided to base our re-build on Symfony. While this allowed for some low-level convenience, the decision was also made that the Symfony validation package wasn’t good enough for our purposes and instead, each CRUD module would require complex validator classes for each of the forms within. I believe we wasted quite a bit of developer time/resources in re-inventing a pretty decent wheel. Reflecting on that time now, I believe that was a huge mistake. Yes, it was the more principled approach, but I don’t think we gained much, if anything, by writing our own validation instead of leveraging the widely used package.

Question 2: Laravel Benefits

Laravel is known for its elegant syntax and robust features. Can you share an example from your experience where Laravel uniquely benefited a project you worked on, perhaps in ways other PHP frameworks might not have?

In my opinion, Laravel’s most valuable feature is how it allows you to go from nothing to a minimum viable product (MVP) faster than any other framework. Because of its popularity, so many community packages are available to be quickly integrated into your project as well. Say you need to add OAuth to your project, for example. With other frameworks or languages, that typically requires a significant amount of work. Whereas with Laravel, the OAuth package offered, Fortify, does the overwhelming majority of the work for you and requires minimal effort to integrate.

Question 3: Your Experience with Laravel

What drew you to specialize in Laravel, and how has it shaped your journey as a developer? Are there any projects or achievements within the Laravel community that you’re particularly proud of?

I wouldn’t say I necessarily specialize in Laravel, but it is definitely my framework of choice when I’m offered a choice. I’ve worked on projects using Symfony, CodeIgniter v3, Zend v1, and even a homegrown framework that predates all of the others.

Many moons ago I was tasked with extending and maintaining APIs for various mobile apps which were all bundled into a single WordPress XMLRPC plugin. I was given more freedom on one project and I presented the case that I should be given the time to learn and build this next API using a concept I had just heard of: Object Oriented Programming (OOP). I was successful in convincing the stakeholders that allowing me the time to learn and build in this way would be worthwhile. I tried out numerous frameworks, but with the help of Jeffrey Way’s Laracasts, Laravel just seemed to come so naturally and truly helped me learn and adopt programming principles that I hadn’t known before.

Speaking of Laracasts, I would consider that project and community one of the best things to come from Laravel. I’m sure many other developers like myself got their start from working through those videos and tutorials. I certainly wouldn’t be where I am today without Laracasts. Nor would I be as efficient as I am within my IDE.

Question 4: Laraval with .env.vault

What drew you to the .env.vault mechanism? How do you think it will affect the Laravel ecosystem? Is it useful to it? Laravel has its own encryption mechanism for .env files, how is .env.vault different and or more useful in your mind?

I’m currently working on a Zend Framework v1 monolith project that my team and I are attempting to modernize. These apps use Zend’s ini files for configuration which also can be overridden via .env values. I’m working on protecting these secrets and making them more portable while simultaneously starting the process of migrating the apps from Zend to Laravel. During my search for solutions, I came across dotenv.org and its vault for secure secret storage that seemed to fit my needs. I did, however, see an opportunity to author my first Laravel package which simply wrapped the PHP Dotenv library for dead-simple integration with the framework.

I think the vault mechanism can be useful for those who are looking for a storage solution for their secrets which may not be available or is costly with their hosting provider. Additionally, the remote sync feature offered on dotenv.org with the potential for granular access control across user accounts adds a great value that is missing from Laravel’s encryption mechanism.

Thank you David for the thoughts and for your dotenv-vault-laravel contribution to the Laravel community.

PHP dotenv is inconsistent across development and production

Dotenv — Tue, 07 Nov 2023 00:00:00 +0000

I recently added .env.vault support for PHP, and I came across serious inconsistencies across development and production using phpdotenv.

Values can come up blank (yikes!) and load works differently than the other major dotenv libraries.

Luckily, the fix is straightforward.

Use $_SERVER - don’t use $_ENV or getenv
Use safeLoad() - don’t use .load()

Let’s dive in.

Also, let me say that I know how difficult it is to maintain a widely-embedded library like phpdotenv. There are good historical reasons a library might have inconsistencies. Sometimes changing the inconsistencies leads to worse cascading effects.

Setup

Install phpdotenv.

composer require vlucas/phpdotenv

Create a .env file.

HELLO="File"

Then load your .env file in a way that will output Hello File using each available accessor.

$_ENV
$_SERVER
getenv

<?php
// example1.php
require 'vendor/autoload.php';

$dotenv = Dotenv\Dotenv::createImmutable( __DIR__ );
$dotenv->load();

$env_hello = $_ENV['HELLO'];
$server_hello = $_SERVER['HELLO'];
$getenv_hello = getenv('HELLO');

echo "ENV: Hello {$env_hello}";
echo "\n";
echo "SERVER: Hello {$server_hello}";
echo "\n";
echo "getenv: Hello {$getenv_hello}";

Ok, let’s run some scenarios demonstrating the inconsistencies.

Scenarios

Scenario 1 - `getenv` missing value

In the first scenario, the getenv value comes back blank.

<?php
// example1.php
require 'vendor/autoload.php';

$dotenv = Dotenv\Dotenv::createImmutable( __DIR__ );
$dotenv->load();

$env_hello = $_ENV['HELLO'];
$server_hello = $_SERVER['HELLO'];
$getenv_hello = getenv('HELLO');

echo "ENV: Hello {$env_hello}";
echo "\n";
echo "SERVER: Hello {$server_hello}";
echo "\n";
echo "getenv: Hello {$getenv_hello}";

$ php example1.php
ENV: Hello File
SERVER: Hello File
getenv: Hello

getenv returns Hello [blank].

Scenario 2 - `createUnsafeImmutable` not thread-safe

In the second scenario, we remove thread-safety.

Change createImmutable to createUnsafeImmutable in order to populate data to getenv.

<?php
// example2
require 'vendor/autoload.php';

$dotenv = Dotenv\Dotenv::createUnsafeImmutable( __DIR__ );
$dotenv->load();

$env_hello = $_ENV['HELLO'];
$server_hello = $_SERVER['HELLO'];
$getenv_hello = getenv('HELLO');

echo "ENV: Hello {$env_hello}";
echo "\n";
echo "SERVER: Hello {$server_hello}";
echo "\n";
echo "getenv: Hello {$getenv_hello}";

$ php example2.php
ENV: Hello File
SERVER: Hello File
getenv: Hello File

That works. getenv now correctly returns Hello File, but it is not thread safe - super dangerous for any production application!

So, let’s switch it back to createImmutable and try something else.

Scenario 3 - `$_ENV` missing value

In the third scenario, $_ENV comes back blank.

Mimic the behavior of an already set environment variable on the server by pre-setting HELLO=Server.

<?php
// example1.php
require 'vendor/autoload.php';

$dotenv = Dotenv\Dotenv::createImmutable( __DIR__ );
$dotenv->load();

$env_hello = $_ENV['HELLO'];
$server_hello = $_SERVER['HELLO'];
$getenv_hello = getenv('HELLO');

echo "ENV: Hello {$env_hello}";
echo "\n";
echo "SERVER: Hello {$server_hello}";
echo "\n";
echo "getenv: Hello {$getenv_hello}";

$ HELLO="Server" php example1.php
PHP Warning: Undefined array key "HELLO" in /Users/scottmotte/Code/dotenv-org/examples/dotenv-blog/2023-11-07/example1.php on line 8
Warning: Undefined array key "HELLO" in /Users/scottmotte/Code/dotenv-org/examples/dotenv-blog/2023-11-07/example1.php on line 8

ENV: Hello
SERVER: Hello Server
getenv: Hello Server

$_ENV is blank (and we get a warning)! This is inconsistent behavior between development and production.

But $_SERVER is consistent in all three scenarios. Use that going forward. Easy enough.

`load()` vs `safeLoad()`

In the other 3 major dotenv libraries (node, ruby, python), the load method quietly does nothing when a .env file is not present.

This is for good reason. Your .env file is not committed to code. So when you deploy your code to production (or ci) there is no .env file present. The expecation is the server already has your environment variables in memory.

Let’s see what phpdotenv does in this scenario.

Remove your .env file and run the script again.

rm .env

$ php example1.php
PHP Fatal error: Uncaught Dotenv\Exception\InvalidPathException: Unable to read any of the environment file(s) at [../.env]. in /../vendor/vlucas/phpdotenv/src/Store/FileStore.php:68
Stack trace:
...

It issues a stacktrace error, killing your app!

This really surprised me because this is a really dangerous default. It encourages the developer to commit their .env file to code to fix the problem.

Luckily, the fix is easy again. Use safeLoad instead of load.

But in my experience, a developer new to .env files won’t have the experience to correctly reach for safeLoad here. They are too likely to commit their .env file to code and move on with their day. I’ll admit I don’t have the historical context for this decision here, but currently I think this naming pattern should be reversed. load should be become something like loadAndHaltIfMissingEnv, and safeLoad should become load.

Anyways, let’s see the fix.

<?php
// example3
require 'vendor/autoload.php';

$dotenv = Dotenv\Dotenv::createImmutable( __DIR__ );
$dotenv->safeLoad(); // <--- use safeLoad

$env_hello = $_ENV['HELLO'];
$server_hello = $_SERVER['HELLO'];
$getenv_hello = getenv('HELLO');

echo "ENV: Hello {$env_hello}";
echo "\n";
echo "SERVER: Hello {$server_hello}";
echo "\n";
echo "getenv: Hello {$getenv_hello}";

$ php example3.php
ENV: Hello
SERVER: Hello
getenv: Hello

All blank values and no stacktrace, as it should be.

Let’s simulate production again.

$ HELLO="Server" php example3.php
ENV: Hello
SERVER: Hello Server
getenv: Hello Server

$_SERVER correctly returns Hello Server.

Phew 💛🌴, I’m feeling better.

Conclusion

In conclusion, use $_SERVER, and use safeLoad instead of load. Do the same when using phpdotenv-vault with encrypted .env.vault files.

Happy PHPing!

Node.js 20.6.0 includes built-in support for .env files

Dotenv — Sat, 28 Oct 2023 00:00:00 +0000

Node v20.6.0+ adds native support for loading .env files.

node --env-file=.env index.js

Wow, cool!

Is dotenv dead? Stop using it? Not so fast. Don’t drop dotenv just yet. There are some caveats you should know first.

First, let me say, it is great to see the NodeJS team adopt first-class .env support for developers. As one of the pioneers of dotenv, it’s an honor. dotenv is depended on by more than 14 Million open source repos on GitHub alone and downloaded more than 35 Million times per week. dotenv has proven itself as a trusty friend to millions of developers worldwide.

Anyways, let’s see how this built-in support works (or skip to the caveats section).

Find a complete code example on GitHub for this blog post.

How it works

Install Node v20.6.0 or greater using nvm.

nvm install 20.6.0
nvm use 20.6.0
node -v
v20.6.0

Create your .env file.

HELLO="World"

Create your node script to make use of it.

// index.js
console.log(`Hello ${process.env.HELLO}`)

Run it with the --env-file flag.

node --env-file=.env index.js
Hello World

That’s it!

Want to run it in production? Just point it to a .env.production file.

# .env.production
HELLO="production"

node --env-file=.env.production index.js

Caveats

The biggest current caveat is that this is still an experimental feature. That means it will ship with bugs and with missing feature support. The top hn comment sums it up well - albeit a bit grumpily.

I also want stress the word current because this is all still under active development. These things take time. By the time you read this, some of these caveats might no longer be around.

Missing multiline support

The current implementation does not support multiline environment variables. If you attempt to include a multiline environment variable it will be undefined. For example:

# .env.multiline
HELLO="This
is
a
multiline"

// index.js
console.log(`Hello ${process.env.HELLO}`)

node --env-file=.env.multiline index.js
Hello undefined

Note: multiline support is being actively discussed and will probably get added in the near future.

Missing override option

You cannot override your system’s environment variables with your .env file. There is no option.

# .env
HELLO="World"

// index.js
console.log(`Hello ${process.env.HELLO}`)

export HELLO="System"
node --env-file=.env index.js
Hello System

It prints Hello System rather then Hello World. There is no option to overwrite system variables.

If you need to do this then continue using dotenv with its override option.

Missing variable expansion

It’s important to note that variable expansion support has always existed in a separate library dotenv-expand. But it is so widely used with 13 million downloads that it defacto considered part of dotenv.

As of this writing, Node does not support variable expansion. Instead, it will output the variable as a string.

# .env
PASSWORD="password123"
SECRET=$PASSWORD

// index.js
console.log(`The secret is ${process.env.SECRET}`)

node --env-file=.env index.js
The secret is $PASSWORD

So if you need variable expansion, you should continue using dotenv and dotenv-expand.

Missing `.env.vault` support

The .env.vault file is the spiritual successor to the .env file. They have multiple security advantages which you can read about here.

They are quite new but also quite useful for production and ci. They are gaining adoption across multiple languages like python and rust. dotenv supports them but Node’s implementation of .env files does not at this time.

#/-------------------.env.vault---------------------/
#/ cloud-agnostic vaulting standard /
#/ [how it works](https://dotenv.org/env-vault) /
#/--------------------------------------------------/
# development
DOTENV_VAULT_DEVELOPMENT="AtEC33ZfFJQMSE6C+EBX8nzTyQzfC+xhsIfGjyWr47jiHsUi07PHzX2/RmCB0PIi"
# production
DOTENV_VAULT_PRODUCTION="t9van8HefnTIHVlK3vQ6WYLtWEOvPunEnOphV3Hw3aBTBDuwLq22yU0Tdl5fAnk="

Conclusion

In conclusion, built-in support for .env files (even if currently experimental) is a huge and welcome step forward for Node. We should particularly thank Yagiz Nizipli for making this happen. Go sponsor him on GitHub. He is doing incredible work for Node.

That said, there are some caveats, and I would recommend against npm uninstall-ing dotenv for your production apps at this time. Wait until it is non-experimental and has added support for the missing features above.

Using `.env` files?

dotenv-vault is a secrets manager for securely managing them. Create your Dotenv Account and try it today.

https://dotenv.org/signup

What is a .env.vault file

Dotenv — Tue, 24 Oct 2023 00:00:00 +0000

It’s an encrypted copy of your .env files.

It is easiest to understand if you generate one. So let’s do that. Then I’ll show you how to use it in production. Lastly, we’ll talk about its security advantages.

Generating

We’re going to use the command npx dotenv-vault local build.

Prerequisites

Enter a project where you already have .env.* file(s) and have installed dotenv.

For example, I have a project with 3 files in it. See example code.

index.js
.env
.env.production

// index.js
require('dotenv').config()
console.log(`Hello ${process.env.HELLO}`)

# .env
HELLO="development"

# .env.production
HELLO="production"

When I run node index.js I get the expected output Hello development.

$ node index.js
Hello development

Let’s build the .env.vault file.

Generate .env.vault

Run the local build command.

$ npx dotenv-vault local build

You will see a .env.vault file that looks something like this.

#/-------------------.env.vault---------------------/
#/ cloud-agnostic vaulting standard /
#/ [how it works](https://dotenv.org/env-vault) /
#/--------------------------------------------------/
# development
DOTENV_VAULT_DEVELOPMENT="AtEC33ZfFJQMSE6C+EBX8nzTyQzfC+xhsIfGjyWr47jiHsUi07PHzX2/RmCB0PIi"
# production
DOTENV_VAULT_PRODUCTION="t9van8HefnTIHVlK3vQ6WYLtWEOvPunEnOphV3Hw3aBTBDuwLq22yU0Tdl5fAnk="

It contains two keys.

DOTENV_VAULT_DEVELOPMENT
DOTENV_VAULT_PRODUCTION

These contain encrypted copies of:

your .env file
your .env.production file.

A .env.keys file was also generated. These keys decrypt the contents of DOTENV_VAULT_${ENVIRONMENT}.

$ npx dotenv-vault local keys

#/!!!!!!!!!!!!!!!!!!!.env.keys!!!!!!!!!!!!!!!!!!!!!!/
#/ DOTENV_KEYs. DO NOT commit to source control /
#/ [how it works](https://dotenv.org/env-keys) /
#/--------------------------------------------------/
DOTENV_KEY_DEVELOPMENT="dotenv://:key_f4516b0077d9aefad9fa7b36cec570e05dcb7cd6d5de1dac2562b6421af7d185@dotenv.local/vault/.env.vault?environment=development"
DOTENV_KEY_PRODUCTION="dotenv://:key_18a137f844e3511022dbf1de2b1bd5e3bd6d1ef4c78988e2521ce9f05abc506a@dotenv.local/vault/.env.vault?environment=production"

See the pattern? A .env.${ENVIRONMENT} file corresponds to a DOTENV_VAULT_${ENVIRONMENT} secret and DOTENV_KEY_${ENVIRONMENT} decryption key.

Try decrypting the contents of DOTENV_VAULT_PRODUCTION.

$ npx dotenv-vault local decrypt 'dotenv://:key_18a137f844e3511022dbf1de2b1bd5e3bd6d1ef4c78988e2521ce9f05abc506a@dotenv.local/vault/.env.vault?environment=production'
HELLO="production"

Great! It’s decrypting successfully. Next, let’s put this to use in production.

Production

Commit .env.vault to code
Set DOTENV_KEY on server
Deploy your code

At runtime your encrypted secrets will be injected into your code just-in-time.

Try it on your machine with this simple example.

$ DOTENV_KEY='dotenv://:key_18a137f844e3511022dbf1de2b1bd5e3bd6d1ef4c78988e2521ce9f05abc506a@dotenv.local/vault/.env.vault?environment=production' node index.js

[dotenv@16.3.1][INFO] Loading env from encrypted .env.vault
Hello production

As you can see, it loads your env from your encrypted .env.vault file and successfully outputs Hello production. Elegant!

(Other languages are supported too. See dotenv.org/docs)

Security Advantages

Do you remember the CircleCI data breach? An attacker gained access to everyone’s environment variables putting their software products at major risk.

But if you were using .env.vault files, you were not at risk. Why?

The attacker solely gained access to environment variables, not code. He had your DOTENV_KEY but not your .env.vault file. He needed both to access your secrets.

This takes the Twelve-Factor App’s principle of strict separation of config from code to the next level - where even your config is separated.

This leads to some great second order effects.

You are no longer scattering your secrets across multiple third-parties and tools
Your secrets are easier to manage in one central place close to your code which means less chance of fat-fingering or forgetting to set a secret
You add more friction to attackers and remove friction for yourself - no more hard work managing secrets across multiple servers

I’d encourage you to give .env.vault files a try. I think you will like them after the initial adoption hump. They are simple files that don’t require any additional secret manager processes to be kept running.

.env files were simple, useful, and added additional security. .env.vault files maintain that same spirit while adding a much higher level of security. What do you think, let me know at @dotenvorg or @motdotla.

dotenv-vault — A secrets manager for .env and .env.vault files.

If you are looking to also manage your .env and .env.vault files across a larger team, complete with permissions, versions, and history then create a Dotenv Account. It’s free with premium features.

https://dotenv.org/signup

DEV Community: Dotenv

From dotenv to dotenvx: Next Generation Config Management

The problems with dotenv

Run Anywhere

Multiple Environments

Encryption

1.0.0 Release

Community Spotlight: David Cochrum

Question 1: Laravel Ecosystem

Question 2: Laravel Benefits

Question 3: Your Experience with Laravel

Question 4: Laraval with .env.vault

PHP dotenv is inconsistent across development and production

Setup

Scenarios

Scenario 1 - getenv missing value

Scenario 2 - createUnsafeImmutable not thread-safe

Scenario 3 - $_ENV missing value

load() vs safeLoad()

Conclusion

Node.js 20.6.0 includes built-in support for .env files

How it works

Caveats

Missing multiline support

Missing override option

Missing variable expansion

Missing .env.vault support

Conclusion

Using .env files?

What is a .env.vault file

Generating

Prerequisites

Generate .env.vault

Production

Security Advantages

dotenv-vault — A secrets manager for .env and .env.vault files.

The problems with `dotenv`

Scenario 1 - `getenv` missing value

Scenario 2 - `createUnsafeImmutable` not thread-safe

Scenario 3 - `$_ENV` missing value

`load()` vs `safeLoad()`

Missing `.env.vault` support

Using `.env` files?