📄️ Deploying a Django Web Application
You have already learned enough about Django operating system (usually some Linux distribution), web server (Apache, NGINX, IIS, etc.), database, mail server, etc. All these questions are out of the scope of this tutorial. Instead, you will learn how to use a free, managed service for hosting web applications written in Python called PythonAnywhere to deploy Django applications in production.
📄️ About PythonAnywhere
PythonAnywhere is a hosting service for web applications written in Python. After creating an account, you get for free a (sort of) Linux virtual machine with several Python interpreters installed, multiple modules and third-party packages (including Django) and the ability to install new ones using pip, a ready-to-use MySQL database, a fully configured web server, a 512 MB file system and many other interesting things. It is not only an ideal solution for taking a web application to production for the first time, but also for professional projects. PythonAnywhere allows you to select only the resources you want to use and pay accordingly. Moreover, in paid plans you can set up your applications in your own internet domain (.com, .net, etc.)
📄️ Sign up and Setup in PythonAnywhere
To start using PythonAnywhere, visit https
📄️ Setting up a Django Project for Production
We have a default application running at .pythonanywhere.com. Now you will want to deploy your own application, instead of the one automatically generated by the PythonAnywhere wizard, to that domain. Once this is done, anyone having access to that URL will be able to use your Django web application. But befor that, you need to make some small changes to your project configuration.
📄️ Uploading a Django Project to PythonAnywhere
You just configured your project so that it is suitable to run in production. Now you need to upload the entire tree of the myproject directory to PythonAnywhere. Go to the Files menu in the upper right corner of the screen. On the left you will see something like this:
📄️ Serving Static Files in Production
In a previous chapter we introduced the concept of a static file, that is, a file whose content is not generated in real time by Django or any other Python code, unlike, for example, HTML templates, which are processed in each request. By default, when the web browser requests the content of a static file (e.g. /static/myapp/styles.css), Django looks for it in the file system, opens it, reads it, and returns it as the content of an HTTP response. This is fine during development, but in production it is better to let the web server (Apache, NGINX, or whatever it is configured) take care of it, which it will be able to do it faster and more efficiently. It is not only better, but necessary, since Django only serves static files when debug mode is enabled.
📄️ Setting up a MySQL Database for Production
SQLite is a very useful database engine for the development stage, since there is no need to install additional software and it is very well integrated with Python. However, it is not that suitable for production usage. SQLite databases are simply files on the system, and as such have certain limitations: two processes cannot simultaneously write to the same file. Furthermore, in cloud services such as PythonAnywhere, file system access is usually a heavier operation than its equivalent database query.
📄️ Creating a Settings File for Development
The counterpart of the various changes we have made the previous section to make the project suitable for production is that we can no longer run it in development. This shouldn't be a problem, though. Typically, Django projects have multiple settings