Hur hanterar du inställningar över olika miljöer?

Question

Accepted Answer

Django-konfiguration finns i `settings.py`, men riktiga applikationer behöver **olika inställningar per miljö** (utveckling, staging, produktion) och måste hålla **hemligheter utanför koden**. Att hantera detta korrekt är både en operativ nödvändighet och ett säkerhetskrav.

## Problemet med en enda 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
```

Hårdkodade värden blandar miljöer och — kritiskt — förbinder hemligheter (SECRET_KEY, databaslösenord, API-nycklar) till versionskontroll, vilket är ett allvarligt säkerhetsbortfall.

## Lösning 1: läs konfiguration från miljövariabler

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

Att läsa konfiguration (särskilt hemligheter) från **miljövariabler** håller det utanför koden — samma kodbas körs i vilken miljö som helst med olika injicerade värden (twelve-factor-metoden).

## Lösning 2: dela upp inställningsfiler per miljö

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

Att dela upp inställningar i en delad `base.py` plus per-miljö-filer (valda via `DJANGO_SETTINGS_MODULE`) separerar miljöspecifik konfiguration på ett rent sätt samtidigt som gemensamma inställningar delas.

## Kritiska produktionsinställningar

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

## Varför det spelar roll

Att hantera inställningar över miljöer är både en **operativ nödvändighet** och en **kritisk säkerhetspraxis** för alla riktiga Django-applikationer.

Applikationer måste bete sig olika över miljöer — utveckling behöver `DEBUG=True` och bekväma lokala inställningar, medan produktion kräver `DEBUG=False`, säkerhetshärdning, riktiga databaser och korrekta hosts — och en enda hårdkodad `settings.py` kan inte tjäna alla dessa.

Viktigare än så är detta ett **större säkerhetsproblem**: hårdkodade hemligheter (SECRET_KEY, databaslösenord, API-nycklar) förbinder dem till versionskontroll, ett av de vanligaste och allvarligaste säkerhetsbortfallen (vem som helst med repo-åtkomst, eller i ett offentligt repo, får nycklarna till din applikation och data).

Att förstå lösningarna — läsa konfiguration och hemligheter från **miljövariabler** (hålla dem utanför koden, twelve-factor-metoden, ofta med verktyg som django-environ och gitignorerade `.env`-filer) och **dela upp inställningar** i en delad bas plus per-miljö-filer — är väsentligt för att distribuera Django på ett säkert och korrekt sätt.

Att känna till de **kritiska produktionsinställningarna** (särskilt att `DEBUG` måste vara `False` i produktion, eftersom `DEBUG=True` läcker stacktracebacks, källvägar och inställningar till angripare, plus `ALLOWED_HOSTS` och säkerhetshärdning) är icke förhandlingsbar produktionskunskap.

Att få inställningshanteringen rätt — hemligheter i miljön, miljölämplig konfiguration, säkra produktionsstandarder — är grundläggande för att köra Django-applikationer professionellt och undvika de allvarliga säkerhetsproblem som kommer från läckta hemligheter eller felkonfigurerade produktionsmiljöer, vilket gör det till viktig, praktiskt-kritisk kunskap för all riktiga distribution.