Valet is often talked about in contrast with Docker-based hosting strategies, but they can actually work together in tandem, primarily using Valet's proxy feature. If your project is running in Docker at the same time something else is running on port 80, for example, Valet, then one of the things you commonly have to do is modify your Docker script to expose the HTTP port not at 80, but something else, often 8080 or 8081. You'll end up getting URLs like localhost:8080 or localhost:8081. So let's say we had a SAIL site here. We had just installed Laravel SAIL, and we wanted it to run at the same time as our Valet site was running, or some other site that was running on port 80. We need to customize this app to run at a different port.

site was running, or some other site that was running on port 80. We need to customize this app to run at a different port. Thankfully, SAIL makes that super easy. If you open up your .env file, you change APP_PORT to be whatever port you want it to run on. So we can just say 8080, and then when we run vendor/bin/sail up, it'll read that port and be accessible there. So let's take a look. localhost:8080, and there's our site. But let's say we had multiple projects in Docker containers, not just one.

Localhost 8080, and there's our site. But let's say we had multiple projects in Docker containers, not just one. Imagine we had a different setup where there's three different domains for our site. You've got www.myproject.com, which is going to be served by localhost 3000, which is a very common port for a front-end PLM. You've got api.myproject.com, which is going to be serving from localhost 8080. Then you've got the admin panel, localhost 8081. You can imagine it can get very tiring to constantly be typing in and actually just remembering the specific numbers. And this is where valet proxy comes in very helpful.

remembering the specific numbers. And this is where valet proxy comes in very helpful. With valet's proxy command, we can route all calls sent to a given domain, for example www.myproject.test, to another URL, for example, http://localhost:3000. To do that, we would run valet proxy and then www.myproject. The next parameter would be where it's forwarding to, http://localhost:8080. And optionally, you could pass a secure flag if you want to get an HTTPS forward. We're not going to deal with that right now. So if we go take a look at www.myproject.test, we should see the exact same results as we

We're not going to deal with that right now. So if we go take a look at www.myproject.test, we should see the exact same results as we were seeing at localhost:8080. So www.myproject.test, and there we go, exact same output. So to handle the rest of our domains, we'd be looking at valet proxy www.myproject, and of course, we set this one up just for our local sale install, but we'd have to do the localhost:3000 instead. And then we do valet proxy api.myproject, and we'd pass that one localhost:8080. And then we say valet proxy admin.myproject, and then we pass it, man, this is hard to type.

And then we say valet proxy admin.myproject, and then we pass it, man, this is hard to type. And we pass it localhost:8081. And at that point, we now have www.myproject.test, api.myproject.test, and admin.myproject.test. Super easy to remember, super easy to type, super easy for them to refer to each other without having to memorize all of those ports. And the interesting thing here is Valet's not even serving these sites. It's being served by Docker. Valet is just using its DNS mask installation to make it easier to access those Docker instances with reasonable domain names.

Valley is just using its DNS mask installation to make it easier to access those Docker instances with reasonable domain names. If you're having trouble with this scenario, the one likely culprit is that you might be having trouble with your sites referring to each other internally within Docker. This basically happens because 127.0.0.1 is used by your computer, it's used by Valet, it's used by Docker. And when they're all trying to reach for the same thing, they get a little bit lost. So the main trick right there would just be to change your loopback and just say, valet loopback and choose a different address other than 127.0.0.1. This is a trick I learned from Mikhail Popovits, who actually wrote the proxy command originally.

loopback and choose a different address other than 127.0.1. This is a trick I learned from Mikhail Popovits, who actually wrote the proxy command originally. He's got a great blog post going into more detail about the feature itself, and also this particular situation that we're talking about. Definitely recommend taking a look. You can check it out on his personal website. So in short, Valley's proxy command makes it super easy to set up custom .test domains for any other website you want. Usually most helpful for Docker, but you might have other uses for it. Either way, enjoy.

Usually most helpful for Docker, but you might have other uses for it. Either way, enjoy.