So if we're going to cover how zero downtime deploys work, I first wanna cover once again how traditional deploys work. So I have two versions of the site on the server. There's the downtime or traditional version, and then there's the zero downtime version. Before we dive into them, just a quick reminder, if you don't remember the way to create each of those as when you're creating a new site, you can either not change the setting, which gives you zero downtime, or you can go to advanced settings

not change the setting, which gives you zero downtime, or you can go to advanced settings and you can disable zero downtime deployments, which gives you the non-zero downtime version. So if we look at the downtime version inside here, we just have our Laravel application just as we would clone it on any other server or any other site. And you can see GI status, you can do GI poll, and this is basically just our application at it exists. There's no special magic going on here other than maybe

and this is basically just our application at it exists. There's no special magic going on here other than maybe that Laravel will run some of these deploy steps for us and manage our dot env file for us. Outside of that, this is just a normal site, but you may have run into the downside of the normal site before, which is that our deploy script usually involves composer install, N-P-M-C-I-N-P-M run, build PHP is and migrate. Those things can take time, but if you pull down code

build PHP is and migrate. Those things can take time, but if you pull down code and you haven't migrated, or if you pull down code and you haven't run composer install yet, or just the entire process of running NPM Run Build your site can be broken during that time and that time could be several seconds and it might not be acceptable for your business to have the site go down for potentially several seconds. Every time you run a deploy, enter zero downtime deploy.

to have the site go down for potentially several seconds. Every time you run a deploy, enter zero downtime deploy. So let's go look at the zero downtime version of the site. So lar cast tutorial on forge.com. So it looks a little different. We're not seeing our Laravel application here. What's really important here is two directories releases and current. And current is a sim link, so it's not technically a directory,

And current is a sim link, so it's not technically a directory, but it is a sim link to a directory, which is one of our releases. So it's basically a directory. So what happens is every single time we make a new release of our site, we create a folder for it in the releases directory. And the latest one is always symlinked to current. So where our engine X configuration on the traditional site

And the latest one is always symlinked to current. So where our engine X configuration on the traditional site is looking for slash home slash forge slash your project slash public slash index PHP. And that's what it's actually serving for those traditional sites. If you're doing that for one of these, it's the same thing. Home Forge your project slash current slash index PHP, oops PHP.

slash current slash index PHP, oops PHP. And so it's basically putting everything not in the root folder, like the traditional deploy, but instead in individual folders that each represent a release and then different folders are activated by becoming the one that is sim linked to this current directory. So basically the cool part about that is if we go into releases,

So basically the cool part about that is if we go into releases, we'll see all those releases are there and it'll delete releases after a certain number, maybe after 10 or something like that. But if you go into a release, you can actually see your full application in here, just like you saw it in the root. And the thing that's interesting about this first of all, is the idea that you have multiple instances

And the thing that's interesting about this first of all, is the idea that you have multiple instances of your application running side by side, which is kind of fascinating. They're just sitting there waiting to be used. Um, but also there's some files that you want to exist in between your deploys. This would be the NV file, this would be auth Jason. This would be your storage directory. And so you can actually see that those files are SIM links.

This would be your storage directory. And so you can actually see that those files are SIM links. So those are not actually files that exist in this release. Those files exist in here and you can see auth Jason here, you can see do NV here. And you can see the storage directory here in the root of our application. So every time a new release is created, we do clone that content down from your Git provider, but then also those files are sim linked in.

that content down from your Git provider, but then also those files are sim linked in. So the release actually has a slinked copy of TJA sim linked copy of dot edv, a sim link copy of your storage directory. So let's take a look at how this looks in Forge. So in Forge you can see we have our two sites. We can take a look at the downtime version and if we look at our deployments, it is the traditional forge deployment setup.

and if we look at our deployments, it is the traditional forge deployment setup. We CD into the directory, we pull the latest code down from GI and then we run our install steps and perfectly fine. But again, this may give us some downtime. Now if we go over to the zero downtime version, it's a little bit different. It's actually simpler and easier to understand. We create a new release, we CD into the release directory.

It's actually simpler and easier to understand. We create a new release, we CD into the release directory. We take all our install steps and then we activate that release. And creating release is what I just said, which is you go into the releases directory and create a new folder that is the copy of your application at this particular commit and gi and then you CD into that. It's going to sim link those important files down

and then you CD into that. It's going to sim link those important files down to the root and then it's gonna run your whole install process. But because it's not activated at this point, this is not actually being on the internet anywhere. This is just sitting in a folder somewhere while we act on it. And it will not actually be put on the internet until we activate the release.

And it will not actually be put on the internet until we activate the release. And activating the release is basically updating the sim link to this new release folder and then deleting any old releases that are beyond the release retention schedule. And that's it. So we basically have, uh, the ability to have a version of our application that switches over in, you know, milliseconds without any concerns around race conditions about when certain pieces

you know, milliseconds without any concerns around race conditions about when certain pieces of our deploy happens, or just the amount of time things are broken between pulling down the latest code and artisan migrating and composer installing and everything else. So to see it in action, let's take a real quick look at what it would look like for us to do another deploy on the site. We'll go over to the server

to do another deploy on the site. We'll go over to the server where the releases directory. And remember this current sim link is pointing to 1 0 2 right now. So current is pointing to 1 0 2 and we go to releases directory. We've got, oops, we've got the original and then 1 0 1 and 1 0 2. So let's trigger another deploy.

and then 1 0 1 and 1 0 2. So let's trigger another deploy. We can watch it in real time. We'll see another one show up here pretty shortly. That's deploying. Alright, creating new release. So we should have another one now. Yep. 1 0 3. And it's actually doing all those steps there. So it's, uh, cloning it down to a new folder. I, I can't keep it up there, but it's cloning down a new folder.

I, I can't keep it up there, but it's cloning down a new folder. It's doing the sim linking, it's doing composer install. And then finally we see activating release, purging releases and deployment complete. So these are what happens in that second function. It activates the new release with the new sim link and then it purges old releases. So if we take a look here, this current now points to 1 0 3 and that's it.

So if we take a look here, this current now points to 1 0 3 and that's it. It's live, it's ready to go. And if you for some reason realize there's something wrong with 1 0 3, you could go in and manually change the sim link to point to 1 0 2. And I think this is a really great entry level, zero downtime deploy that will work for a large majority of sites. But if you do need a more customized zero downtime deploy

for a large majority of sites. But if you do need a more customized zero downtime deploy experience, Laravel s Envoy is built around doing that in a much more complex way. So drag and drop builders for all the steps that are gonna happen. Uh, you can do your zero downtime employees across multiple servers. It's a little bit more equipped for multiple users to have different permissions and everything like that.

It's a little bit more equipped for multiple users to have different permissions and everything like that. So if you're looking for a more complicated version of this, definitely check out Envoyer. But I think this is a really solid start for us and a lot of sites will be happy just with this.