Please note, this is a STATIC archive of website developer.mozilla.org from 03 Nov 2016, cach3.com does not collect or store any user information, there is no "phishing" involved.

Django Tutorial Part 11: Deploying a Django website to production

This article needs an editorial review. How you can help.

Draft
This page is not complete.

Contact Hamish Willee via chrisdavidmills if you have any questions about this work.

Now you've created (and tested) an awesome LocalLibrary website, you're going to want to deploy it to production — install it on a public web server. This article provides an overview of how you might go about finding a host to deploy your website, and what you need to do in order to get your site ready for production.

Prerequisites: Complete all previous tutorial topics, including Django Tutorial Part 10: Testing a Django web application.
Objective: To learn where and how you can deploy a Django app to production.

Overview

Once your site is finished (or finished "enough" to start public testing) you're going to need to host it somewhere more public and accessible than your personal development computer.

Up to now you've been working in a development environment, using the Django development web server to share your site to the local browser/network, and running your website with (insecure) development settings that expose debug and other private information. Before you can host a website externally you're first going to have to:

  • Make a few changes to your project settings.
  • Choose an environment for hosting the Django app.
  • Choose an environment for hosting any static files.
  • Set up a production-level infrastructure for serving your website.

This tutorial provides some guidance on your options for choosing a hosting site, provides a brief overview of what you need to do in order to get your Django app ready for production, and works through how to install the LocalLibrary website onto the Heroku cloud hosting service.

What is a production environment?

The production environment is the environment provided by the server computer where you will run your website for external consumption. The environment includes:

  • Computer hardware on which the website runs.
  • Operating system (Linux, Windows, etc.)
  • Programming language runtime and framework libraries used to write your website.
  • Web server used to serve pages and other content (e.g. Nginx, Apache).
  • Application server that passes "dynamic" requests between your Django website and the webserver.
  • Databases on which your website is dependent.
  • Depending on how your production is configured you might also have a reverse proxy, load balancer etc. 

The server computer could be located on your premises and connected to the Internet by a fast link, but it is far more common to use a computer that is hosted "in the cloud". What this actually means is that your code is run on some computer (or possibly a "virtual" computer) in your hosting company's data centre(s), and which provides some guaranteed level of computing (e.g. CPU, RAM, storage memory etc) and Internet connectivity.

This sort of remotely accessible computing/networking hardware is referred to as Infrastructure As A Service (IaaS). Many IaaS hosts provide options to preinstall a particular operating system, onto which you must install the other components of your production environment. Other IaaS providers allow you to select more fully-featured environments, perhaps including a complete Django and web-server setup.

Note: Pre-built environments can make setting up your website very easy because they reduce the configuration, but the available options may limit you to an unfamiliar server (or other components) and may be based on an older version of the OS. Often it is better to install components yourself, so that you get the ones that you want, and when you need to upgrade parts of the system, you have some idea where to start!

Other hosting providers support Django as part of a Platform As A Service (PaaS) offering. In this sort of hosting you don't need to worry about most of your production environment (web server, application server, load balancers) as the host platform takes care of those for you (along with most of what you need to do in order to scale your application). That makes deployment quite easy, because you just need to concentrate on the web application and not all the other server infrastructure.

More experienced developers will often find that they appreciate the increased flexiblity provided by IaaS over PaaS hosting. When you're getting started though, setting up your website on a PaaS system is much easier, and so that is what we'll do in this tutorial.

Tip: If you choose a Python/Django friendly hosting provider they should have instructions on how to set up Django website using different configurations of webserver, application server, reverse proxy etc (or this won't be relevant if you choose a PaaS). For example, there are many step-by-step guides for various configurations in the Digital Ocean Django community docs.

Choosing a hosting provider

There are well over 100 hosting providers that are known to either actively support or work well with Django (you can find a fairly extensive list here: https://djangofriendly.com/hosts/). These provide different types of environments (IaaS, PaaS), and different levels of computing and network resources, with differently constucted price bands. 

Some of the things to consider when choosing a host:

  • How busy your site is likely to be and the cost of data and computing resource is required to meet that demand.
  • The cost of scaling up to a larger computer and the cost of scaling to multiple smaller machines.
  • What support for scaling horizontally (adding more machines) and vertically (upgrading to more powerful machines).
  • Where the supplier has data centres, and hence where access is likely to be fastest.
  • The host's historial uptime and downtime performance.
  • Tools provided for managing the site — are they easy to use and are they secure (e.g. SFTP vs FTP).
  • Inbuilt frameworks for monitoring your server.
  • Known limitations. Some hosts will deliberately block certain services (e.g. email) . Others offer only a certain number of hours of "live time" in some price tiers, or only have volatile storage so you need to host any files outside of where you are serving your website. 
  • Additional benefits. Some providers will offer free domain names and support for SSL certificates which you would otherwise have to pay for.
  • Whether the "free" tier you're relying on expires over time, and whether the cost of migrating to a more expensive tier means you would have been better off using some other service in the first place!

The good news when you're starting out is that there are quite a few sites that provide "evaluation", "developer" or "hobbyist" computing environments for "free". These are always fairly resource constrained/limited environments, and you do need to be aware that they may expire after some introductory period. They are however great for testing low traffic sites in a real environment, and can provide an easy migration to paying for more resources when your site gets busier. Popular choices in this category include Heroku, Python Anywhere, Amazon Web Services, Microsoft Azure, etc.

Many providers also have a "basic" tier that provides more useful levels of computing power and fewer limitations. Digital Ocean, Python Anywhere are examples of popular hosting providers that offer a relatively inexpensive basic computing tier (in the $5 to $10USD per month range).

Note: Remember that price is not the only criteria. If your website is successful, it may turn out that scalability is a more important consideration. 

Getting your website ready to publish

The Django skeleton website created using the django-admin and manage.py tools are configured to make development easier. Many of the Django project settings (specified in settings.py) should be different for production, either for security or performance reasons.

Tip: It is common to have a separate settings.py file for production, and to import sensitive settings from a separate file or an environment variable. This file should then be protected, even if the rest of the source code is available on a public repository.

The critical settings that you must check are:

  • DEBUG. This should be set as False in production (DEBUG = False). This stops the sensitive/confidential debug trace and variable information from being displayed.
  • SECRET_KEY. This is a large random value used for CRSF protection etc. It is important that the key used in production is not in source control or accessible outside the production server. The Django documents suggest that this might best be loaded from an environment variable or read from a serve-only file. 
  • # Read SECRET_KEY from an environment variable
    import os
    SECRET_KEY = os.environ['SECRET_KEY']
    
    #OR
    
    #Read secret key from a file
    with open('/etc/secret_key.txt') as f:
        SECRET_KEY = f.read().strip()

A full checklist of setting you might want to change is provided in Deployment checklist (Django docs). You can also list a number of these using the command below:

python3 manage.py check --deploy

 

Example: Installing LocalLibrary on Heroku

This section provides a practical demonstration of how to install LocalLibrary on the Heroku PaaS cloud.

Why Heroku

 

Heroku Django Resources

Configuring Django apps for Heroku (Heroku docs)

Getting Started on Heroku with Django (Heroku docs)

Django and Static Assets (Heroku docs)

Concurrency and Database Connections in Django (Heroku docs)

Challenge yourself

...

Summary

...

That's the end of the tutorial (for now). We do have other Django overview topics though!

See also

Document Tags and Contributors

 Contributors to this page: hamishwillee
 Last updated by: hamishwillee,