How do you manage settings across environments?

Question

Accepted Answer

Django configuration lives in `settings.py`, but real applications need **different settings per environment** (development, staging, production) and must keep **secrets out of code**. Managing this correctly is both an operational necessity and a security requirement.

## The problem with a single 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
```

Hardcoding values mixes environments and — critically — commits secrets (SECRET_KEY, database passwords, API keys) into version control, a serious security breach.

## Solution 1: read config from environment variables

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

Reading config (especially secrets) from **environment variables** keeps it out of code — the same codebase runs in any environment with different injected values (the twelve-factor approach).

## Solution 2: split settings files per environment

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

Splitting settings into a shared `base.py` plus per-environment files (selected via `DJANGO_SETTINGS_MODULE`) cleanly separates environment-specific configuration while sharing common settings.

## Critical production settings

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

## Why it matters

Managing settings across environments is both an **operational necessity** and a **critical security practice** for any real Django application.

Applications must behave differently across environments — development needs `DEBUG=True` and convenient local settings, while production requires `DEBUG=False`, security hardening, real databases, and proper hosts — and a single hardcoded `settings.py` can't serve all of these.

More importantly, this is a **major security concern**: hardcoding secrets (the SECRET_KEY, database passwords, API keys) commits them to version control, one of the most common and serious security breaches (anyone with repo access, or in a public repo, gets the keys to your application and data).

Understanding the solutions — reading config and secrets from **environment variables** (keeping them out of code, the twelve-factor approach, often with tools like django-environ and gitignored `.env` files) and **splitting settings** into a shared base plus per-environment files — is essential for deploying Django safely and correctly.

Knowing the **critical production settings** (especially that `DEBUG` must be `False` in production, since `DEBUG=True` leaks tracebacks, source paths, and settings to attackers, plus `ALLOWED_HOSTS` and security hardening) is non-negotiable production knowledge.

Getting settings management right — secrets in the environment, environment-appropriate configuration, secure production defaults — is fundamental to running Django applications professionally and avoiding the serious vulnerabilities that come from leaked secrets or misconfigured production environments, making it important, practically-critical knowledge for any real deployment.