Hvordan distribuerer du en Django-applikasjon til produksjon?

Question

Accepted Answer

Å distribuere Django til produksjon innebærer å kjøre den bak en ordentlig **WSGI/ASGI-server** og **webserver**, servere statiske filer korrekt, sikre innstillinger og håndtere databasen — svært forskjellig fra den innebygde utviklingsserveren (som **ikke** er for produksjon).

## The production stack

```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 for produksjon. Standard stack: en **application server** (Gunicorn/uWSGI for WSGI, Uvicorn for ASGI/async) kjører Django med flere arbeidere, bak en **webserver** (nginx) som håndterer innkommende forbindelser, TLS og statiske filer.

## Production settings (security-critical)

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

## Static files

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

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

## A typical deployment checklist

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

## Modern deployment approaches

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

Å distribuere Django til produksjon på riktig måte er viktig kunnskap for å ta applikasjoner fra utvikling til virkelig bruk, og det innebærer viktige hensyn som er fundamentalt forskjellige fra lokal utvikling — å gjøre det feil fører til sikkerhetssårbarheter, dårlig ytelse eller ødelagte applikasjoner.

Å forstå **production stack** er grunnleggende: den innebygde utviklingsserveren (`runserver`) er eksplisitt ikke for produksjon (den er enkeltrådet, usikker og kan ikke håndtere belastning), så du må kjøre Django bak en ordentlig **application server** (Gunicorn/uWSGI for WSGI, eller Uvicorn for ASGI/async) med flere arbeidere, foran en **webserver** (nginx) som håndterer forbindelser, TLS og statisk filservering.

Flere aspekter er sikkerhets- og korrekthets-kritiske: **production settings** (spesielt `DEBUG=False`, som er obligatorisk siden `DEBUG=True` lekker sensitive stack traces og konfigurasjon til angripere, pluss `ALLOWED_HOSTS`, en hemmelig `SECRET_KEY` fra miljøet, og HTTPS-tvang), **static file handling** (kjør `collectstatic` og server filer via nginx/CDN/WhiteNoise, siden Django ikke server dem selv i produksjon — en vanlig distribusjonsfeil), og **database management** (en riktig database som PostgreSQL, kjør migrasjoner, sikkerhetskopier).

Å kjenne distribusjons-sjekklisten, moderne tilnærminger (Docker/kontainere, administrerte plattformer, sky-lagring for media, Celery arbeidere som separate tjenester, horisontal skalering med en stateless app), og operasjonelle hensyn (logging, overvåking med Sentry, helsesjekker, prosesshåndtering) er det som skiller en fungerende produksjonsdistribusjon fra en skjør eller usikker.

Fordi enhver reell Django-applikasjon til slutt må distribueres, og fordi distribusjonsfeil (la `DEBUG=True` være på, feilhåndtering av statiske filer, eksponering av hemmeligheter, bruk av dev-serveren) forårsaker reelle sikkerhets- og pålitelighetsproblemer, er det viktig å forstå hvordan man distribuerer Django riktig — stacken, de sikkerhetskritiske innstillingene, statisk/media-håndtering og moderne distribusjonspraksis — viktig, høyinnsats-kunnskap som gjenspeiler evnen til å levere produksjonsklar applikasjoner, et hyppig relevant og profesjonelt essensielt emne for enhver Django-utvikler ansvarlig for live systemer.