Deploy

Goal for this part

Prepare Campus Wire for a world beyond your laptop. You will load SECRET_KEY and database settings from environment variables, keep debug off by default, 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 and configuration.

What you should already know

You should be able to run Campus Wire locally with a virtual environment and understand that SECRET_KEY protects sessions and CSRF tokens. Basic comfort with the terminal is enough.

You do not need a paid cloud account to learn from this part. Reading the configuration code and running with a local exported secret already teaches the main idea.

Concepts: environment-based configuration

Source control is for code, not for production secrets. Environment variables let each machine—your laptop, a staging host, a production service—supply different values without editing Python files.

Debug mode is helpful locally and dangerous when exposed to the public internet. This snapshot turns debug on only when you explicitly set FLASK_DEBUG=1, which is a safer default for deploy-minded code.

import os

app.config["SECRET_KEY"] = os.environ.get("SECRET_KEY", "dev-only-change-me")
app.config["SQLALCHEMY_DATABASE_URI"] = os.environ.get(
    "DATABASE_URL",
    "sqlite:///campus_wire.db",
)
app.config["DEBUG"] = os.environ.get("FLASK_DEBUG", "0") == "1"

Walkthrough: local run with an env secret

Create and activate a venv inside 08-Deploy, install requirements, export a local SECRET_KEY, then start the app. The export lasts for that terminal session unless you add it to a tool that loads env files.

Platforms such as Render or Railway often inject PORT. This snapshot can read HOST and PORT when you run python app.py for demos, which mirrors how hosts expect apps to listen on an assigned port.

cd fcc-flask-blog/08-Deploy
python3 -m venv .venv
source .venv/bin/activate
pip install -r ../requirements.txt
export SECRET_KEY="local-dev-secret"
python app.py

Hosting overview

On a platform like Render or Railway, set SECRET_KEY in the dashboard, install requirements, and start with a WSGI server such as gunicorn app:app. The development server built into Flask is not meant for public production traffic.

On a VPS, run gunicorn behind nginx or Caddy, keep secrets in the process environment, and enable HTTPS before accepting real accounts. For multi-instance hosting, prefer managed Postgres over a single SQLite file that cannot be shared cleanly across machines.

• Never commit production SECRET_KEY values
• Add gunicorn (or similar) on Linux hosts
• Use migrations for schema changes beyond classroom create_all()
• Turn off public debug mode before real users arrive

Common mistakes and troubleshooting

If sessions or CSRF break after deploy, check that SECRET_KEY is set to a stable value in that environment—and not still using a throwaway default that changes between restarts on some setups.

If the app works locally but not on a host, compare Python versions, installed requirements, working directory, and whether the platform expects gunicorn instead of python app.py. Read the host’s build logs from the top; the first error is usually the real one.

Try this checklist

Run the deploy snapshot with an exported secret and confirm login still works. Then intentionally unset SECRET_KEY in a new terminal, start again, and notice you are on the insecure default—exactly what you want to avoid in production.

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 this app’s teaching defaults out of public production as-is