If you are like me, you visit the Python Standard Library Reference all the time. You already know there’s a “datetime” module, a “random” module, an “os.path” module, and so on, so how do you quickly go there to read the reference? Here’s what I do.
Do you know that in Heroku you can enter a single command and have your Django project deployed for you? If there are services that have commoditized deployment, why should you care about nginx, Apache, PostgreSQL, Gunicorn, systemd, and all that, and don’t you spend your time and grey matter on something more useful?
I’ve noticed that many people attempting to deploy Django have trouble understanding how a single web server installation can serve many domains. One reason is that words matter. What Apache calls a “virtual host” is exactly what nginx calls a “server” and what HTTP calls a “host”. It is neither a host (let alone a virtual one) nor a server; it’s a domain. Let’s clear this up.
Digital Ocean advertises its services as “cloud computing”, and sometimes refers to its virtual servers, its “droplets” that is, as “cloud servers”. Reader Chris Pantazis asked me if this means it has less downtime than a provider that doesn’t advertise them in this way. The answer is that “cloud” doesn’t mean anything at all. In this post I explain how virtual server providers minimize downtime.
You deploy with nginx and Gunicorn and your site uses HTTPS. If Django occasionally returns HttpResponseRedirect or similar, you may find that the redirect sends you back to HTTP. Here’s how to fix it.
You’ve set your
EMAIL_* settings correctly, and when you try to send emails with
django.core.mail.sendmail() it works. However, Django still does not send you internal server errors. Why?