For your Supervisor deployment to actually be secure, you need to make a couple changes.<p>First, you should be using a separate root-owned virtualenv for Supervisor itself. If you use a virtualenv owned by another user, that user can effectively cause arbitrary command execution as root whenever Supervisor starts by modifying the virtualenv activation script.<p>Second, the Supervisor configuration file itself should also be root-owned and specified using the -c switch for 'supervisord'. A malicious user with access to the Supervisor config file can do all kinds of malicious things with that access alone, usually starting with disabling the privilege dropping and proceeding to overwriting arbitrary files as root. You should always specify the path to the config file as well, because otherwise Supervisor looks in the current working directory. That's harder to exploit, but it's better to be safe and have zero chance of a root-owned process reading a wrong (and possibly malicious) config file.<p>Fixing this stuff is probably beyond the scope of the article, but they're things you should consider if you plan on deploying Supervisor on production systems.
Note that it's "Deploy (Django on Nginx and Gunicorn over HTTPS)" and not "Deploy (Django on Nginx and Gunicorn) over HTTPS", which looked like quite some fun.