mod_wsgiLink to this heading#Deploying Django with Apache and mod_wsgi is a tried and tested way to get\nDjango into production.
\nmod_wsgi is an Apache module which can host any Python WSGI application,\nincluding Django. Django will work with any version of Apache which supports\nmod_wsgi.
\nThe official mod_wsgi documentation is your source for all the details about\nhow to use mod_wsgi. You’ll probably want to start with the installation and\nconfiguration documentation.
\nOnce you’ve got mod_wsgi installed and activated, edit your Apache server’s\nhttpd.conf file and add the following.
\nWSGIScriptAlias / /path/to/mysite.com/mysite/wsgi.py\nWSGIPythonHome /path/to/venv\nWSGIPythonPath /path/to/mysite.com\n\n<Directory /path/to/mysite.com/mysite>\n<Files wsgi.py>\nRequire all granted\n</Files>\n</Directory>\nThe first bit in the WSGIScriptAlias line is the base URL path you want to\nserve your application at (/ indicates the root url), and the second is the\nlocation of a “WSGI file” – see below – on your system, usually inside of\nyour project package (mysite in this example). This tells Apache to serve\nany request below the given URL using the WSGI application defined in that\nfile.
If you install your project’s Python dependencies inside a virtual\nenvironment, add the path using WSGIPythonHome. See the mod_wsgi\nvirtual environment guide for more details.
The WSGIPythonPath line ensures that your project package is available for\nimport on the Python path; in other words, that import mysite works.
The <Directory> piece ensures that Apache can access your wsgi.py\nfile.
Next we’ll need to ensure this wsgi.py with a WSGI application object\nexists. As of Django version 1.4, startproject will have created one\nfor you; otherwise, you’ll need to create it. See the WSGI overview\ndocumentation for the default contents you\nshould put in this file, and what else you can add to it.
mod_wsgi daemon modeLink to this heading#“Daemon mode” is the recommended mode for running mod_wsgi (on non-Windows\nplatforms). To create the required daemon process group and delegate the\nDjango instance to run in it, you will need to add appropriate\nWSGIDaemonProcess and WSGIProcessGroup directives. A further change\nrequired to the above configuration if you use daemon mode is that you can’t\nuse WSGIPythonPath; instead you should use the python-path option to\nWSGIDaemonProcess, for example:
WSGIDaemonProcess example.com python-home=/path/to/venv python-path=/path/to/mysite.com\nWSGIProcessGroup example.com\nIf you want to serve your project in a subdirectory\n(https://example.com/mysite in this example), you can add WSGIScriptAlias\nto the configuration above:
WSGIScriptAlias /mysite /path/to/mysite.com/mysite/wsgi.py process-group=example.com\nSee the official mod_wsgi documentation for details on setting up daemon\nmode.
\nDjango doesn’t serve files itself; it leaves that job to whichever Web\nserver you choose.
\nWe recommend using a separate Web server – i.e., one that’s not also running\nDjango – for serving media. Here are some good choices:
\n\nIf, however, you have no option but to serve media files on the same Apache\nVirtualHost as Django, you can set up Apache to serve some URLs as\nstatic media, and others using the mod_wsgi interface to Django.
This example sets up Django at the site root, but serves robots.txt,\nfavicon.ico, and anything in the /static/ and /media/ URL space as\na static file. All other URLs will be served using mod_wsgi:
Alias /robots.txt /path/to/mysite.com/static/robots.txt\nAlias /favicon.ico /path/to/mysite.com/static/favicon.ico\n\nAlias /media/ /path/to/mysite.com/media/\nAlias /static/ /path/to/mysite.com/static/\n\n<Directory /path/to/mysite.com/static>\nRequire all granted\n</Directory>\n\n<Directory /path/to/mysite.com/media>\nRequire all granted\n</Directory>\n\nWSGIScriptAlias / /path/to/mysite.com/mysite/wsgi.py\n\n<Directory /path/to/mysite.com/mysite>\n<Files wsgi.py>\nRequire all granted\n</Files>\n</Directory>\nWhen django.contrib.staticfiles is in INSTALLED_APPS, the\nDjango development server automatically serves the static files of the\nadmin app (and any other installed apps). This is however not the case when you\nuse any other server arrangement. You’re responsible for setting up Apache, or\nwhichever Web server you’re using, to serve the admin files.
The admin files live in (django/contrib/admin/static/admin) of the\nDjango distribution.
We strongly recommend using django.contrib.staticfiles to handle the\nadmin files (along with a Web server as outlined in the previous section; this\nmeans using the collectstatic management command to collect the\nstatic files in STATIC_ROOT, and then configuring your Web server to\nserve STATIC_ROOT at STATIC_URL), but here are three\nother approaches:
Create a symbolic link to the admin static files from within your\ndocument root (this may require +FollowSymLinks in your Apache\nconfiguration).
Use an Alias directive, as demonstrated above, to alias the appropriate\nURL (probably STATIC_URL + admin/) to the actual location of\nthe admin files.
Copy the admin static files so that they live within your Apache\ndocument root.
Django provides a handler to allow Apache to authenticate users directly\nagainst Django’s authentication backends. See the mod_wsgi authentication\ndocumentation.
\n