So when we first set up a site, forge deploys it for us. And it's pretty easy to assume from the user interface that we can know that it's pulling the code down from Git and then it's at least installing the composer dependencies because that's actually what it said it was doing. But what else is it doing? How do we customize it? How do we trigger it happening? That's what we're gonna cover in this video. So for starters, before we go into the default forge way of deploying, which is zero downtime deploys, I want us

So for starters, before we go into the default forge way of deploying, which is zero downtime deploys, I want us to take a look at the old default, which is a non-zero downtime deploy. I just wanna give you a quick note that if you decide to do this like I did, what you're gonna do is you're gonna create a new site, you're gonna go to the advanced settings, and then you're gonna disable zero downtime deploy and you make it an error doing that. That will happen because you created the server

and you make it an error doing that. That will happen because you created the server before you connected your GitHub um account. And that means the SSH key for the server wasn't automatically added to your GitHub account. So you can just go to the server settings, grab that server SH key, and then put it in your GitHub trusted SSH keys and then try it again.

and then put it in your GitHub trusted SSH keys and then try it again. It'll work fine. So once you have that running, you go to settings, deployments, and this is where we define the script that is going to be used for our deploy. So basically what happens in the classic way of doing it is you change the directory to the directory for that site. You pull down the code from Git when the specific branch you

to the directory for that site. You pull down the code from Git when the specific branch you run composer install, and then there's this FPM lock thing. And what this does is basically make sure that we don't have a situation where multiple different services are trying to restart F PHP FPM on the server. At the same time, let's say you have deploys from four different sites all overlapping with each other, you don't want to constantly be sending

different sites all overlapping with each other, you don't want to constantly be sending that reset restart signal. So this keeps that from happening. Then we do N-P-M-C-I-N-P-M run build and if the Artisan file exists, which it should because this is a layer about application, then we run a couple artisan commands. And these commands aren't exactly the same as those that are there for the zero downtime deploy,

And these commands aren't exactly the same as those that are there for the zero downtime deploy, but I think that's just a coincidence right now and they'll probably get them synchronized at some point. So that's what the default deploy script looks like. So anytime a deploy is triggered on the site, it's going to be running this script for us. Now we can look at the same script for a zero down time deploy site and notice it doesn't look quite the same.

for a zero down time deploy site and notice it doesn't look quite the same. We're not gonna go into crazy amount of detail on this because there is a video later covering the entirety of how zero down time Deploy works and how it works on Forge. But you can at least see here that we have this function to create the release and another function to activate the release. And in between them we take the same steps that we were taking in the other deploy script composer

And in between them we take the same steps that we were taking in the other deploy script composer install, N-P-M-C-I-N-P-M run Build. And in this one it doesn't check if Artisan exists and it adds this storage link. But again, I think those are just coincidental. Consider them basically the same script. And if you're like me and if you're like Tighten at some point you'll have a customized version of the script

and if you're like Tighten at some point you'll have a customized version of the script that does it exactly the way you want that you're gonna paste into every new site that you're working on Anyway. So this is what it looks like when you're working with the zero downtime deploy script and with either, you will notice that you have these variables here, these for specific variables.

that you have these variables here, these for specific variables. And if you go to the documentation you can see a list of all the different variables you can use in your deploy script. But you can also use your own environment variables. So if you check this right here, you have access to all the variables in your Dov file. So you could do something like, you know, echo app local into local text, or you can, you know, run a PHP script

So you could do something like, you know, echo app local into local text, or you can, you know, run a PHP script and pass when your environment availables into it, whatever you need. So now let's talk about when these get deployed. 'cause we said this is what happens when a deploy is triggered, but when is the deploy triggered? Well, there's three main times that can happen. The first is when somebody clicks the deploy button. It lives up here on most of the pages.

The first is when somebody clicks the deploy button. It lives up here on most of the pages. And then on the overview page, it lives over here. If you click this, it just automatically triggers a deploy. And one of the variables you have access to is actually whether or not this is manually deployed. And so you can actually do some conditional work based on whether somebody clicked this button or it was triggered automatically. You also have the ability in your settings to choose a push

or it was triggered automatically. You also have the ability in your settings to choose a push to deploy setup, which is the most common by far way of setting up deploys with your Lable applications on Forge. What happens here is whatever your branch is on your source control provider, for example, main branch on GitHub, whenever that branch has a new commit, your source control provider pushes a web hook to Forge. And Forge uses that to say, oh, it's time for a new release. So this is push to deploy,

And Forge uses that to say, oh, it's time for a new release. So this is push to deploy, push new code automatically expected to deploy. The other option is you get a specific deploy hook for every single site that you have. If you send a get or post request to this URL, it'll automatically trigger a deploy. There's one other thing I wanna show you, which is GitHub deployments. So if you use this tool,

which is GitHub deployments. So if you use this tool, basically every single time you do a new Deploy on this branch, it'll push it up to GitHub and GitHub will record it as a deployment, which is something that shows up in the user interface in a few places, primarily in pull requests to say, Hey, when you were working on this, we push to deploy. Oh, you're working on it more. We push to deploy again. Finally, I wanna show you commands

Oh, you're working on it more. We push to deploy again. Finally, I wanna show you commands and commands are not exactly the same as deployments, but similarly they're ways where you are choosing in the web interface to run a command on the server. And obviously Laravel VPS has its own terminal, uh, but this works across all of our sites. If we go to commands, you can run a command that's got all these very common commands

If we go to commands, you can run a command that's got all these very common commands that you'll probably wanna run that are PHP and Artisan specific, but you can really run anything you want. Here you can see Ls al dash al, and you're gonna get the output of that run from the root server of the current release of your application. So that's it.

of the current release of your application. So that's it.