Let's dig into how you would deploy your functions as a part of your regular build pipeline. Before we do that, we need to look in detail at the difference between deploying and activating your functions. We're going to use the Hello World to do this example. I'm going to switch it back to JavaScript and change this back to Node. Let's go to index.js and we're just going to return 1. If we deploy and activate this, we're going to see 1 come back in the browser. We come over here, we hit serverless.whip, we see the number 1. If we refresh our console, we see this is the most recent function, serverless local Hello World.

If we refresh our console, we see this is the most recent function, serverless local Hello World. Let's scroll down here and look at versions. You see that each time we deploy something new, a new version gets created. This most recent one has an alias called active, and that's what tells Sidecar which version to hit. Every version of a Lambda function is independent. Sidecar updates the alias whenever you tell it to activate. Let's see how this works. Back in our index.js, let's change this to 2.

Let's see how this works. Back in our index.js, let's change this to 2. We're going to deploy again, but this time we will not activate. If we hit it in the browser, we should see we do. We still see the number 1, not the number 2. Come back here and refresh the page. You'll see why exactly that is. We didn't update the alias to the new version. If we look at the new version, we can actually inspect the code, and the code says return 2.

If we look at the new version, we can actually inspect the code, and the code says return 2. So we know that the new version is out there, but if we look at the version that's actually aliased to active, that's the one we deployed a second ago with the code of return 1. Going back down to the version listing, let's call activate on its own, refresh, and now you see the alias active is applied to version number 4. The way that this helps us in deploying is there may be a long time between when you build your functions and when your new Laravel app is finally ready to start receiving inbound requests. We don't want our serverless functions to be ready a minute or two or three before our

requests. We don't want our serverless functions to be ready a minute or two or three before our Laravel app is ready, because then we're running different versions and bad things could happen. If we look at Laravel Envoyer, I have a fake project set up here. You don't have to use Envoyer, but this is really great because you have kind of a build step and then an activate step. So we're going to add a hook called publish, let's call this deploy sidecar functions. It's fine to run it as forge, php artisan sidecar deploy. So we'll put the deploy in one step, save that hook, then we'll add a new step and we'll say activate sidecar functions.

So we'll put the deploy in one step, save that hook, then we'll add a new step and we'll say activate sidecar functions. We'll say php sidecar activate and save that step. We're going to move deploy before activate and we're going to move activate after activate. So now the way that it's going to run is all your php dependencies will be installed, your sidecar functions will be deployed, but they won't be active until after your Laravel app is active. So your Laravel app will be activated and then immediately after your sidecar functions will be activated. You can do the same thing if you're deploying with Vapor because Vapor gives you a build.

will be activated. You can do the same thing if you're deploying with Vapor because Vapor gives you a build step and it gives you a deploy step. So in your build step you would say php artisan sidecar deploy. And in your deploy step you'd say artisan sidecar activate. Because the Vapor builds run on your machine or GitHub Actions or somewhere else besides actually on Vapor, you'll probably want to put env=production if you're deploying to production. This ensures that the sidecar functions get named correctly and don't pick up the name of maybe the CI server or your local machine.