There are particular settings in our current Django project that we will need to change. In general, our current settings allow a significant amount of data to be leaked across various components of our project. This is because, while being developed locally, we can afford to have these settings the way they are so that the debugging and testing processes will be easier and more intuitive.

In production, potential attackers and malicious users might be able to take advantage of those data leaks. Furthermore, since no debugging or testing will be done in production, those settings need to be modified accordingly.

These settings are generally called the Django deployment checklist, which needs to be completed regardless of which hosting service you're using. They include the following:

• Hiding keys and passwords: It is no surprise that we shouldn't hardcode various keys and passwords for our project within the actual project code. This includes the secret key of our whole project (in mysite/settings.py), as well as any passwords and secret credentials that are used by any of our applications (such as the email address and password for our SMTP emailing server).
  One of the easiest ways to address this problem is to hide these keys and passwords in environment variables that are specific to the hosting platform or text file.
• Disabling debugging: Simply change the value of the DEBUG variable in mysite/settings.py to False.
• Listing valid hosts: Use the ALLOWED_HOSTS list variable to include the domain of the sites that will serve your web applications. Any site not listed in this variable will be rejected by Django if it attempts to access the project code.
• Implementing logging: As you push your fully functioning website to production, there is still a chance that it will encounter some error in the future. Make sure to configure your logging settings so that you can obtain the appropriate information after potential crashes.
• Making views for errors: We saw an example of a site displaying various pieces of information when an error was encountered in our earlier discussions. This is undesirable in production as that output might include important information that will make our website vulnerable to attacks. Instead, we would like to simply create an appropriate view for each of the potential errors that might occur.

To do this, simply create the following files in our templates folders: 404.html, 500.html, 403.html, and 400.html. Then, put in any error message that you'd like. Django will automatically know to use these templates accordingly should an error occur.

The aforementioned points apply for most Django web applications, but your project might have other particularities that need to be addressed. Refer to the official documentation from Django to learn more: https://docs.djangoproject.com/en/2.2/howto/deployment/checklist/.

Most of the time, the process of deploying your Django project into the cloud, including these Django-related settings, will be very specific to the hosting service you are using. However, most services have extensive documentation and guides that will walk you through the whole process.

This concludes our discussion on building an example web application using Django and PyCharm. Moving forward, you can choose to either create new Django projects while referencing what we have learned here or simply use the blog application that we built, extend it further, and add more applications to the project itself.