So let's do a quick review of what Dov files for. The primary goal is to differentiate configuration settings across multiple servers. So if you take a look at your ENV file, any of these settings have one reason to be in here or another. The first reason is this should be different on each server you're working on. The second is, this is something private that we don't want to put in our source control.

The second is, this is something private that we don't want to put in our source control. So for example, the app key is gonna be different on different environments. The URL might be different, the logging might be different. The database connection might be different across different installs. Staging, production, multiple versions of staging, maybe your local development environment, but also some of these are passwords that you don't want

maybe your local development environment, but also some of these are passwords that you don't want to commit to your source control for. VE a variety of reasons. And so you might not want your database passwords in there. So dot e NV files are a space for you to do those two things together in one. So when you first spin up a site in Forge, it's gonna copy your Do nv Do example file, which is committed to code

it's gonna copy your Do nv Do example file, which is committed to code but doesn't have any real data in it, and it's gonna copy it into the Dov file and it's gonna make any changes to it that it knows how. So let's take a look at our Dov example file here. And this is in our Layer cast tutorial. And so you'll notice that it just has local host as A URL. It doesn't know anything about Database connection. You know, this is very generic.

It doesn't know anything about Database connection. You know, this is very generic. And then lets SSHN, we can CD into our latest and we can take a look at the dot e NV file here and we can see that there are some customized properties here that are set specifically for this server. This specific instance of this specific site running this specific server, we got our app key, our app URL.

of this specific site running this specific server, we got our app key, our app URL. We've got our MySQL database instead of SQL Light, we've got our login credentials for that database, password, everything we need to make sure that this site will work correctly in this version. And of course, it's not smart enough to do things like to get your API keys, but at least it gets you up and running as much as it's capable. And one of the benefits about having this ENV manageable

and running as much as it's capable. And one of the benefits about having this ENV manageable by Forge is we can now also if we wanna make changes, log into Forge and change them there directly. We don't actually have to SSH in every single time. We want to modify our environment settings. So you go to your site settings environment and you can actually see your environment settings here and modify them directly before you hit save. You'll notice that there are three options

and modify them directly before you hit save. You'll notice that there are three options down here you might wanna consider. The first is Config cache. The second is Q restart. And the third is encrypted Environment files. So the reason you might wanna run Config Cache after updating these variables is if you run Config cache as a part of your deploy script, then modifications to the ENV file don't actually get pushed forward to your application until you do a deploy.

to the ENV file don't actually get pushed forward to your application until you do a deploy. So you wanna make sure you run config cache again after making these changes if you have a cached config. Also, if you have a Q worker running, it will not pick up any changes to NV unless you run q restart afterwards. So that's why you might wanna click this. Finally, Laravel has a feature called Encrypted Environment Files that allows you to encrypt your environment files

Finally, Laravel has a feature called Encrypted Environment Files that allows you to encrypt your environment files and then actually commit them to source control as something encrypted so people could see that file, but they couldn't do anything with it unless they have the key. But that means every time you deploy, you need to decrypt it. You can take a look at the documentation here to learn a little bit more about it,

You can take a look at the documentation here to learn a little bit more about it, but basically you run PHP Artisan ENV encrypt with a specific key, and then when you wanna decrypt it, you need that key. So Forge allows you to pass that key in to this deploy script. So in your deploy script, you just run this without actually putting the key in plain text in your deploy script.

you just run this without actually putting the key in plain text in your deploy script. And Laravel will pass it in as an environment variable from how you set it here. So if you're dealing with all that now, it makes a lot easier. Here again, for most folks, all you're gonna be doing is making your changes here if you need to, checking one of the two of these Hitting save,

if you need to, checking one of the two of these Hitting save, and then your environment variables are modified without you having SSHN at all.