Alright, so in our weber.yaml file, we have configured a single environment named production. But each project in Weber may have as many environments as needs. For example, we can have a production environment, staging environment, sandbox environment, and so on. We may configure each environment separately, in terms of CPU, memory, queues, and everything. So let's go ahead and add a new staging environment to our Weber application. We will go to the terminal and run weber-env-staging. If we refresh the weber.yaml file, we can see that Weber has added the new environment there. We can adjust the memory, CLI memory, runtime, and everything else separately for this environment.

there. We can adjust the memory, CLI memory, runtime, and everything else separately for this environment. To deploy this environment, we may run weber-deploy-staging. However the Weber CLI uses staging as the default environment name if we don't provide any. So we can just run weber-deploy and Weber will deploy our staging environment. I am going to use the power of video editing to speed up the provisioning process. And here we go. The environment was successfully deployed and a unique environment URL was generated. We can use this URL to test things out before we deploy our code to the production environment.

away from the production environment. And once we feel that everything is ready, we can go live. We deploy to production. Now as Laravel developers, we are familiar with environment variables and how helpful it is to have different configuration values based on the environment. So for example, we use environment variables to use a testing API key for some service in the staging environment and a different production key for the production environment. This makes it easy to write code once and run it on several environments without making any changes. By default, Laravel injects several environment variables into any function it creates.

any changes. By default, Weber injects several environment variables into any function it creates. Let's take a look. We'll check any of the Lambda functions we have. Let's say the queue Lambda for the staging environment. Let's click on the configuration tab, scroll down a bit and click on environment variables. We will see a list of variables that were just set by default. For example, we can see an appKey variable set automatically with a unique encryption key for this environment. We can also see that the appUrl variable is set to the environment domain that Weber

key for this environment. We can also see that the app URL variable is set to the environment domain that Weber generated for us. If we scroll down a bit, we can see an asset URL variable that stores the location of our asset files on CloudFront. CloudFront is a content delivery network run by Amazon. Weber uses it to host our asset files so they are served to the users from a location near them, which of course makes downloading these assets much faster. There are multiple other environment variables that Weber configures out of the box. Some of these variables you can override, others you shouldn't really alter them in

There are multiple other environment variables that Weber configures out of the box. Some of these variables you can override, others you shouldn't really alter them in any way as Weber relies on them internally to make your application run or work on the Lambda environment. And to update any of the environment variables from these default values or add new ones, we may use the Weber CLI. So let's go ahead and head over to the terminal and run weber inv pull staging. Weber will download an environment file and store it in the root directory of our application. So here we have a .env.staging file downloaded and let's open it in our editor. And we can see that there are a few environment variables that we can edit.

So here we have a .env staging file downloaded and let's open it in our editor. And we can see that there are a few environment variables that we can edit. These are the most common ones that people usually need to adjust, but you can add any variable you want. So let's edit the APP_DEBUG variable and set it to true. And to apply the changes, we need to run the weber inv push staging command. weber will upload this file and store it in its database. But the variables will not be utilized until the application is deployed again. So let's go ahead and run weber deploy to deploy the staging environment. And after the deployment is done, the new changes will reflect.

And that's how the deployment is done. Also there is one thing you need to know about environment variables in Weber. All environment variables may only be four kilobyte in total. This is an AWS limitation that we have to deal with for many applications. This is not really an issue. But if your application needs to use many environment variables and you start hitting the limit, you can switch to using encrypted environment files instead. This feature is not limited to Weber. It's available to all Laravel users. So let's take a look at it.

It's available to all Laravel users. So let's take a look at it. We'll first create a new file in our project through directory. We will call this file .env.staging. Inside the file, we will add our secret environment variables. Let's go for an API_KEY variable and use the value 1, 2, 3, 4, 5, 6. Now let's head to the terminal and run php artisan env:encrypt --env=staging. This command will encrypt the content of the .env.staging environment file by using a generated encryption key. Laravel will display that encryption key for us.

a generated encryption key. Laravel will display that encryption key for us. It will also show us the name of the encrypted file. So let's go ahead and open it. We can see that the content of the file is encrypted. Now let's delete the .env.staging file. Then run weber env pull staging to pull the weber environment file. Inside the file, we will add a new variable called laravel.env.encryption_key and set its value to the key Laravel generated for us. Then we run weber env push staging to upload the environment variables to weber.

its value to the key Laravel generated for us. Then we run weber env push staging to upload the environment variables to weber. Finally, let's run weber deploy. With this setup, weber is going to upload the encrypted environment file to Lambda and use the encryption key we provided to weber to decrypt the content of this file and populate the environment variables inside each of the functions that belong to this environment. I know it's a little confusing that there are environment variables that are read by weber and added to the Lambda function default environment variables and other environment variables that are encrypted and then decrypted in the runtime environment. I personally recommend that you always use encrypted variables instead of relying on

variables that are encrypted and then decrypted in the runtime environment. I personally recommend that you always use encrypted variables instead of relying on the default Lambda environment variables. And it's because of this annoying 4 kilobyte size limit. We want to avoid it. So let's use encrypted environment variables instead. For that, you just need to set this Laravel env encryption key variable once using the env pull and env push commands and then use Laravel's environment encryption after that. With Laravel's encryption, the encrypted file will be uploaded to Lambda along with the application files and the Weber runtime will decrypt it and populate the environment.

With Laravel's encryption, the encrypted file will be uploaded to Lambda along with the application files and the weber runtime will decrypt it and populate the environment variables. That's how we avoid the default 4 kilobyte limit. I hope that makes it clear.