Hur distribuerar man en Django-applikation till produktion?

Question

Accepted Answer

Att distribuera Django till produktion innebär att köra den bakom en korrekt **WSGI/ASGI-server** och **webbserver**, servera statiska filer korrekt, säkra inställningar och hantera databasen — helt annorlunda än den inbyggda utvecklingsservern (som **inte** är avsedd för produktion).

## Produktionsstacken

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

Development-servern är olämplig för produktion. Standardstacken: en **applikationsserver** (Gunicorn/uWSGI för WSGI, Uvicorn för ASGI/async) kör Django med flera workers, bakom en **webbserver** (nginx) som hanterar inkommande anslutningar, TLS och statiska filer.

## Produktionsinställningar (säkerhetskritiska)

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

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

## Databas och migrationer

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

## En typisk checklista för distribution

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

## Moderna distributionsmetoder

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

## Varför det spelar roll

Att distribuera Django till produktion på rätt sätt är väsentlig kunskap för att ta applikationer från utveckling till verklig användning, och det innebär viktiga överväganden som skiljer sig fundamentalt från lokal utveckling — att göra det fel leder till säkerhetsproblem, dålig prestanda eller brustna applikationer.

Att förstå **produktionsstacken** är grundläggande: den inbyggda utvecklingsservern (`runserver`) är uttryckligen inte för produktion (den är single-threaded, osäker och kan inte hantera belastning), så du måste köra Django bakom en korrekt **applikationsserver** (Gunicorn/uWSGI för WSGI, eller Uvicorn för ASGI/async) med flera workers, frontat av en **webbserver** (nginx) som hanterar anslutningar, TLS och statisk filservering.

Flera aspekter är säkerhets- och korrekthetskritiska: **produktionsinställningar** (särskilt `DEBUG=False`, som är obligatoriskt eftersom `DEBUG=True` läcker känsliga stack traces och konfiguration till angripare, plus `ALLOWED_HOSTS`, en hemlig `SECRET_KEY` från miljön och HTTPS-tvingande), **statisk filhantering** (köra `collectstatic` och servera filer via nginx/CDN/WhiteNoise, eftersom Django inte serverar dem själv i produktion — ett vanligt distributionsfel), och **databashantering** (en verklig databas som PostgreSQL, applicera migrationer, säkerhetskopior).

Att känna till distributionschecklistan, moderna metoder (Docker/containers, hanterade plattformar, molnlagring för media, Celery-workers som separata tjänster, horisontell skalning med en tillståndslös app) och de operativa övervägandena (logging, övervakning med Sentry, hälsokontroller, processhantering) är vad som skiljer en fungerande produktionsdistribution från en skör eller osäker sådan.

Eftersom varje verklig Django-applikation så småningom måste distribueras, och eftersom distributionsmisstag (lämna `DEBUG=True`, felaktig hantering av statiska filer, exponera hemligheter, använda dev-servern) orsakar verkliga säkerhets- och tillförlitlighetsproblem, är det viktigt att förstå hur man distribuerar Django korrekt — stacken, de säkerhetskritiska inställningarna, statisk/media-hantering och moderna distributionsmetoder — viktig, högriskkunskap som återspeglar förmågan att leverera produktionsklara applikationer, ett ofta relevant och professionellt väsentligt ämne för alla Django-utvecklare som ansvarar för live-system.