A great thing about the popularity of next JS is that deployment guides exist for any cloud provider that you prefer. Of course, you need a next JS application in order to deploy it. We have a simple app that displays a welcome message to the screen. The contents of the application are not important and the process will work for any next JS application that you might have. You can deploy your next year's application from your local machine, but when working as a team, it is best to host it in shared source control and deploy it from there. The most popular option for this by far is GitHub. For this, you will need a GitHub account

and you can get one for free from github.com. Once you have your GitHub account, you can actually publish directly from within Visual Studio Code. Here I'm publishing my source code to a new public repository for your benefit, and once this is complete, we can now proceed to our deployment. The core business model of Versal, which is the company that builds next JS, is cloud hosting. This makes Versal the simplest deployment solution possible, especially when you are in the process of learning. Next js, you can sign up to Versal and join the hobby plan for free, even if you do not plan to use Versal eventually. Since it is free, it is great for experimentation.

Once you are signed up, add a new project, and over here using your GitHub account, you will be able to import the repository that you just created. Versal will automatically detect that this is a next J project, and all that's left to do over here is to click the deploy button. You can monitor the initial deployment of your application and once that completes, congratulations, you have just deployed your next year's application to the public internet. From here, you can go to the dashboard for this particular app, which will also show you the free domain that Purcell has captured for your project. This domain will be inspired by your project name, which for our case is course Dash next year's dash deploy.

If you visit this URL, we can see our application ready for use by anyone on the internet. One great built-in feature offered by the cell, which is worth highlighting is its support for continuous deployment From our dashboard under the deployment tab, we can see that we currently only have one deployment for our application. Let's make a simple modification to our application. We provide a new text for our route page. We commit this modification with the new message over to Git, and once we sync those changes to push them over to GitHub cloud or sell will automatically pick up that new code has arrived and kick off a new deployment. We can monitor and debug the deployment

by going into the deployment page. Over here, we can see that the deployment is still taking place. At this point, we could look at the bid logs if you wanted, and that is helpful in case issues ever arise, but this particular deployment is going to succeed without any issues, and once it is complete, we can revisit our production application and we see the new updated message. In addition to production deployments, modern services also provide preview environments that can help you test your code before releasing it to the public. As an example, let's modify our page and create a new pull request.

We look at the page on GitHub, go into edit, and then modify the message to be something silly like, does this dress make me look fat? When we try to commit these changes, we are presented with a new dialogue over here. We could commit these changes directly to the main branch, Which will deploy to production, but instead we will create a pull request to allow us to collect feedback from our peers and visit a preview deployment of this application to see what it would look like if we were to deploy to production. Once we create the pull request, Orel will automatically pick up that a new pull request has arrived

and we'll kick off a preview deployment. Once this preview deployment has been completed, we can visit the preview URL that was provided as a part of a comment by Versa bot. On this preview URL, we can see our changes as if they were deployed to production, but notice the URL. This is only a preview URL. If you go to our production website, we still see the classic message. At this point, we have a choice. We can either commit these changes, leave comments, make some modifications, and eventually merge this poll request in order to deploy to production, or if we are unhappy

with this entire approach, we can instead choose to close the poll request.