Django: Difference between using server through manage.py and other servers like gunicorn etc. Which is better?
Question:
I have been running my beginner Django projects with manage.py runserver. I see suggestions to use gunicorn instead. What is the difference ?
Answers:
manage.py runserver is only a development server, it is not meant for production under any circumstance. You need to use something like Apache, uWSGI, NGINX or some other server to serve your django project once it’s ready for deployment.
nginx and gunicorn are probably the most popular configuration for production deployments. Before detailing why gunicorn is recommended over runserver, let’s quickly clarify the difference between nginx and gunicorn, because both state that they are web servers.
NGINX should be your entrance point to the public, it’s the server listening to port 80 (http) and 443 (https). Its main purpose is handling HTTP requests, that is applying redirects, HTTP Auth if required, managing TSL/SSL Certificates and – among other things – decides where your requests is finally going to. E.g. there maybe a node.js app living on localhost:3000 that awaits requests on/foo/api while gunicorn is waiting at localhost:8000 to serve your awesome app. This functionality of proxying incoming requests to so called upstream services (in this case node.js and gunicorn) is called reverse-proxy.
GUNICORN is a server that translates HTTP requests into Python. WSGI is one of the interfaces/implementations that does that (e.g., the text parts of http headers are transformed into key-value dicts).
Django’s built-in development web server (what you get when you run manage.py runserver) provides that functionality also, but it targets a development environment (e.g., restart when the code changes), whereas Gunicorn targets production.
Gunicorn has many features that Django’s built-in server is lacking:
- gunicorn can spawn multiple worker processes to parallelize incoming requests to multiple CPU cores
- gunicorn has better logging
- gunicorn is generally optimized for speed
- gunicorn can be
configured to fine grades depending on your setup
- gunicorn is
actively designed and maintained with security in mind
There are web servers other than gunicorn, but gunicorn (inspired by ruby’s unicorn) is very popular and easy to setup, and hence is not only a good starting point, but a professional solution that is used by large projects.
I have been running my beginner Django projects with manage.py runserver. I see suggestions to use gunicorn instead. What is the difference ?
manage.py runserver is only a development server, it is not meant for production under any circumstance. You need to use something like Apache, uWSGI, NGINX or some other server to serve your django project once it’s ready for deployment.
nginx and gunicorn are probably the most popular configuration for production deployments. Before detailing why gunicorn is recommended over runserver, let’s quickly clarify the difference between nginx and gunicorn, because both state that they are web servers.
NGINX should be your entrance point to the public, it’s the server listening to port 80 (http) and 443 (https). Its main purpose is handling HTTP requests, that is applying redirects, HTTP Auth if required, managing TSL/SSL Certificates and – among other things – decides where your requests is finally going to. E.g. there maybe a node.js app living on localhost:3000 that awaits requests on/foo/api while gunicorn is waiting at localhost:8000 to serve your awesome app. This functionality of proxying incoming requests to so called upstream services (in this case node.js and gunicorn) is called reverse-proxy.
GUNICORN is a server that translates HTTP requests into Python. WSGI is one of the interfaces/implementations that does that (e.g., the text parts of http headers are transformed into key-value dicts).
Django’s built-in development web server (what you get when you run manage.py runserver) provides that functionality also, but it targets a development environment (e.g., restart when the code changes), whereas Gunicorn targets production.
Gunicorn has many features that Django’s built-in server is lacking:
- gunicorn can spawn multiple worker processes to parallelize incoming requests to multiple CPU cores
- gunicorn has better logging
- gunicorn is generally optimized for speed
- gunicorn can be
configured to fine grades depending on your setup - gunicorn is
actively designed and maintained with security in mind
There are web servers other than gunicorn, but gunicorn (inspired by ruby’s unicorn) is very popular and easy to setup, and hence is not only a good starting point, but a professional solution that is used by large projects.