Okay, let's grab that server from Forge. We'll grab the IP address. We'll add the second server. We'll just call this Forge Server 2. Paste in the IP address we want to connect as Forge, and again, we're going to use Home Forge default as the project path. Now, when you actually set up a real site, probably this is going to be like foo.com or whatever your application is, verblr.com or something like that. All right, but we're going to make Home Forge default our project path. So let's save this server, and again, we're going to get an SSH key, which we need to add in Laravel Forge. As Envoyer, paste in the key, and add that to the server. All right, now, once this is added, we can again test the connection status from Envoyer to make sure that Envoyer is actually able to connect to this server. So let's do that now. All right, we're going to test that.

we can again test the connection status from Envoyer to make sure that Envoyer is actually able to connect to this server. So let's do that now. All right, we're going to test that connection status, and it looks like it was able to connect to that server. So now we have two servers added to this project, both of which are going to receive our code when we deploy. Now, back on Laravel Forge, I've actually already modified the site to point to current public instead of just public, because remember, current public is where the most current release of our application is going to live. All right, so now let's go ahead and deploy this project and see what it looks like to deploy something with multiple servers. All right, I'll manually trigger a deploy, and there it is. Now, when we look at this deployment output, it's actually running each step before it goes on to the next one. So it's going to finish installing

trigger a deploy, and there it is. Now, when we look at this deployment output, it's actually running each step before it goes on to the next one. So it's going to finish installing the Composer dependencies on both servers before it runs the optimized deployment hook. It never lets one server sort of get ahead of the other. It kind of deploys in parallel. All right, so let's let this go ahead and run through. All right, it's running optimize. This will increase the performance of Laravel applications. Once that's done, it should compile our routes, activate the release, and then purge the old releases. All right, so that was pretty straightforward and simple. Let's see what things look like on our server. All right, let's go back. Let's actually go to the server on Laravel Forge and test that. Okay, we actually did deploy the code successfully out to the server. So now our application is running

All right, let's go back. Let's actually go to the server on Laravel Forge and test that. Okay, we actually did deploy the code successfully out to the server. So now our application is running on both servers, and we can put a node balancer in front of these servers if we wanted to, and we can deploy to both with zero downtime. All right, but if we look back at this deployment, I bet you noticed that we actually were only running our deployment hooks on one server, so let's modify that to run the hooks on both of the servers. We'll go back to the project, and in our deployments hooks tab, let's edit that hook. We'll edit Optimize, and you can see we just need to check that we want to run that on Forge server 2 as well and save the hook. And we'll do the same on compileRoutes and save it. All right, so now let's deploy again. We can see our new deployment should come up here any second. There it is. And now if we look at