How should a Django project load SECRET_KEY in production, and how do you generate a strong new value for it?

## Where the first key comes from `django-admin startproject` generates a **random `SECRET_KEY`** and writes it into `settings.py`. Since the key is then committed with the rest of the project, Django deliberately prefixes it with **`django-insecure-`**. The prefix is a label, not a weakness in the randomness: it tells you, and the deployment checks, that this value has been exposed in source control and must be replaced before production. ## Generating a proper key Django ships a helper for exactly this job: - **`get_random_secret_key()`** in `django.core.management.utils` returns a **50-character** string drawn from lowercase letters, digits and punctuation, using `get_random_string()`, which is built on the `secrets` module. - It is the same function `startproject` uses, minus the insecure prefix. A one-liner from a shell with Django installed: ```bash python -c "from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())" ``` Paste the output into your secret store, not into a file in the repository. ## Loading it without a silent default The common failure is not a weak key but a **committed fallback**. Compare three patterns: | Pattern | What happens when the variable is missing | |---|---| | `SECRET_KEY = os.environ["DJANGO_SECRET_KEY"]` | `KeyError` at import, the process does not start | | `SECRET_KEY = os.environ.get("DJANGO_SECRET_KEY")` | `None`; the first access to `settings.SECRET_KEY` raises `ImproperlyConfigured` | | `SECRET_KEY = os.environ.get("DJANGO_SECRET_KEY", "dev-key")` | the committed `dev-key` silently becomes the production key | The third row is the one to spot in code review. Anyone who can read the repository can then forge sessions, signed cookies and signed links for production. A separate development settings module, or a local `.env` file that is never committed, gives developers a key without putting one in code that production also runs. ## What Django checks for you 1. **Empty key.** `settings.SECRET_KEY` raises `ImproperlyConfigured("The SECRET_KEY setting must not be empty.")` when the value is empty, so Django refuses to run without one. 2. **Weak key.** `manage.py check --deploy` runs `check_secret_key`, which emits **`security.W009`** unless the key has at least **50 characters**, at least **5 unique characters**, and does not start with `django-insecure-`. 3. **Weak fallbacks.** The same criteria apply to each entry of `SECRET_KEY_FALLBACKS`, reported as **`security.W025`**. These checks catch mistakes; they cannot tell whether a strong-looking key has leaked. ## Keys in tests and local development Development and test runs need a key too, but not the production one: - A **test settings module** can set any fixed, non-empty value; tests never need a secret that matters, and `override_settings(SECRET_KEY=...)` lets a single test prove that a signature fails after a key change. - A developer's **local key** can live in an uncommitted `.env` file or in a development-only settings module that production never imports. - **Continuous integration** should use its own throwaway value rather than a copy of production's key, because build logs and caches are read by more people than production is. The principle is the same everywhere: a key's value should be known only to the environment whose signatures it protects. ## Good habits - One key **per environment**: staging must not be able to forge production's cookies. - The **same** key on every instance of one environment, or users are logged out as requests hop between servers. - Keep the key out of logs, error pages and container image layers; `DEBUG = False` matters here because the debug page is where settings tend to leak, although Django masks settings whose names contain `SECRET` or `KEY` in that page. - Plan how you will **rotate** it before you need to, using `SECRET_KEY_FALLBACKS`.