Environment Variables with .env
In this page:
The Shape of a .env File
A .env file is a plain text file with one KEY=value pair per line. It lives in the project root, is never committed to version control, and holds values that differ between developers and environments.
Example: The Shape of a .env File
A .env file is a plain text file with one KEY=value pair per line. It lives in the project root, is never committed to version control, and holds values that differ between developers and environments.
# .env (example values only -- never commit real secrets)
SECRET_KEY=your-secret-key-here
DJANGO_DEBUG=True
DATABASE_NAME=db.sqlite3
{# Django-only code -- models.py/views.py/urls.py/settings.py
snippets, or template markup using Django template tags/variables
-- can't run standalone via Judge0 or the browser preview, since
it needs a real Django project. Only this course's pure-Python
examples (example_lang == 'python', no Django imports) are
actually runnable, so those still get the button below. #}
Loading .env Values with python-dotenv
The python-dotenv package reads a .env file and loads its values into the environment so settings.py can pick them up with os.environ.get(), the same way it would read variables set by the hosting platform in production.
Example: Loading .env Values with python-dotenv
The python-dotenv package reads a .env file and loads its values into the environment so settings.py can pick them up with os.environ.get(), the same way it would read variables set by the hosting platform in production.
pip install python-dotenv
⚠️ Run this command in your terminal.
Reading Values in settings.py
Once loaded, environment variables are read with os.environ.get(), with a sensible default for local development. This keeps the real secret value out of the source code entirely.
Warning: Never hardcode a fallback that looks like a real production secret -- keep defaults obviously safe for local use only.
Example: Reading Values in settings.py
Once loaded, environment variables are read with os.environ.get(), with a sensible default for local development. This keeps the real secret value out of the source code entirely.
# settings.py
import os
from dotenv import load_dotenv
load_dotenv()
SECRET_KEY = os.environ.get('SECRET_KEY', 'dev-only-insecure-key')
DEBUG = os.environ.get('DJANGO_DEBUG', 'True') == 'True'
{# Django-only code -- models.py/views.py/urls.py/settings.py
snippets, or template markup using Django template tags/variables
-- can't run standalone via Judge0 or the browser preview, since
it needs a real Django project. Only this course's pure-Python
examples (example_lang == 'python', no Django imports) are
actually runnable, so those still get the button below. #}
- Committing a real .env file (with real secrets) to version control instead of only committing a .env.example template.
- Hardcoding SECRET_KEY directly in settings.py instead of reading it from the environment.
- Forgetting to add .env to .gitignore, leaking secrets the moment the repo is pushed.
- Environment variables keep secrets like SECRET_KEY and database passwords out of the codebase.
- A .env file stores these values locally as simple KEY=value lines and is loaded at startup.
- settings.py reads values with os.environ.get() instead of hardcoding them.
- .env must be excluded from version control so real secrets never get committed.
Chapter Quiz — Complete all 9 topics to unlock
0/9 topics done
Complete these topics first: