Oftentimes, your functions might need environment variables of their own. We have all of our environment variables for Laravel in our .env, and your serverless function might need the same kind of deal. You can control environment variables using the variables method. Let's take a look at the parent class and see what's in there. By default, it returns false, meaning Sidecar won't do a thing with the environment variables. But it looks like you can return an array, a key value array of environment variables. Let's do that to see how it works. We're going to set a foo variable, and we will set it to bar, obviously. And in our handler, let's go ahead and instead of returning to, we'll do process.env.foo.

We're going to set a foo variable, and we will set it to bar, obviously. And in our handler, let's go ahead and instead of returning to, we'll do process.env.foo. This is just how you get an environment variable out of a node runtime. Let's deploy and activate. You'll see something maybe new down here, updating environment variables, publishing new version with new environment variables. Historically, we haven't seen this, but now that we're letting Sidecar manage the environment, we do see this. Back in the browser, we should see bar. So we are seeing bar in the browser, which means our environment variable was set.

Back in the browser, we should see bar. So we are seeing bar in the browser, which means our environment variable was set. We can confirm that by looking at, this is our lambda function, local hello world. Let's hit refresh on this. We see that foo has been set to a value of bar. This is in the environment variables section. Sidecar also adds its own checksum, and that is so it can skip updating if it's not necessary. If you haven't changed any of the environment variables, then it's not really necessary to update. We can see that by running again, deploy --activate, and you'll see down here, environment.

to update. We can see that by running again, deploy --activate, and you'll see down here, environment variables unchanged. So if the environment variables don't change, Sidecar is going to notice that and skip over it, which will make the activation step a lot faster. You might have noticed that the environment variables are set as a part of the activation step, not as a part of the deployment step. We can prove that out even further by changing this to version and changing this to 1, and then in our index, we'll say .version. Let's deploy again, but not activate this time.

and then in our index, we'll say version. Let's deploy again, but not activate this time. Running in our console again, we see the newest version, which is seven, that was deployed six seconds ago. We see that that's been deployed, but if we check our configuration, we still see that foo is equal to bar, and if we click into this version, we still see that foo is equal to bar. Our new environment variable hasn't been set. In fact, the old one has been carried over from version six to version seven. Let's run activate and see what changes.

In fact, the old one has been carried over from version six to version seven. Let's run activate and see what changes. So it says, updating environment variables, publishing a new version with new environment variables, activating version eight. If we go back, we should see a version eight. Version eight is active, and if we click into version eight, we see that version is set to one, and the reason that that is so important is because deploy may be called on an entirely separate machine than activate. Remember, if you're using Laravel Vapor, you might have a vapor.yaml that looks like this, where you have one step that builds everything, that runs either in GitHub Actions, in your

Remember, if you're using Laravel Vapor, you might have a vapor.yml that looks like this, where you have one step that builds everything, that runs either in GitHub Actions, in your CI server, wherever. You have a separate step that runs inside of Vapor that actually activates your functions. Because your environment variables aren't probably going to be hard-coded like this, it's probably going to be something like app.whatever. It really matters where this is run, because if this is run locally, it's going to pull the .env off of your local machine. But if this is run in production, it's going to pull the .env off of production. So Sidecar doesn't set environment variables until the activation step for this very reason,

But if this is run in production, it's going to pull the .env off of production. So Sidecar doesn't set environment variables until the activation step for this very reason, because this step runs inside the container that has all of your production environment variables, where this step likely runs in a build server that doesn't have your production.env.