The real strength of uwsgi is it's emperor mode [1].
On my servers I have one upstart job whose role is simply to start the emperor daemon and make sure /var/run/uwsgi permissions are correct for writing sock files.
Each django project deployed on the server has a uwsgi.ini file in it's etc folder. This ini file holds the config for that app only. It defines where the socket file is located, where the virtualenv is located and where the project.wsgi file is located.
It's simple because you can host multiple websites on a single server, but you uwsgi configuration is separated into 'system' and 'project', so your 'project' specific config can live in git and your 'system' config never has to change.
On my servers I have one upstart job whose role is simply to start the emperor daemon and make sure /var/run/uwsgi permissions are correct for writing sock files.
Each django project deployed on the server has a uwsgi.ini file in it's etc folder. This ini file holds the config for that app only. It defines where the socket file is located, where the virtualenv is located and where the project.wsgi file is located.
It's simple because you can host multiple websites on a single server, but you uwsgi configuration is separated into 'system' and 'project', so your 'project' specific config can live in git and your 'system' config never has to change.
Nginx is setup in a very similar way.
[1] http://uwsgi-docs.readthedocs.org/en/latest/Emperor.html