Beyond WSGI: Nginx Integration, Workers & Emperor Mode

A Broader Scope Than Gunicorn

uWSGI implements WSGI (so it serves Flask/Django just like Gunicorn) but supports a much broader set of protocols, languages, and deployment scenarios — its own native "uwsgi" protocol, plugins for non-Python languages, multiple config formats (INI, XML, YAML, JSON). More capability comes with more configuration surface area and a steeper learning curve than Gunicorn's simpler defaults.

Nginx + uWSGI: the Native Protocol

# nginx.conf
location / {
    include uwsgi_params;
    uwsgi_pass unix:/tmp/myapp.sock;
}

The classic pattern: Nginx handles TLS termination and static files, then proxies to uWSGI via its native binary protocol (a built-in Nginx module) rather than plain HTTP — potentially more efficient for that specific internal connection than a generic HTTP proxy pass.

Workers, Threads & Harakiri

[uwsgi]
module = myapp:app
processes = 4
threads = 2
harakiri = 30

processes × threads gives fine-grained control over concurrency. harakiri sets a max time per request — a hung worker exceeding it is automatically killed and restarted, uWSGI's equivalent of Gunicorn's --timeout.

Emperor & Vassals

Emperor mode lets a master process monitor a directory of config files and automatically spawn/manage a separate uWSGI process (a vassal) per application — simplifying hosting many independent Python apps on one shared server without manual per-app setup.