Independent comparison · no paid rankings
Home / Blog / Django in production: the minimum path to a clean deployment
Guide

Django in production: the minimum path to a clean deployment

Gunicorn behind nginx, `collectstatic`, env vars, migrations and separate media — the Django prod path fits in a few steps, provided you do not skip collectstatic.

3 min read Updated Jul 19, 2026

python manage.py runserver 0.0.0.0:8000 exposed on the Internet with DEBUG=True. SQLite in production. Uploads in the repo. Three mistakes that turn a promising Django project into a data breach waiting to happen. The minimum path to a clean deployment is well known — it just takes not cutting corners out of fatigue.

Django in production is not more complex than another web framework. It is mostly discipline: separate environments, externalise files, and never confuse what worked locally with what is acceptable in public.

Minimum path in seven steps

StepCommand / actionFrequent omission
Prod settingssettings/production.py, DEBUG=FalseCommitted secret key
DatabasePostgreSQL or MySQLSQLite in prod
Staticcollectstatic → nginx/CDNStatic served by Django
MediaObject storage or dedicated volumeMedia in git
WSGIGunicorn + socket or portrunserver
Proxynginx TLS + headersNo HTTPS redirect
Migrationsmigrate with backupmigrate without rollback test

Django in production is mostly stopping what was convenient locally.

Typical stack


Internet → nginx (TLS, static) → Gunicorn (workers) → Django

                                      ↓

                                 PostgreSQL

                                      ↓

                            Redis (cache/Celery optional)

Gunicorn workers: (2 × CPU) + 1 as a starting rule — adjust for memory and heavy requests.

Variables and secrets

Set DJANGO_SETTINGS_MODULE to production config. Use a unique SECRET_KEY per environment. List ALLOWED_HOSTS explicitly — no * wildcard. Configure email backend (SMTP or transactional API). Add CSRF_TRUSTED_ORIGINS for multiple domains. Inject vars via host or file outside repo.

Celery and async tasks

If you send email, run exports or heavy webhooks, plan Redis or RabbitMQ broker, supervised worker, failed task monitoring, and separate web and batch workers if load requires it.

The climax: Django prod is boring by design

See Hosting Node.js for long-process culture — proxy plus workers principles are similar.

Decide and move forward without blind spots

Create a separate prod settings module and forbid DEBUG=True in production. Move to PostgreSQL with regularly tested backups. Configure nginx plus Gunicorn under systemd or equivalent. Integrate collectstatic in the deploy pipeline. Monitor 5xx errors and media disk space. Browse Python hosts in the directory.

Frequently asked questions

Can Django run without Gunicorn?

Not in prod — Gunicorn/uWSGI/ASGI behind proxy.

Where to serve static and media?

Static nginx/CDN after collectstatic; media object storage or backed volume.

Do you need Celery from day one?

From async tasks — otherwise defer with Redis planned.

Which host for a first Django app?

Python PaaS or VPS with managed PostgreSQL. Avoid shared without WSGI control.


Production Django is not recognised by its URL — it is recognised by the absence of runserver in ps aux.

Compare European hosts

Filter by compliance, location and use case — then open the sheets to verify the real scope.

Browse the directory
Blog

Related reading

All articles →