Debugging is great, but it usually starts with being wrong.

Recently my Django blog on AWS started throwing “too many redirects” errors in production while working perfectly on my local machine. After hours of poking at Nginx redirects, SECURE_SSL_REDIRECT, and HTTPS settings, the real bug turned out to be embarrassingly simple: the EC2 server was still running an old Docker image.

I kept rebuilding and pushing new images, but my docker-compose file on EC2 was pinned to an older tag, so none of my fixes were actually deployed. Inside the container, Django’s settings still showed the old configuration—missing CSRF_TRUSTED_ORIGINS, no SECURE_PROXY_SSL_HEADER, and redirect logic that made sense weeks ago but not anymore.

That single mistake exposed a bigger lesson: debugging production issues is often about debugging your deployment process, not just your code. Now my checklist always includes:

Verify which image is running with docker ps, not just what I think I pushed. ​

Keep one canonical production.py that reads everything from environment variables and includes all security settings. ​

Treat tag changes as releases—either bump a version (v2.2.0) or push to a stable tag like :prod, then docker pull before restart. ​

The redirect loop is fixed, the admin CSRF issue led to better HTTPS/CSRF config, and next up is wiring the contact form and DB dump command properly in production. Debugging didn’t just fix a bug; it forced a more disciplined deployment story.