Deploying to Production

The dev server is not for production

The runserver command you have used is a development server — convenient, but slow and insecure, and the docs explicitly say never to use it for a live site. Going to production means swapping in production-grade pieces. Here is the cast of characters:

WSGI (Web Server Gateway Interface) is just an agreed-upon way for a Python web app and a web server to talk; Django created a wsgi.py file in your project for exactly this. gunicorn is the server that speaks WSGI and runs your code.

Step 1 — make settings production-safe

Three settings turn a development project into a safe one. Getting these wrong is the most common (and most dangerous) deployment mistake:

# settings.py
DEBUG = False                          # NEVER True in production
ALLOWED_HOSTS = ["yourdomain.com"]     # only answer for hosts you own
# SECRET_KEY must come from the environment, not the code (next step)

Why each matters:

• DEBUG = False — hides the detailed error pages (which leak secrets) and shows a plain error instead.
• ALLOWED_HOSTS — Django refuses requests whose Host header is not in this list, blocking a class of attacks.
• SECRET_KEY — signs sessions and tokens; if it leaks, attackers can forge them, so it must never sit in your committed code.

Step 2 — secrets in environment variables

An environment variable is a value the operating system holds outside your code, so you can keep secrets (the SECRET_KEY, the database password) out of Git. You read them in settings.py instead of hard-coding them:

# settings.py
import os

SECRET_KEY = os.environ["DJANGO_SECRET_KEY"]   # read from the environment
DEBUG = os.environ.get("DEBUG", "False") == "True"

# locally you keep these in a .env file (which is git-ignored):
#   DJANGO_SECRET_KEY=super-long-random-string
#   DEBUG=True

Step 3 — a real database (PostgreSQL)

Development uses SQLite (a single file) — fine for learning, but production wants PostgreSQL, a robust multi-user database. You point Django at it in settings, again reading the connection details from the environment:

# settings.py
DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "NAME": os.environ["DB_NAME"],
        "USER": os.environ["DB_USER"],
        "PASSWORD": os.environ["DB_PASSWORD"],
        "HOST": os.environ["DB_HOST"],
        "PORT": "5432",
    }
}
# install the driver:  pip install psycopg2-binary

After switching databases you run the same python manage.py migrate you already know — Django builds your tables in PostgreSQL exactly as it did in SQLite. Your models and queries do not change at all; that is the ORM paying off.

Step 4 — serve static files with WhiteNoise

With DEBUG = False, Django stops serving static files itself. WhiteNoise is a small tool that lets gunicorn serve your collected static files efficiently — no separate setup needed. Three lines wire it in:

# settings.py
MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "whitenoise.middleware.WhiteNoiseMiddleware",   # add right after security
    # ... the rest ...
]
STATIC_ROOT = BASE_DIR / "staticfiles"
STORAGES = {"staticfiles": {"BACKEND":
    "whitenoise.storage.CompressedManifestStaticFilesStorage"}}
# install:  pip install whitenoise

Remember the collectstatic command from the static-files lesson — you run it as part of deploying so WhiteNoise has the gathered files to serve.

Step 5 — run it with gunicorn

Locally you typed runserver. In production you start gunicorn instead, pointing it at your project’s WSGI application:

# install and run the production server
pip install gunicorn
gunicorn mysite.wsgi:application --bind 0.0.0.0:8000

The deployment checklist

Tie it all together. A reliable first deploy follows this order:

1. Set DEBUG = False and fill in ALLOWED_HOSTS with your domain.
2. Move SECRET_KEY, database details and other secrets into environment variables.
3. Switch the database to PostgreSQL and run python manage.py migrate.
4. Add WhiteNoise and run python manage.py collectstatic.
5. Install and start gunicorn (gunicorn mysite.wsgi:application).
6. Put it on a host (Render, Railway, Fly.io, a VPS with Nginx, or AWS) and visit your live URL.