This episode helps you audit the expense-tracker app before it goes to production: run Django’s automated checks, review settings and sensitive data, then list what needs fixing by risk level. Following the wrap-up of the “Building an Expense Tracker with Django” series, this new series takes that very app into a real environment, one step at a time.

Where to Start: Run check –deploy

Django ships a built-in production configuration checker. Run it with your production settings, not your dev settings:

python manage.py check --deploy

It flags common mistakes such as DEBUG still on, ALLOWED_HOSTS left empty, cookies missing their security flags, or a weak SECRET_KEY. Every warning has its own code and a suggested fix, so do not ignore them just because the app still runs fine on your local machine. Fix them, then run the command again to verify.

A 7-Item Checklist Before Deploying

  • Split settings per environment — do not share one file between dev and production.
  • Every secret lives in environment variables, never committed to Git.
  • DEBUG is off, and ALLOWED_HOSTS contains only the real domains.
  • The production database has a backup, and you have tried restoring it once.
  • Static and media files have a clear serving setup — no dev server.
  • Logs and error alerts go to one central place, not just the console.
  • The deploy process includes running migrations and a post-restart check.

Write the results into a short document, marking each item as passed or not yet passed.

A Sample Settings Snippet to Check Against

DEBUG = False
ALLOWED_HOSTS = ["quanlychitieu.example.com"]
SECURE_SSL_REDIRECT = True
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True

Replace the domain with your real one, then check each value. Any value that is only correct on your local machine is a sign the settings have not been split cleanly yet.

The 20-Episode Roadmap

Week one, foundations: (1) checklist, (2) settings and secrets, (3) Gunicorn and Nginx, (4) PostgreSQL, (5) static and media. Week two, day-to-day operations: (6) safe migrations, (7) logging and Sentry, (8) monitoring and health checks, (9) Redis cache, (10) Celery. Week three, security and performance: (11) security checklist, (12) profiling and slow queries, (13) rate limiting for DRF, (14) safe uploads, (15) backup and restore. Week four, deploy and scale: (16) Docker, (17) CI/CD with GitHub Actions, (18) zero-downtime deploys, (19) scaling the system, (20) runbook and wrap-up.

Apply It to Your Project

Do not try to fix everything in one evening. Pick the three highest-risk items — for example secrets in code, DEBUG still on, or no backup — and finish them before your first deploy.

Related Posts

FAQ

If it runs fine locally, is it ready for production?

Not yet. Local machines usually have DEBUG on, use SQLite, lack HTTPS, and never face real traffic. The production checklist checks exactly those differences.

Does check –deploy replace manual review?

No. It only inspects Django configuration — not backups, deploy processes, or load capacity. Use it as the first step, then review the seven items in this post.

When should I deploy for the first time?

As soon as the app runs with real data at a small scale, provided secrets are separated, DEBUG is off, and a backup exists. Deploying early surfaces real problems instead of guesses.

References