Most of the work we do in Forge is about managing a single server at a time. But we can also work on configuring our servers to talk to each other and how they interact with the outside internet. First we'll look at private networks or VPCs, which are basically just collections of servers on the same server provider that can talk to each other outside of just through public ports. So to be in the same private network, two servers need

to each other outside of just through public ports. So to be in the same private network, two servers need to be from the same server provider using the same credentials in the same region and owned by the same user account. And once they're on the same private network, they can connect to each other directly via private IP addresses even if they're not exposed to the internet. So when you create a new server, regardless of the server provider, there's an option

So when you create a new server, regardless of the server provider, there's an option here called private network. And on everybody except for Laravel VPS, you'll probably just get the default private network that your server provider offers might be called my private network if you're on Digital Ocean and you can create new ones as you go. And this allows you to say these servers are on the same network, these servers are not in the same network.

And this allows you to say these servers are on the same network, these servers are not in the same network. If you're dealing with Laravel VPS, by default, you're going to see the option being Laravel managed. And this is the default in Laravel VPS. Almost all Laravel VPS apps are just gonna use this. You can choose to create your own network and it'll be a little bit outside of the normal VPS way of working.

and it'll be a little bit outside of the normal VPS way of working. So if you don't know what you're doing there, I would just recommend sticking with this Laravel managed VPC. And each of these, like I said, gives you a private IP address or in the ch in the case of Laravel VPS, it's a private URL that is only accessible to other servers in the same VPC. So that allows you to have your servers talking

that is only accessible to other servers in the same VPC. So that allows you to have your servers talking to each other through connections and ports that are not accessible to the broad internet because this private IP address won't even resolve to servers not in the same VPC. It's a little bit different with Laravel VPS because instead of using an IP address, they're using a URL. This will resolve, but it will be empty. It won't actually get any responses

This will resolve, but it will be empty. It won't actually get any responses unless they're under the same organization. And the way that works within Laravel VPS is all Laravel VPS servers are under the same broad VPC, but that VPC managed by Forge makes sure that only forge servers within your Forge organization can actually talk to each other. So basically treat this like a private IP address. So now let's take a look at how

So basically treat this like a private IP address. So now let's take a look at how to configure the specific network settings on our servers. We're gonna need two servers that are on the same provider. So we're gonna create a new Laravel VPS server and we're gonna keep it under the Laravel managed private network. But this would be the same if we were using something like Digital Ocean as long as they're on the same private network.

Digital Ocean as long as they're on the same private network. Alright, so now that we have two servers on the same VPC, we've got a settings network and we can add a server to our network. So we've gotta add servers to network and we can add the other server to our network. And what this does is it uses a tool called UFW to add some pre-configured firewall rules to our server. So now Oregon Trail staging has been modified

to add some pre-configured firewall rules to our server. So now Oregon Trail staging has been modified to allow our new server with Spring Moon to access a few common ports on it. And those ports are gonna be things like MySQL and Postgres and Redis and memc. And so basically this is just an easy way to have some pre-configured firewall rules on your servers that you don't have to manually set up yourself. Now if you wanna set up your own custom firewall rules,

that you don't have to manually set up yourself. Now if you wanna set up your own custom firewall rules, you can also do that here under Settings Network on the server. You just scroll down a little bit and we see the default firewall rules that forge ships with for every single server. And you can modify those if you want or you can add your own rule, you give it a name, you pick a port or a port range potentially if you want

or you can add your own rule, you give it a name, you pick a port or a port range potentially if you want to customize it just to a specific IP address. And whether this is an allow rule or a deny rule. So you could theoretically set up the exact same rules that we set up in that server network, but you have incredibly more opportunities here to customize it to however you want. Next, let's talk about load balancing. If you're not familiar, load balancing is taking more than

Next, let's talk about load balancing. If you're not familiar, load balancing is taking more than one app server and then putting something in front of them that is responsible for distributing traffic between those servers. So you wanna create two apps in the same provider, in the same region and the same private network. So we're gonna create an additional Laravel VPS server. This one will be Divine Leaf I guess Laravel managed. And we want to set up the same site with the same URL

This one will be Divine Leaf I guess Laravel managed. And we want to set up the same site with the same URL to serve on both of them. So we can create a new site and we'll make this you need a custom domain and our custom main domain can be testing load balancing, do ttn.com and then we're gonna go over to D to Whispering Moon and we're gonna set up that exact same site, exact same settings.

and we're gonna set up that exact same site, exact same settings. And then we're gonna create a new server. But this new server instead of being an app server, is going to be a load balancer server. So we go to load balancer, create server, and we create a new site here as well. There's our domain. We can choose whether or not it supports wild card domains and we can choose the balancing method.

