I recently had some hair-raising adventures in the land of website deployment. I’ve been completely rebuilding my website with a Django backend because I love Python. (This blog will eventually be hosted there, although WordPress does excel at the blog thing, so I might just get crazy and integrate Django AND WordPress. But I digress.) I had everything working all fine and dandy on my local computer and was ready to deploy my almost-identical-but-now-Django-backed placeholder site. I’ve long had Apache serving a few VirtualHosts and handling the SSL certificates on my personal DigitalOcean droplet, so my choice of web server was made for me. At least all that domain config stuff was done, so it would be a cinch to get Django up and running in place of my static site, I thought.
I thought wrong.
It started off so well. I installed python and PostgreSQL on my server and configured my production settings file to match (and to pull in the passwords from a separate ini file on the server and out of the git tracking). I set up a bare repo and some git hooks to make pushing to production easy. (I know I should also set up a separate staging subdomain for testing, but I’ve been in a hurry to get something real up there since I’m starting the ol’ job hunt.) Everything seemed to be ready to push so I turned to the Apache config.
This is where my troubles began. I had been running Django’s testing server locally, but the docs were very clear that this testing server should not be used in production. They did not go into details as to why other than “security and scaling,” but I took their word for it. That’s okay, I thought; I have Apache set up already anyway. The docs also kept talking about this “WSGI” thing, but when I had tried to figure out how to configure that, it had mostly just confused me, and well, it was working on my machine.