Hoe deploy je een Django-applicatie naar productie?

Question

Accepted Answer

Het deployen van Django naar productie omvat het uitvoeren ervan achter een degelijke **WSGI/ASGI-server** en **webserver**, het correct serveren van statische bestanden, het beveiligen van instellingen en het beheren van de database — aanzienlijk anders dan de ingebouwde ontwikkelingserver (die **niet** voor productie is).

## De productiestapel

```text
Client → NGINX (web server) → GUNICORN (WSGI app server) → DJANGO
           │                      (runs your Python app, multiple workers)
           └─ serves static/media files directly (efficient)

❌ NEVER use `python manage.py runserver` in production — it's single-threaded,
   insecure, and not built for load. Use Gunicorn (WSGI) or Uvicorn (ASGI for async).
```

De dev-server is ongeschikt voor productie. De standaardstapel: een **applicatieserver** (Gunicorn/uWSGI voor WSGI, Uvicorn voor ASGI/async) voert Django uit met meerdere workers, achter een **webserver** (nginx) die binnenkomende verbindingen, TLS en statische bestanden afhandelt.

## Instellingen voor productie (beveiligingskritiek)

```python
DEBUG = False                            # ❗ MUST be False — DEBUG=True leaks sensitive info
ALLOWED_HOSTS = ["example.com"]          # required when DEBUG=False
SECRET_KEY = os.environ["SECRET_KEY"]    # from the environment, NOT committed
SECURE_SSL_REDIRECT = True               # force HTTPS
SESSION_COOKIE_SECURE = True
SECURE_HSTS_SECONDS = 31536000
```

## Statische bestanden

```bash
python manage.py collectstatic           # gather static files into STATIC_ROOT
# then serve them via nginx or a CDN — or use WhiteNoise to serve them from the app
# (Django does NOT serve static files itself in production)
```

## Database en migraties

```bash
python manage.py migrate                  # apply migrations to the production DB
# use a real database (PostgreSQL), connection pooling, regular backups
```

## Een typische implementatiechecklist

```text
1. Set production environment variables (SECRET_KEY, DB credentials, DEBUG=False)
2. Run migrations (manage.py migrate)
3. Collect static files (collectstatic) → serve via nginx/CDN/WhiteNoise
4. Run the app with Gunicorn/Uvicorn (multiple workers, behind nginx)
5. Enable HTTPS (TLS certificates, e.g. Let's Encrypt)
6. Set up logging, error monitoring (Sentry), health checks
7. Add a process manager (systemd/supervisor) or use containers (Docker) + orchestration
8. Run `manage.py check --deploy` to audit security settings
```

## Moderne implementatiebenaderingen

```text
✓ Containers (Docker) + orchestration (Kubernetes) or platforms (Heroku, Railway, Render)
✓ Managed databases, separate static/media storage (S3 + CDN)
✓ Background workers (Celery) + a broker (Redis) as separate services
✓ Horizontal scaling: multiple app instances behind a load balancer (keep app STATELESS)
```

## Waarom het belangrijk is

Het correct deployen van Django naar productie is essentiële kennis voor het brengen van applicaties van ontwikkeling naar real-world gebruik, en het omvat belangrijke overwegingen die fundamenteel verschillen van lokale ontwikkeling — het verkeerd doen leidt tot beveiligingskwetsbaarheden, slechte prestaties of kapotte applicaties.

Het begrijpen van de **productiestapel** is fundamenteel: de ingebouwde ontwikkelingserver (`runserver`) is expliciet niet voor productie (deze is single-threaded, onveilig en kan geen belasting aan), dus je moet Django achter een degelijke **applicatieserver** uitvoeren (Gunicorn/uWSGI voor WSGI, of Uvicorn voor ASGI/async) met meerdere workers, voorafgegaan door een **webserver** (nginx) die verbindingen, TLS en statische bestandservering afhandelt.

Verscheidene aspecten zijn beveiligings- en correctheidskritiek: **productie-instellingen** (vooral `DEBUG=False`, wat verplicht is aangezien `DEBUG=True` gevoelige tracebacks en configuratie aan aanvallers onthult, plus `ALLOWED_HOSTS`, een geheime `SECRET_KEY` uit de omgeving en HTTPS-handhaving), **statische bestandenafhandeling** (het uitvoeren van `collectstatic` en het serveren van bestanden via nginx/CDN/WhiteNoise, aangezien Django deze zelf niet in productie serveert — een veelvoorkomend implementatieprobleem), en **databasebeheer** (een echte database zoals PostgreSQL, migraties toepassen, back-ups).

Het kennen van de implementatiechecklist, moderne benaderingen (Docker/containers, beheerde platforms, cloudobslag voor media, Celery-workers als afzonderlijke services, horizontale schaling met een stateless app) en operationele overwegingen (logging, monitoring met Sentry, gezondheidscontroles, processenmanagement) onderscheidt een werkende productie-implementatie van een fragiele of onveilige.

Omdat elke echte Django-applicatie uiteindelijk moet worden geïmplementeerd, en omdat implementatiefouten (het achterlaten van `DEBUG=True`, het verkeerd afhandelen van statische bestanden, het blootstellen van geheimen, het gebruiken van de dev-server) echte beveiligings- en betrouwbaarheidsproblemen veroorzaken, is het begrijpen hoe je Django correct implementeert — de stapel, de beveiligingskritieke instellingen, het afhandelen van statische/media-inhoud en moderne implementatiepraktijken — belangrijk, hoog-risico-kennis die de capaciteit weerspiegelt om productie-klaar applicaties uit te geven, een frequent relevante en professioneel essentiële onderwerp voor elke Django-ontwikkelaar die verantwoordelijk is voor live systemen.