And now that our application is complete, let's take a look at how we might deploy it to production. To do that, we're going to use another tool from the Laravel ecosystem, Laravel Forge. Forge makes it really easy for us to get our applications up and running and online by provisioning servers and managing sites on those servers for us. What it also has more recently is a direct integration with Laravel Reverb. Getting our Reverb-powered applications up and running in production is also very straightforward. Here I have a brand new server provisioned called Reverb. It's fresh and out of the box. I've also pre-configured a domain, reverb.rocks, and configured the DNS to point at the public

It's fresh and out of the box. I've also pre-configured a domain, reverb.rocks, and configured the DNS to point at the public IP address of this server. With those things in place, all that's left to do is to configure our site. We can start over here by typing in our domain name, reverb.rocks. We can leave all the defaults in place and go ahead and click on Add Site. Once our site is installed on the server, we can go ahead and link up with our Git repository. I can go ahead and install my repository directly from GitHub by typing in my namespace, Joe Dixon, and the repository name, which is Git Reel with Laravel Reverb. The branch we're actually going to select here is the latest branch that we worked on,

Dixon, and the repository name, which is Git Reel with Laravel Reverb. The branch we're actually going to select here is the latest branch that we worked on, which was Model Broadcasting. And for database, we're just going to go ahead and select the default database on the server, which is Forge. Yes, we would like to go ahead and install our composer dependencies and run our Laravel migrations. Okay, with our repository installed, our site is now ready to interact with. The first thing I would like to do is jump over into our deployments tab and just check out the deployment script.

The first thing I would like to do is jump over into our deployments tab and just check out the deployment script. This all looks pretty good to me at the moment, but one thing I can see that's missing is to build our front-end dependencies on deploy. So we're just going to type in here npm ci and npm run build. We'll go ahead and update this and we'll trigger a deployment to make sure our front-end dependencies are in place. Okay, so looking at the deployment output, you can see that the branch was already up to date. We installed our npm dependencies, built our application, installed our packages, and there's

to date. We installed our npm dependencies, built our application, installed our packages, and there's nothing to migrate at this stage because the migration was done at the point that we installed the site. So that's all looking good. One thing that's left to do is to seed our database. So I'm going to jump over here into commands, and I'm going to type in here php artisan db:seed, and we're going to force that because we're in production at the moment. So let's go ahead and run that, and all being well, we should see our command is picked up and it's running, and it finished successfully.

So let's go ahead and run that, and all being well, we should see our command is picked up and it's running, and it finished successfully. And if we view the output of the command, you can see that the database was indeed seeded successfully. If I refresh the page now, we should see that our application is up and running. So let's go and see if we can log in. So here we are on the registration page. Let's use the username joe, and we'll type joe@laravel.com, and we'll give a simple password, and let's register. And you can see we are now logged into our Slack application.

password, and let's register. And you can see we are now logged into our Slack application. We have some users seeded here, we have some channels seeded here, and everything looks good to go. However, if I inspect the console here, you'll see that we have some errors that echo is not defined, and this is because we must pass a key when instantiating pusher. So you can see now that we're running into some problems because we don't have reverb installed and running on our server at this point. Let's jump back over into Forge. Okay, so back here on the application panel in Forge, if I scroll down the page a little

Let's jump back over into Forge. Okay, so back here on the application panel in Forge, if I scroll down the page a little bit, you can see some first party Laravel integrations. We can enable our scheduler here. We can enable maintenance mode here. And what's really interesting for us is that we can also enable Reverb. And that's because Forge is able to read our composer dependencies and understand that Reverb is already installed. And because it knows it's part of our application, it can go ahead and configure it for us. The first thing we want to do there is just slide the toggle switch on.

And because it knows it's part of our application, it can go ahead and configure it for us. The first thing we want to do there is just slide the toggle switch on. And you can see that we are given some options. The first one being the host name that we want reverb to be accessible on. Now Forge will go ahead and default this to be a subdomain of the root domain or the apex domain which we supply when setting up our site. So in our case, it's ws.reverb.rocks. And I'm happy with that default, so I can leave that like that. But if I want to change that and make my WebSocket server accessible on a different host name, I'm free to go ahead and change that.

But if I want to change that and make my WebSocket server accessible on a different host name, I'm free to go ahead and change that. The port number here is the internal port number which Forge will run the reverb service on. 8080 is fine in this case. And then Forge is asking us for an indication of the maximum concurrent connections which our server should be able to handle. And this is really for a couple of reasons. Because of the nature of WebSocket, our server is going to hold on to connections for potentially long periods of time.

