Introduction to Django for Beginners
■Episode 4: Django Settings and Structure for Production Environment
(Last updated: 2023.04.11)
Image of Django framework
This article takes 6 minutes to read!
(Rotate your smartphone for a larger image)
"Where do I change the settings?"
When using Django, knowing how to work with the settings file is just as important as understanding the basic operations. Django settings are written in the `settings.py` file. This article explains how to configure `settings.py` and Django's overall structure for a production environment.
[Table of Contents]
Django Settings for Production (settings.py)
Django Structure in Production Environment
1. Django Settings for Production (settings.py)
The settings file (`settings.py`) is located in the project directory with the same name. When you open this file, you will see several configuration options. One of the first items to change is `DEBUG`. By default, it is set to `True`. While this is fine for development, leaving it enabled in production can expose unnecessary information to users during an error. Always set `DEBUG = False` when deploying to production.
The `ALLOWED_HOSTS` setting defines the domains that are allowed to access your site. Use `localhost` for test environments and your actual domain in production. Below that is the list of installed applications. Whenever you create a new app or add a third-party app like Django REST Framework, be sure to add it here.
`Middleware` is a list of processes that run during request/response handling. It's best not to touch this when you're just starting out. As you become more experienced, you might create your own middleware, but for now, just know it exists. `ROOT_URLCONF` usually doesn’t need to be changed. It tells Django where to look for `urls.py` to handle routing.
`TEMPLATES` is a commonly edited setting. By default, templates are stored in each app's `templates` folder. If you'd prefer to keep all templates in one central place, you can create a `templates` directory directly under `BASE_DIR` and set it in the `DIRS` section.
Sample `settings.py` content (debug mode, template directory setup, etc.)
Further down in the file, you'll find the database settings. By default, Django uses SQLite, but you can change it to use MySQL (MariaDB) or PostgreSQL, which are commonly used in production. In the example below, the MySQL configuration includes username, password, port, and other details for connecting.
Then there's the language and time zone settings. If you're in Japan, change the language from `en-us` to `ja` and the time zone from `UTC` to `Asia/Tokyo`.
Next is the `static` directory setting, which defines where static files like images, CSS, and JavaScript are stored. Like templates, it is common to place the `static` folder under `BASE_DIR`.
Other settings include trailing slashes for URLs and user authentication (login), which we’ll briefly mention here. Finally, there's the email configuration used to send messages during signup or contact form submissions. In development, you can set `EMAIL_BACKEND` to output emails to the console (this is usually commented out). In production, use SMTP and configure the host, port, email address, and password of your mail server.
Sample `settings.py` content (database, timezone, directory paths, email configuration)
2. Django Structure in Production Environment
In Episode 1, we explained Django’s overall structure. Here, as a recap, we’ll introduce a diagram that includes the web server configuration. The right side of the diagram shows Django’s internal components (from middleware onward), which you should understand if you’ve read Episodes 1 to 3.
Let’s now look at the left side—the web server integration. During development, you usually don’t use a web server. Instead, you use Django’s built-in `manage.py runserver` command, which runs a lightweight server for displaying the site in a browser. However, `manage.py` does not support parallel processing or automatic process restarting, making it unsuitable for production environments.
In production, Django is deployed alongside web servers like Apache or Nginx. While the technical setup is beyond this article, the key point is that a Python interface called `wsgi` connects the web server to Django. In other words, as long as a web server supports `wsgi`, Django can be deployed with it. Note that `wsgi` is a common Python interface, so other frameworks like Flask can also be deployed using it.
Lastly, let’s briefly discuss `admin.py`, which we haven't covered before. This file controls what is shown in Django’s admin panel. By adding `admin.site.register(ModelName)` to `admin.py`, you can make a model (i.e., a database table) manageable via the admin site. This makes it easy to add or edit data from the web interface.
Django system architecture
▼References
“Django no Tsubo to Kotsu ga Zettai ni Wakaru Hon” by Ryota Ohashi, Shuwa System (Japanese book)
“Genba de Tsukaeru Django Kanri Site no Tsukurikata” by Akihito Yokose (Japanese book)
How to Change Language to Japanese (via settings file) – Code for Django
Overview of Web Server Interfaces: CGI, FastCGI, Apache Modules, WSGI – Blow Up by Black Swan
Who Runs Django? (Deployment Overview) – Qiita
