Deploy

Goal for this part

Prepare Campus Press for a world beyond your laptop. You will load SECRET_KEY, DEBUG, and ALLOWED_HOSTS from environment variables, collect static files, and review a practical hosting checklist.

This snapshot is still a teaching app, not a full production hardening guide. It focuses on the habits that prevent the most common beginner deploy mistakes around secrets, hosts, and static files.

What you should already know

You should be able to run Campus Press locally with migrations and understand that SECRET_KEY signs sessions and tokens. Basic comfort with the terminal is enough.

You do not need a paid cloud account to learn from this part. Reading the settings module and running with exported env vars already teaches the main idea.

Concepts: environment-based settings

Source control is for code, not for production secrets. Environment variables let each machine supply different values without editing Python files. DEBUG must be false when exposed to the public internet; ALLOWED_HOSTS must list your domain.

Production usually serves static files via WhiteNoise or a reverse proxy, and often uses Postgres instead of SQLite. The snapshot shows the settings shape even if you still run SQLite locally.

import os
from pathlib import Path

SECRET_KEY = os.environ.get("SECRET_KEY", "dev-only-change-me")
DEBUG = os.environ.get("DEBUG", "0") == "1"
ALLOWED_HOSTS = os.environ.get("ALLOWED_HOSTS", "localhost,127.0.0.1").split(",")

Walkthrough: local run with env secrets

Create and activate a venv inside 12-Deploy, install requirements, export a local SECRET_KEY, migrate, and run the server. Optionally run collectstatic to see how production gathers CSS into one directory.

Platforms such as Render or Railway inject env vars in a dashboard and expect a start command like gunicorn campus_press.wsgi:application. The development server is not meant for public production traffic.

cd fcc-django-blog/12-Deploy
python3 -m venv .venv
source .venv/bin/activate
pip install -r ../requirements.txt
export SECRET_KEY="local-dev-secret"
export DEBUG=1
python manage.py migrate
python manage.py runserver

Hosting overview

On a platform host, set SECRET_KEY, DEBUG=0, and ALLOWED_HOSTS, run migrations on release, collect static files, and start gunicorn (or the platform’s Django recipe). Enable HTTPS before accepting real accounts.

For media uploads at scale, object storage (such as S3-compatible services) beats local disk on ephemeral hosts. For multi-instance apps, prefer managed Postgres over a single SQLite file.

• Never commit production SECRET_KEY values
• Set DEBUG false on public hosts
• Populate ALLOWED_HOSTS with your domain
• Use gunicorn (or similar) behind HTTPS in production

Common mistakes and troubleshooting

DisallowedHost errors mean ALLOWED_HOSTS does not include the domain you typed. Missing CSS after deploy usually means collectstatic was skipped or the static server is misconfigured.

If sessions or password-reset tokens break between restarts, confirm SECRET_KEY is stable in that environment—not a random default generated on each boot.

Try this checklist

Run the deploy snapshot with an exported secret and confirm login still works. Then start with DEBUG=0 locally and notice how error pages become generic—exactly what public users should see.

Skim your host’s documentation for where environment variables are set. Even if you do not deploy today, knowing that screen exists makes the next ship much less intimidating.

• Local export works for demos; hosts need dashboard or systemd env config
• SQLite is fine for learning; plan Postgres for scaled hosting
• Keep teaching defaults out of public production as-is