How to Share Environment Variables with Your Team

[00:00 - 00:10] When you work in a team, you need to share your environment variables with them for local testing. The best thing to do is only give them the minimum they need until they need more.

[00:11 - 00:21] That is, you only need to give them the development settings and not production settings. The most secure way to do this typically is in person or on the phone.

[00:22 - 00:38] You can also send the values over a secure message platform, but the best way to share your development environment variables is using a key service like .envault. .envault allows you to control which environments users can access.

[00:39 - 00:58] Update them if things change and take away that access in a secure way. Although you can already set the values for the environment variables through their respective dashboards for each service, there is also a way to automate inserting the values into your test and production environments easily.

[00:59 - 01:11] This eliminates the need for .env flow since you already can switch between the environment settings easily. If you want to change the local values, you can just set the values in your .

[01:12 - 01:31] env file and pull to reset the values. Before I set up my vault, I like to set up my package JSON scripts. I like to add the common commands that I use, and I've added a few extra ones for when we add it to the CI system.

[01:32 - 01:43] We'll go over a lot of these commands, build, new, push, pull, login. But for now, I'll just leave them there before I explain them all.

[01:44 - 01:49] Let's get started and create your vault. To do that, we'll use the vault new command.

[01:50 - 02:08] This will create a new repo on the vault servers, and if you have a .env file prior to running this, it'll use those values to initialize your vault. Let's go run that now. npm run vault new.

[02:09 - 02:18] This creates a .env.vault file as you see, which is a public vault project identifier. This can be committed to Git.

[02:19 - 02:27] The command also tries to send you to the vault website. But if that fails, you can click the link manually.

[02:28 - 02:32] Okay. All right.

[02:33 - 02:42] So we'll just have to login and then step three will be open. Next thing to do is to use vault login.

[02:43 - 02:54] It's a little bit weird because you log into the account after you create your vault. But that's how it works because that's how you get your session token.

[02:55 - 03:03] Let's try that now. npm run vault login.

[03:04 - 03:21] You'll notice this creates a .env.me file, which is a private vault session file with an auth token, so make sure it's Git ignored. For me, the link didn't work again, so I had to menu and click it, but that ended up working.

[03:22 - 03:38] If you don't understand how cookies or auth tokens work, it's a secure identifier that makes sure you don't have to login with your password every time you need to hit the remote server. It's also unique per machine and repo.

[03:39 - 03:49] Next, if you want to make changes to your vault, you need to know push. So push will push your values that you've written in dot end into the vault.

[03:50 - 03:57] Let's do that now. npm run vault push.

[03:58 - 04:13] There's also a vault open command, but I didn't include it in my commands that you need to know because it just opens the vault project page in your browser and it's completely optional. You can still access the project page on the vault website.

[04:14 - 04:32] As you can see, your dot end file holds your secret values, like regular dot end file, and it so works like a regular dot end file within your project. Pulling will update it from remote and pushing will update remote from it.

[04:33 - 04:45] Dot end also, this file refers to the primary environment set. That is, you can have multiple environment sets as you please.

[04:46 - 04:58] However, additional environment sets are not created by default. By default, you have a single primary environment set called development.

[04:59 - 05:08] And if you want more, so in this case, we can have a CI set, we have to push the values to it. So let's do that now.

[05:09 - 05:26] npm run vault push CI. As you see, there's an error. It says mission and file. That's because we don't have an dot end dot CI file.

[05:27 - 05:37] So let's create that and then try again. We'll save an empty file as dot end dot CI.

[05:38 - 05:45] We'll say CI at the top. And then we'll say Mongo DB equals test.

[05:46 - 05:57] Now, let's see what happens when we do that. The next thing that you should know is how to sync your dot end vault your project from a fresh clone.

[05:58 - 06:08] So I'm actually going to delete the dot end CI and dot end files. And we will just go through the process.

[06:09 - 06:15] So the first thing that we have to do is log in. We've already done that. We have our dot me.

[06:16 - 06:31] And then what we do is we do vault pull and pm run vault pull. And it will log in and it will download the dot end file.

[06:32 - 06:48] If you do not have your dot end dot vault file, you can use vault build and pm run vault build. This will create the individual session identifiers.

[06:49 - 07:15] It is run automatically every time that pulls run, but it's a good idea to rebuild the dot end dot vault file, which at any time there's any issues with it. When you want to deploy the environment set to your server or to your CI, you have to download your dot end key.

[07:16 - 07:44] The dot end key is an additional security measure that you can use or that you have to use that helps you access your dot end files from a separate server. So to do that, I'm going to make another command dot end keys and we're going to get it from CI.

[07:45 - 08:08] Next, take the key that was generated in the console and add it in dot end key, paste it in the value section and add it. And now your CI should be able to pull the dot end values from your managed dot end platform.

[08:09 - 08:12] Thank you and see you in the next one.