Hvordan deployer du en Django-applikation til produktion?

Question

Accepted Answer

At deploye Django til produktion indebærer at køre den bag en ordentlig **WSGI/ASGI-server** og **webserver**, servere statiske filer korrekt, sikre indstillinger og administrere databasen — helt forskelligt fra den indbyggede udviklerserver (som **ikke** er til produktion).

## Produktionsstakken

```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).
```

Dev-serveren er uegnet til produktion. Standardstakken: en **applikationsserver** (Gunicorn/uWSGI til WSGI, Uvicorn til ASGI/async) kører Django med flere workers bag en **webserver** (nginx), der håndterer indgående forbindelser, TLS og statiske filer.

## Produktionsindstillinger (sikkerhedskritisk)

```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
```

## Statiske filer

```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 og migrationer

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

## En typisk deploy-tjekliste

```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 deployment-tilgange

```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)
```

## Hvorfor det betyder noget

At deploye Django til produktion korrekt er vigtig viden for at få applikationer fra udvikling til virkelig brug, og det involverer vigtige overvejelser, der adskiller sig fundamentalt fra lokal udvikling — at gøre det forkert fører til sikkerhedssårbarheder, dårlig performance eller ødelagte applikationer.

At forstå **produktionsstakken** er grundlæggende: den indbyggede udviklerserver (`runserver`) er eksplicit ikke til produktion (den er enker-trået, usikker og kan ikke håndtere belastning), så du skal køre Django bag en ordentlig **applikationsserver** (Gunicorn/uWSGI til WSGI, eller Uvicorn til ASGI/async) med flere workers, frontet af en **webserver** (nginx), der håndterer forbindelser, TLS og servering af statiske filer.

Flere aspekter er sikkerhed- og korrekthedskritiske: **produktionsindstillinger** (især `DEBUG=False`, som er obligatorisk, da `DEBUG=True` lækker følsomme stack traces og konfiguration til angribere, plus `ALLOWED_HOSTS`, en hemmeligt `SECRET_KEY` fra miljøet og HTTPS-håndhævelse), **håndtering af statiske filer** (kørsel af `collectstatic` og servering af filer via nginx/CDN/WhiteNoise, da Django ikke serverer dem selv i produktion — en almindelig deploy-fejl), og **databaseadministration** (en rigtig database som PostgreSQL, anvendelse af migrationer, backups).

At kende deploy-tjeklisten, moderne tilgange (Docker/containere, administrerede platforme, cloud-lagerplads til media, Celery-workers som separate tjenester, horisontale skalering med en stateless app), og de operationelle bekymringer (logging, overvågning med Sentry, health checks, procesadministration) er det, der adskiller en fungerende produktionsdeploy fra en skrøbelig eller usikker.

Fordi hver rigtig Django-applikation til sidst skal deployes, og fordi deploy-fejl (efterlade `DEBUG=True`, dårlig håndtering af statiske filer, eksponering af hemmeligheder, brug af dev-serveren) forårsager rigtige sikkerhed- og pålidelighedsproblemer, er det vigtigt at forstå, hvordan man deployer Django korrekt — stakken, de sikkerhedskritiske indstillinger, håndtering af statiske/media-filer og moderne deploy-praksis — vigtig, høj-indsats viden, der afspejler evnen til at levere produktionsklar applikationer, et hyppigt relevant og professionelt væsentligt emne for enhver Django-udvikler, der er ansvarlig for liveaktive systemer.