Django requires Python. See the table in the next question for the versions of Python that work with each version of Django. Other Python libraries may be required for some uses, but you’ll receive an error about it as they’re needed.
For a development environment – if you just want to experiment with Django – you don’t need to have a separate Web server installed; Django comes with its own lightweight development server. For a production environment, Django follows the WSGI spec, PEP 3333, which means it can run on a variety of server platforms. See Deploying Django for some popular alternatives.
If you want to use Django with a database, which is probably the case, you’ll also need a database engine. PostgreSQL is recommended, because we’re PostgreSQL fans, and MySQL, SQLite, and Oracle are also supported.
| Django version | Python versions |
|---|---|
| 1.11 | 2.7, 3.4, 3.5, 3.6, 3.7 (added in 1.11.17) |
| 2.0 | 3.4, 3.5, 3.6, 3.7 |
| 2.1 | 3.5, 3.6, 3.7 |
| 2.2 | 3.5, 3.6, 3.7, 3.8 (added in 2.2.8), 3.9 (added in 2.2.17) |
For each version of Python, only the latest micro release (A.B.C) is officially supported. You can find the latest micro version for each series on the Python download page.
Typically, we will support a Python version up to and including the first Django LTS release whose security support ends after security support for that version of Python ends. For example, Python 3.3 security support ends September 2017 and Django 1.8 LTS security support ends April 2018. Therefore Django 1.8 is the last version to support Python 3.3.
Python 3 is recommended. Django 1.11 is the last version to support Python 2.7. Support for Python 2.7 and Django 1.11 ends in 2020.
Since newer versions of Python are often faster, have more features, and are better supported, the latest version of Python 3 is recommended.
You don’t lose anything in Django by using an older release, but you don’t take advantage of the improvements and optimizations in newer Python releases. Third-party applications for use with Django are, of course, free to set their own version requirements.
Generally, if you’re using code in production, you should be using a stable release. The Django project publishes a full stable release every nine months or so, with bugfix updates in between. These stable releases contain the API that is covered by our backwards compatibility guarantees; if you write code against stable releases, you shouldn’t have any problems upgrading when the next official version is released.
Nov 02, 2020