In the last episode, we started looking at how Valet works under the hood by following an HTTP request and a CLI request the whole way through the app. Now let's take a look at a few more advanced features and how they work. First, let's take a look at valet use, which allows you to define the global version of php that Valet is serving with. If you just run valet use, it's going to tell you what version you're using, but if you pass a version after that, like valet use php 8.2, this will actually go through the process of making sure that 8.2 is installed, and then also converting it to be the primary version that Valet is using for serving your requests, and also the primary version that Homebrew is linking locally.

version that Valet is using for serving your requests, and also the primary version that Homebrew is linking locally. So if we go to cli-app.php, and we look at the use command, we can see we're passing a php version. If you don't pass a php version, like we showed earlier, it will just tell you what version it's using, unless you are in a directory that has a definition in that directory of what version you should use. If you've got a .valetrc or a .valetphprc file that specifies version, then it'll take that as a command that when you run valet use, it should run valet use for that specific version.

that as a command that when you run valay-use, it should run valay-use for that specific version. If you've already isolated php in that particular version, it'll also read that as the version you're trying to run with. If neither of those work, it'll just tell you what it's using. But if either of those do work, then it'll actually switch you to that version. Finally, assuming that we've gotten a version specification from either looking it up in one of these, or because you actually passed it in, we're going to tell phpfpm that's the version we want to use. When we go to use version, we normalize the version that's passed down, we see if it's

version we want to use. When we go to use version, we normalize the version that's passed down, we see if it's what's already running, and if it's not already running, we tell Homebrew, make sure this particular version of PHP is installed. It unlinks the global PHP version if it already has one, and if you don't remember linking, linking is how Homebrew makes sure that there's always a version of PHP that you can run just by running php, instead of having to run php 8.2 or php 8.3, there's always going to be one that's symlinked just as php. So we're going to unlink that symlink, and we're going to take the responsibility ourselves of telling brew, link this new version, so that if we do have 8.0 and 8.1 and 8.2 and

So we're going to unlink that symlink, and we're going to take the responsibility ourselves of telling brew, link this new version, so that if we do have 8.0 and 8.1 and 8.2 and 8.3 all installed, whichever particular one we're asking to set up as our primary right now with this use command, that's going to be the one that's linked. And if you're not using isolation, that alone is enough to make the changes that valet needs. Valet by default assumes you always have one primary linked version of PHP, and unless a particular site is isolated, that's what it's always going to be using. So let's take a look at a few more commands that I think they're really interesting to see how they work. Both secure and isolate have to do with customizing a specific nginx config just for that site.

see how they work. Both secure and isolate have to do with customizing a specific nginx config just for that site. So if you remember from last episode, there's a default nginx config file that all of our sites use. If you make a request to a .test domain, it's just going to hit that one config file, and we already took a look at it earlier. However, if you isolate the php version, you're going to need to send the request to a specific SOC file. Remember, when we went to the config valet directory, there's these different SOC files? Well, if you're going to isolate, our nginx config for that site needs to explicitly say

Remember, when we went to the config valet directory, there's these different .soc files? Well, if you're going to isolate, our nginx config for that site needs to explicitly say don't point to valet.soc, point to one of these. So isolation requires a unique configuration for that particular site. And if you run valet secure, it's the same thing because it needs to point to a specific certificate. So let's take a look right now at what we have for our certificates directory. Do we even have anything secured? We do. Tighten.com.test.

We do. Tighten.com.test. That's actually old. So let's make a new one of our own. So let's secure a flow there. When we run valet secure, everything's running through this site secure method. The first thing it does is just make sure the core directories that we're going to need actually exist. Then it starts building the certificate authority. And if you're not familiar, a certificate authority is the thing that we use to generate

Then it starts building the certificate authority. And if you're not familiar, a certificate authority is the thing that we use to generate new SSL certificates. It makes sure that if we don't already have one, we create a new certificate authority with a certain expiration date. And then given that authority already being there or having just been created, now we create a specific SSL certificate, then puts together an nginx config specifically pointing to that certificate just for this URL, and then it saves that file. So after we run valet secure here, oh, looks like we already had a link here. So it secured poga.test, which was our main link at that point.

So after we run valet secure here, oh, looks like we already had a link here. So it secured poga.test, which was our main link at that point. We go to certificates, oops. We'll now see the four configuration files we need to have an SSL certificate for Poga. When we look over here, we've got nginx. We're also going to have a specific config for Poga that was just generated. And the reason for that is it needs a separate server block here for listening to SSL requests. And that block has to specifically point towards that SSL certificate. All the rest of this config look exactly the same as the main config that all the other sites are using, but we had to modify it to add this additional block and to add these.

All the rest of this config look exactly the same as the main config that all the other sites are using, but we had to modify it to add this additional block and to add these references to the SSL certificate so that it can be secured. Similarly, you can see that we already had isolated some sites in previous episodes. So if we were to example, take a look at the php 8.2 configuration, you'll notice that it's going to look exactly the same, except the sock file is going to be for the 8.2.sock instead of for valet.sock. Everything else is exactly the same. So both these commands, secure and isolate, are generating custom nginx configuration files just for those sites.

So both these commands, secure and isolate, are generating custom nginx configuration files just for those sites. And the moment you unsecure it or unisolate it, it'll just delete this configuration file and allow it to go back to using the normal valet nginx configuration. The only thing that secure is doing that isolate isn't doing is it's also making sure we have a certificate authority and generating a specific certificate for this site. The next command we're going to look at is the valet trust method. If you run valet trust, it'll make it so that when you're doing certain things in valet that require you to type a password, once you run valet trust, you won't have to type the password when it does those things in the future.

that require you to type a password, once you run valet trust, you won't have to type the password when it does those things in the future. It is trusting this valet app to do certain very important actions without actually having you type a pseudo password every single time. If we look at the trust command, it is creating sudoers entries for brew and valet. The sudoers files contain instructions to the system that when you are running this particular command, this is what it should be able to do. And so what we've done is just set one up for homebrew and one up for valet to say when they run don't require you to type a password. And let's look at one last advanced feature, proxying.

they run don't require you to type a password. And let's look at one last advanced feature, proxying. Remember proxying is when we want to say that requests made to a particular .test domain instead of coming into valet should go over to another IP address. Remember that's primarily used for things like instead of having to type 127.0.0.1:7001 for one docker instance and :7002 for another docker instance, you can set them up as frontend.myapp.test and backend.myapp.test. So what we're doing here is basically saying given this particular domain, given this particular host we're forwarding over to, whether or not we're securing it, create this proxy. So it's generating the proxy that we're working with by adding .tld, so .test to the end of

host we're forwarding over to, whether or not we're securing it, create this proxy. So it's generating the proxy that we're working with by adding .tld, so .test to the end of it. It's using our initial stubs, which is either secure.proxy.valet.conf or proxy.valet.conf, securing them or not, and it's just saving them down. If you look at this put method, it literally just creates an nginx configuration file, but all that nginx configuration file is going to say is any request to this should be proxied over to that IP address. So if we were to say valet proxy frontend 127.0.0.1:1234, we can take a look and now we have a frontend.test nginx configuration that listens, that sets up frontend.test,

So if we were to say valet proxy frontend 127.0.0.1:1234, we can take a look and now we have a frontend.test nginx configuration that listens, that sets up frontend.test, and all it does is proxy_pass, which is an nginx specific config, everything through to 127.0.1:1234. So it's a full nginx config, but all it's doing is just proxying those files through. I hope it helps for you to now understand how some of these more advanced valet features work under the hood, because it can help you with using them, with configuring them, and even in troubleshooting them.