Hoe beheer je instellingen in verschillende omgevingen?

Question

Accepted Answer

Django-configuratie staat in `settings.py`, maar echte applicaties hebben **verschillende instellingen per omgeving** (development, staging, production) nodig en moeten **geheimen uit de code houden**. Dit correct beheren is zowel een operationele noodzaak als een veiligheidsvereiste.

## Het probleem met een enkele settings.py

```python
# ❌ hardcoded, environment-mixed, and INSECURE settings
DEBUG = True                                    # must be False in production!
SECRET_KEY = "hardcoded-secret-in-code"          # ❌ secret committed to git
DATABASES = {"default": {"PASSWORD": "prod-pw"}} # ❌ production password in code
```

Het hardcoden van waarden vermengt omgevingen en — kritiek — commits geheimen (SECRET_KEY, databasewachtwoorden, API-sleutels) naar versiebeheer, een ernstige veiligheidsinbreuk.

## Oplossing 1: configuratie uit omgevingsvariabelen lezen

```python
import os
from pathlib import Path

SECRET_KEY = os.environ["DJANGO_SECRET_KEY"]    # from the environment, NOT code
DEBUG = os.environ.get("DJANGO_DEBUG", "False") == "True"
ALLOWED_HOSTS = os.environ.get("ALLOWED_HOSTS", "").split(",")
DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "NAME": os.environ["DB_NAME"],
        "PASSWORD": os.environ["DB_PASSWORD"],   # injected per environment
    }
}
# tools like django-environ / python-decouple make this cleaner (+ .env file support)
```

Configuratielezen (vooral geheimen) uit **omgevingsvariabelen** houdt het uit de code — dezelfde codebase draait in elke omgeving met verschillende geïnjecteerde waarden (de twelve-factor benadering).

## Oplossing 2: instellingsbestanden per omgeving splitsen

```text
settings/
  base.py          # shared settings (apps, middleware, templates)
  development.py   # from base import *; DEBUG=True, local DB, debug toolbar
  production.py    # from base import *; DEBUG=False, security hardening, real DB
  test.py          # test-specific settings
```

```python
# production.py
from .base import *
DEBUG = False
ALLOWED_HOSTS = ["example.com"]
SECURE_SSL_REDIRECT = True            # production-only security settings
# select via: DJANGO_SETTINGS_MODULE=config.settings.production
```

Instellingen splitsen in een gedeelde `base.py` plus omgevingsspecifieke bestanden (geselecteerd via `DJANGO_SETTINGS_MODULE`) scheidt omgevingsspecifieke configuratie schoon terwijl gemeenschappelijke instellingen worden gedeeld.

## Kritieke productie-instellingen

```python
DEBUG = False                  # ❗ NEVER True in production — leaks sensitive error info
ALLOWED_HOSTS = ["example.com"] # required when DEBUG=False
SECRET_KEY = os.environ[...]    # strong, secret, from the environment
# + SECURE_SSL_REDIRECT, SESSION_COOKIE_SECURE, HSTS, etc. for hardening
```

```text
✓ NEVER commit secrets — use env vars / a secret manager; gitignore .env
✓ DEBUG=False in production (DEBUG=True leaks tracebacks, settings → security risk)
✓ Commit a .env.example documenting required variables (no real values)
```

## Waarom het belangrijk is

Instellingen beheren in verschillende omgevingen is zowel een **operationele noodzaak** als een **kritieke veiligheidspraktijk** voor elke echte Django-applicatie.

Applicaties moeten zich anders gedragen in omgevingen — development heeft `DEBUG=True` en handige lokale instellingen nodig, terwijl production `DEBUG=False`, veiligheidsverharding, echte databases en juiste hosts vereist — en een enkele hardgecodeerde `settings.py` kan niet allemaal bedienen.

Meer nog, dit is een **groot veiligheidsrisico**: het hardcoden van geheimen (de SECRET_KEY, databasewachtwoorden, API-sleutels) commit ze naar versiebeheer, een van de meest voorkomende en ernstige veiligheidsinbreuken (iedereen met repo-toegang, of in een publieke repo, krijgt de sleutels tot je applicatie en gegevens).

De oplossingen begrijpen — configuratie en geheimen lezen uit **omgevingsvariabelen** (ze uit de code houden, de twelve-factor benadering, vaak met tools als django-environ en `.env`-bestanden die in .gitignore staan) en **instellingen splitsen** in een gedeelde basis plus omgevingsspecifieke bestanden — is essentieel voor het veilig en correct implementeren van Django.

**Kritieke productie-instellingen** kennen (vooral dat `DEBUG` in production `False` moet zijn, omdat `DEBUG=True` tracebacks, bronpaden en instellingen naar aanvallers lekt, plus `ALLOWED_HOSTS` en veiligheidsverharding) is onmisbare productiekennis.

Instellingenbeheer goed doen — geheimen in de omgeving, omgevingsgeschikte configuratie, veilige productie-defaults — is fundamenteel voor het professioneel draaien van Django-applicaties en vermijding van de ernstige kwetsbaarheden die komen uit gelekte geheimen of verkeerd geconfigureerde productieomgevingen, wat het belangrijk, praktisch-kritiek kennis maakt voor elke echte implementatie.