or not it supports wild card domains and we can choose the balancing method. So there's three balancing methods we have access to in Forge Round. Robin gives every single one the same amount least connections, says whichever has the fewest active connections in that moment should get it. So it's sort of like a who has the most uh, ability to serve it right now. And then IP hash says once you have connected,

ability to serve it right now. And then IP hash says once you have connected, you're gonna constantly get that same one. And that allows you to do things like if you've got uh, sessions that need to be held from request request, you can use IP hash for that for now. We'll keep it simple with round robin and then you can choose which servers are going to be backed by this load balancer. So we'll say, well we definitely

by this load balancer. So we'll say, well we definitely want Whispering Moon to do it. Uh, for each of these you can pick the port it's serving under by default, that's 80, but you can customize it if you want. The waiting basically says, uh, for example, if I were to set this one with a weight of two and the other one with a weight of one for every two requests that are passed to Whispering Moon,

and the other one with a weight of one for every two requests that are passed to Whispering Moon, there'd be one request passed to the other one. Backup says this is the primary instance that should be served from if everything else is failing. And pause is something you can change on and off over time. If you want to actually just pause one of these servers and pull out of that pool. So we add the Whispering Moon server, we're gonna add the Divine Leaf server.

So we add the Whispering Moon server, we're gonna add the Divine Leaf server. You know what, let's give it a weight of two and we will create the site. So now we need to go to our DNS provider and add uh, a reference for this domain pointing to the load balancers public ip. Okay, so now we are in DN simple. We're gonna pass testing load balance type co to this public IP address

We're gonna pass testing load balance type co to this public IP address and then hit add record. So in a few minutes that testing load balance do tgt n Do co domain is gonna resolve to this load balancer, which is passing these off with a weight of two to divine leaf and one to whisper moon. But it's not always clear when that's happening. So one things I did was on the homepage of this uh, LAR cast tutorial, I actually have it say this is the server

So one things I did was on the homepage of this uh, LAR cast tutorial, I actually have it say this is the server we're on right now and that's an environment variable. So let's go over to those servers. So we'll go to Whispering Moon and we'll edit the environment variable here. And it's server display name with Spring Moon. And because this is using uh, zero downtime deploy, I think I will have to run config cash again afterwards.

And because this is using uh, zero downtime deploy, I think I will have to run config cash again afterwards. Let's go to Divine Leaf and do the same. And let's test it out. So we see Divine Leaf, we refresh, we see Divine Leaf, we refresh, we see Divine Leaf, we recess, there we go. Whispering Moon. So we now have a load balancer that is sending two requests over to Divine Leaf for every one request over to Whispering Moon. And they are completely distinct app servers

for every one request over to Whispering Moon. And they are completely distinct app servers that are accessible at the same URL. And finally, some of the control we have over networks happens not at the server level but at the site level. And that is password protection and redirects. So first let's take a look at password or also called security rules. So if we go, let's keep it simple and let's just go to Oregon trail production

So if we go, let's keep it simple and let's just go to Oregon trail production and we'll go to our, one of our existing domains we have set up. So if you go to site and then we go to network and add security rule under the security section, you can see that we are just naming what it is, restricted access and we can pick either the whole site or just a specific path under the site and we can set up login credentials,

or just a specific path under the site and we can set up login credentials, which is just a username and password. And so this makes it possible for you to say, for example, this whole site, 'cause it's a staging site or maybe just certain subsections are only accessible using very simple basic HGTP off. That's just a little popup in your browser. It's nothing fancy, nothing related to your Laravel app. And it makes it very easy

It's nothing fancy, nothing related to your Laravel app. And it makes it very easy to password protect either certain subsections of URLs that are not being served by Laravel or temporary password protection. Or maybe you might wanna set this up if you're using a staging site or something. And just so you know, this is not actually saving any of the security information in Forge. You don't have to worry about this being hacked.

of the security information in Forge. You don't have to worry about this being hacked. It is creating HT password files locally on your machine. And then when you look at this later, it just reads those again so it's not actually saving it in forges database. And then finally, we can configure also at the site level redirects. So if you wanna do a redirect, for example, you renamed one of your pages and you don't want to have to build

So if you wanna do a redirect, for example, you renamed one of your pages and you don't want to have to build that page redirect in Laravel. You can just say redirect from, for example, the speaking page to the podcast page. And a temporary redirect requires your browser and any other servers to relook at this redirect every single time. Whereas a permanent redirect once anything has seen a browser server, anything else like that, it caches it

Whereas a permanent redirect once anything has seen a browser server, anything else like that, it caches it and says, I don't even need to check the server again. I know that for the rest of time this speaking URL should forward over to the podcast's URL.