Gunicorn comme serveur WSGI

Django's runserver is great for coding, but it is single-threaded and unsafe for the public web. In production you need a real app server. 🚀

WSGI is the standard contract between a Python web app and a server. It lets any server talk to Django without knowing its internals.

Gunicorn is a production WSGI server that loads your Django app and runs it fast, stable, and concurrently across many requests.

Add Gunicorn to your environment with pip, then pin it in requirements.txt so every deploy uses the same version.

Every project ships a wsgi.py exposing an object named application. Gunicorn imports exactly that object to serve your site.

Point gunicorn at your project's wsgi module. The dotted path mirrors how Python imports it, ending in application.

Use --bind to choose the host and port. Binding to 0.0.0.0 lets the outside world reach the server, not just localhost.

Each worker is a process serving requests in parallel. A common start is 2 times CPU cores plus 1, then tune from real traffic.

Gunicorn runs your Python code, not files. Serving CSS and images is a job you hand to Nginx or WhiteNoise instead.

A live server must survive reboots and crashes. A process manager like systemd restarts Gunicorn automatically so your site stays up.

The --timeout flag kills workers stuck on slow requests. The default is 30 seconds, which protects you from one hung view freezing everything.

Let's confirm what Gunicorn actually serves.

You learned that Gunicorn is the production WSGI server that runs Django via wsgi:application, scales with workers, and leaves static files to others. 🎯