Because of the nature of WebSocket, our server is going to hold on to connections for potentially long periods of time. And in Unix-based operating systems, each connection is represented as an open file on our server. And there are limits in place on the server as to how many files can be open at any given time. And so when we provide the maximum concurrent connections which we're expecting, Reverb is able to configure our server to increase that number of allowed open files. And it can also determine whether we need to install any additional extensions. But for the purposes of this, I think 1000 is a sensible default.

And it can also determine whether we need to install any additional extensions. But for the purposes of this, I think 1000 is a sensible default. So let's go ahead and start the reverb service. OK, so behind the scenes, Forge has made some configuration changes to the server for us. And if we jump back up a level to the server, and we look at the daemons, we should be able to see that the reverb daemon is running. That's looking good. Let's jump back into our site. OK, if I jump into the .env file and take a look at our environment variables, we should see at the bottom of the file, Forge has injected the relevant environment variables for us.

OK, if I jump into the environment and take a look at our environment variables, we should see at the bottom of the file, Forge has injected the relevant environment variables for us. Now of course, there's one extra step we need to take care of because previously or prior to this step, we didn't have any front end reverb environment variables configured. And that's why we're getting the error in the console. So to make these changes come to effect, we're going to need to go ahead and trigger another deployment. So let's go ahead and deploy now. And we should see that we are now connecting successfully to our WebSocket server. And our subscriptions have been successful.

And we should see that we are now connecting successfully to our WebSocket server. And our subscriptions have been successful. One interesting thing to point out is that we're not actually connecting via secure WebSockets at this time. You can see this ws:// prefix means we're over plain text WebSockets. As indeed, we are for the app itself. Let's go ahead and address that. Back in the site configuration for Forge, I'm going to jump down to SSL and I'm going to use Let's Encrypt. Now Forge will automatically populate the domains which I want to be protected via SSL.

to use Let's Encrypt. Now Forge will automatically populate the domains which I want to be protected via SSL. And it will automatically include the subdomain which we are using for reverb, because it knows reverb needs this host name protected. I'm going to go ahead and obtain a certificate. Great, that certificate has now been installed. And behind the scenes, Forge will have configured the host names for reverb.rocks and ws.reverb.rocks to redirect all traffic to HTTPS. So that's great. But there's one more thing that we need to do.

So that's great. But there's one more thing that we need to do. Because we enabled reverb before SSL was available, reverb went ahead and created or set the environment variables to be accessible to port 80 only. So we can just go ahead and remove these two variables, and we will default to HTTPS and port 443. And we can go ahead and save that. And because we've made those changes, we'll need to rebuild our front end. Okay, I'm back here in the browser. And you can see that I have successfully connected over secure WebSockets.

Okay, I'm back here in the browser. And you can see that I have successfully connected over secure WebSockets. And indeed, our site has been automatically redirected to HTTPS. So let's make sure things are working as we would expect. Let's log in as two different users. Here I am logged in as two different users in two separate browsers side by side. So let's check that in our production environment, our features that we built into our application to interact with Reverb are working as expected. The first thing we can check is our presence indicator. So you can see here on the left, both James and I are online.

The first thing we can check is our presence indicator. So you can see here on the left, both James and I are online. And the same applies in James's window. Let's check our typing indicator. So if I come over here and say hi to James, I send that message, you can see the typing indicator worked and the message was also delivered in real time. And similarly, if James sends a message back, you can see James is typing over here on the left. And as soon as he sends that message, that message is also received in real time. Finally, let's check on what happens if I add a new channel.

And as soon as he sends that message, that message is also received in real time. Finally, let's check on what happens if I add a new channel. So let's take a new channel called Laracosts, hit enter. And you can see again, that this Laracost channel has appeared in both windows in real time. So that's an overview of how you may deploy your Laravel and Reverb application into production. And Forge really takes the legwork out of this for us. It's going to go ahead and configure all of the things required on our server, such as taking a request from the internet, routing that request through Nginx and passing the request on to Reverb, configuring things like the number of open files allowed on the server.

taking a request from the internet, routing that request through Nginx and passing the request on to Reverb, configuring things like the number of open files allowed on the server and installing any additional extensions, which may be required depending on the number of connections which we need to handle.