Django Deployment Essentials
Fundamentals of Deployment
Most modern web technologies follow a similar deployment process. Regardless of whether it is Django, Ruby on Rails or ExpressJS, they all have some things in common.
Servers
A server is simply another computer, somewhere out in the world that is connected to the internet. And the internet is just a bunch of computers talking to each other.
When you deploy your web app, you are running a command to start a process that accepts and handles requests that come via the web.
Back in the old days, companies used to deploy web apps on their own servers. These servers would be managed by a team within the company. Just like your personal computer, if the server were to go off for any reason the web app would no longer be accessible.
In recent years there's been the rise of cloud providers such as AWS, Microsoft Azure, GCP, Digital Ocean and many others. These companies provide a service to host your web app "in the cloud". What this means is that instead of having to buy a server and invest in your own infrastructure, you can pay to have your web app hosted in data centers all over the world. These companies would manage the infrastructure for you, at a cheaper cost and with much more reliability.
Modern Deployment
There have been several new technologies that have improved the way we deploy web apps. Today you can deploy your web app in many different ways, using many different technologies. But ultimately, the end result is the same - we want to have our server running and handling requests from the web.
A common deployment service is to connect your GitHub account to the cloud provider and select the repository of your project. You can then deploy the project with just a few clicks and configure environment variables, build commands and more.
Databases
There are many different types of databases like PostgreSQL, MySQL and MariaDB. The most important part of any deployment is the database. It's important for the database to be secure and setup in such a way that it is accessible only by the web app, or other processes that require access to it.
Allowed origins
Most CSP (Cloud Service Providers) that offer a managed database service have functionality to specify the origins that are allowed to access the database. The origins is a list of IP addresses, internal applications and public web apps that can connect to the database. If you aren't using a managed database you will have to configure those settings yourself - and it's not an easy task.
Deploying on a separate server
When deploying a database it's typically recommended to deploy it on a separate server to that of the web application. There are advantages and disadvantages which you can read about in this community post. The most important advantage is that it is more secure because the database is isolated. A disadvantage is that it can lead to latency issues. If you're deploying your web app in California and your database in Frankfurt you will definitely experience bad latency so make sure you deploy your web app and database in the same datacenter.
Static and Media Files
Most, if not all web apps rely on CSS, JavaScript and Images. These files are known as static files. Media files are files that are uploaded from users that use the web application.
These files need to be hosted somewhere for the web app to access them. There are a couple of ways to host static and media files.
Hosting within the web app
A very simple way is to host the static files from within the actual web application. For example, if you go to mywebapp.com/media/ in your web app then you'd access your media files. If you went to mywebapp.com/static/ then you'd access your static files.
This is a very quick way to host your files. However, it will require more configuration to control things like preventing access to private files. You'd also need to look at solutions to compress the files so that you can load them faster.
Object Storage
Object storage is a data storage architecture that manages data as objects. You can read more about this on wikipedia. Regardless of how complicated it may sound, it is relatively easy to set up thanks to cloud providers like AWS and Digital Ocean.
AWS provides a service called S3 that you can connect to your web app so that static and media files are uploaded to a "bucket". The files are hosted in the bucket and to access them you could go to s3.mybucket.com/static and s3.mybucket.com/media for example.
The benefit of hosting like this is that, just like with a database, you can configure the allowed origins and each files' accessibility as publicly available or private. You can also use services to make your bucket a CDN so that the files are cached and load faster.
That being said if you are considering object storage, I'd recommend going with Digital Ocean Spaces. It's more user friendly and was easy to set up a CDN as well.
Use this link to get $100 of free credit.
Deployment architecture
Thus far we've looked at the actual server deployment, the database and the static files. This diagram represents the setup of what a typical web application architecture would look like:
Web app deployment architecture
Here we have a Django app deployed on domain.com. The database is deployed separately using a managed database service. For example, we could deploy it on Digital Ocean and configure it so that only domain.com can connect to it. We then have static and media files being hosted using Digital Ocean Spaces and a CDN set up so that those files are accessible on assets.domain.com.
That is the typical setup of web application in production. This is not unique to Django - most web apps follow a structure similar to this.
Deploying Django
There are a lot of companies providing hosting services. You can find a list of options on Will's blog.
Tutorials
For beginners, I recommend using Digital Ocean or Render, as they're just easier to use and cheaper.
Digital Ocean
Render