= Server arrangements = [[TOC]] Because Django uses [http://www.python.org/peps/pep-0333.html WSGI], it can run on any WSGI-compatible Web server. Here's how to run Django on various server arrangements. == Apache == === Apache with mod_python === * See the [http://www.djangoproject.com/documentation/modpython/ official documentation]. * you can also look at the [wiki:django_apache_and_mod_rewrite] small tutorial. === Apache with FastCGI === * See the [http://www.djangoproject.com/documentation/fastcgi/ official documentation]. * Mac OS X users, see [wiki:OsxFcgi Django with FCGI on OS X]. * For running django with mod_fcgid or with straight CGI, see [http://www.djangosnippets.org/snippets/1307/] === Apache with SCGI === * [http://www.mems-exchange.org/software/scgi/ SCGI] can be used with Apache [https://simon.bofh.ms/cgi-bin/trac-django-projects.cgi/wiki/DjangoScgi#preview like this]. It builds on stuff from the Apache+FCGI documentation above. ''The material at simon.bofh.ms has been hard to get - server sometimes responds, sometimes not IME. In any event, #3047 has patches, and seems to be on track to become the official way to do SCGI with Django.'' === Apache with mod_wsgi === * See the [http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango mod_wsgi official docs]. * See this [wiki:django_apache_and_mod_wsgi page for a step by step] procedure to configure it on windows. == lighttpd == === lighttpd with Apache === * See [http://www.inerciasensorial.com.br/2007/06/10/perils-of-software-development/lighttpd-with-apache/ this page]. === lighttpd with FastCGI === * See the [http://www.djangoproject.com/documentation/fastcgi/ official documentation]. * Django/lighttpd/FastCGI [http://manuals.textdrive.com/read/book/15 instructions for use on TextDrive shared hosting accounts] are also available. === lighttpd with SCGI === * See [http://sayspy.blogspot.com/2006/09/ignorant-newbie-running-django-using.html Running Django using SCGI through LightTPD]. == FastCGI == * [wiki:MultipleVersionsWithFCGI]. * [wiki:InitdScriptForLinux FastCGI init scripts] == Twisted.web2 == * See #172. == nginx == * See [http://www.rkblog.rk.edu.pl/w/p/django-nginx/ Django on nginx] and [http://www.alrond.com/en/2007/mar/01/start-django-with-nginx/ Start Django with nginx]. I've been serving up my django site via nginx for a short while now and wanted to report my setup so that others may give it a shot. My performance over the previous setup with lighttpd is a bit better. This setup uses much less cpu and memory to achieve much better throughput and response time. The simple syntax of the nginx.conf allows you to setup a cluster of backend processes quite easily to handle load. Currently this is my nginx.conf relevant to my django site. You can reference the above links for more information about additional options. {{{ upstream djangoserv { server 127.0.0.1:8801; } server { listen 80; root /path/to/app; server_name test.local.domain; access_log /path/to/logs/appname-access.log main; error_log /path/to/logs/appname-error.log; location /styles { root /path/to/styles; } location /javascripts { root /path/to/javascripts; } location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|mov) { access_log off; expires 30d; } location / { # host and port to fastcgi server fastcgi_pass 127.0.0.1:8801; fastcgi_param PATH_INFO $fastcgi_script_name; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param QUERY_STRING $query_string; fastcgi_param SERVER_NAME $server_name; fastcgi_param SERVER_PORT $server_port; fastcgi_param SERVER_PROTOCOL $server_protocol; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_pass_header Authorization; fastcgi_intercept_errors off; } } }}} Once you fire up nginx you will need to start your nginx fastcgi processes. I simply use: {{{ python2.4 manage.py runfcgi method=threaded host=127.0.0.1 port=8801 }}} == Django behind/inside Zope == It's possible to query a Django site from Zope or Plone and return the result. This allows you to include a Django site inside a pre-existing Zope/Plone site. It's good for custom content that you don't want to use existing Zope technologies to develop. The main trick is to write a "Script (Python)" object that loads up Django's request handling mechanisms, while ensuring (as with any Django deployment) that your Django site is on the current PYTHONPATH and that the env var DJANGO_SETTINGS_MODULE is set to your project's settings file. I'm afraid I've lost the original code that did this but the approach was pretty simple. However, an even better approach showed up later (found due to Plone's caching mechanisms causing problems with the above -- it would occasionally call the script multiple times, which on POSTs is a very bad thing...) which is simply to use Apache as the primary frontend, and using mod_proxy to send some requests to the Plone app server running on another port, with other requests going to your Django site, however you wish to deploy it with Apache (I used mod_python, would be using mod_wsgi today). E.g. proxy /cms and /documents to Plone, with a catchall serving up your Django site. (Or vice-versa, if you desire -- it's all just Apache at this point.) With this latter approach, I also had to create a simple Plone script, but this one was for the Django site to query Plone to ask about credentials, since I was using Plone for authentication. I.e. a simple Django middleware would look for the Plone auth cookie and send it onwards to the Plone script, which would use the username or token to check whether the credentials were accurate / the user had a currently live session. It would then return a boolean value and anything else the Django code needed to know (e.g. list of group memberships). As with the even older code, this code is no longer around :( == CGI == Running Django as a traditional CGI is possible and would work the same as running any other sort of Python CGI script, but is generally not recommended. With traditional CGI, the program which will be run -- in this case, Django plus a Django-powered application -- is loaded from disk into memory each time a request is served, which results in a significant amount of processing overhead and much slower responses. FastCGI and SCGI, in contrast, load the code only once -- when the server starts up -- and keep it in memory as long as the server is running, resulting in much faster responses. If that hasn't put you off and you still need CGI, take a look at #2407. == !CherryPy and WSGI == * See [http://xhtml.net/scripts/Django-CherryPy-server-DjangoCerise Run your Django app with the CherryPy server - DjangoCerise]. Version 1.2 now supports SSL. Rock solid behind a proxy like NGINX. * [http://lincolnloop.com/blog/2008/mar/25/serving-django-cherrypy/ CherryPy server as a management command] and [http://yml-blog.blogspot.com/2009/02/serving-django-via-cherrypy-behind.html serving it behind Cherokee] == Devserver - Django built-in development server == * Once again, this isn't for production use, but the [http://www.djangoproject.com/documentation/django_admin/ official documentation] may help. Ticket #4996 has a patch to daemonize which may be useful == Differences between Devserver and production == * [wiki:devserver_and_apache_differences] - tips to help ease the transition.