Post Date: August 16, 2018
Last Updated: September 22, 2026
Introduction
This guide explains how to configure multiple uWSGI applications behind Nginx, using uWSGI’s Emperor mode to manage several apps at once, each with its own Nginx server block.
The original version of this guide only showed a single app configured — this update adds a genuine second app example so the “multiple applications” part is actually demonstrated, along with the Emperor mechanism that makes running many apps this way possible in the first place.
Prerequisites
- Nginx and uWSGI installed
- One or more Python/Django applications ready to deploy
- Root or sudo access
Architecture
uWSGI’s Emperor mode is what makes “multiple applications” work cleanly:
- The Emperor process watches a specific directory (
/etc/uwsgi/vassals/) for.inifiles - Each
.inifile found there automatically becomes a running vassal — its own independent uWSGI worker process, with its own socket - Adding a new app is as simple as dropping a new
.inifile (or symlink) into that directory — no need to restart the Emperor itself - Nginx then routes incoming requests to the correct app’s socket based on the domain/server block that matched the request
This is also why the original guide’s directory structure matters: it’s not just a config location, it’s the mechanism Emperor uses to discover and manage every app automatically.
Steps
1. Create the First App’s uWSGI Vassal Config
Symlink the app’s .ini file into the vassals directory so Emperor picks it up:
cd /etc/uwsgi/vassals/ ln -s /var/www/app1/app1/demo.ini .
Contents of demo.ini:
[uwsgi] chdir = /var/www/app1/app1 module = app1.wsgi enable-threads = true master = true processes = 10 listen = 100 socket = /var/www/app1/app1/app1.sock chmod-socket = 660 vacuum = true max-requests = 1000
Note: The original used
chmod-socket = 666, which makes the socket world-writable — readable and writable by any user or process on the system.660(owner and group only) is safer, as long as the socket’s group matches the user Nginx runs as.
2. Create the Second App’s uWSGI Vassal Config
This is the part the original guide skipped — here’s a second, independent app configured the same way, to actually demonstrate “multiple”:
cd /etc/uwsgi/vassals/ ln -s /var/www/app2/app2/demo2.ini .
Contents of demo2.ini:
[uwsgi] chdir = /var/www/app2/app2 module = app2.wsgi enable-threads = true master = true processes = 5 listen = 100 socket = /var/www/app2/app2/app2.sock chmod-socket = 660 vacuum = true max-requests = 1000
Because Emperor watches the whole directory, this second app starts running automatically as soon as its .ini file is symlinked in — no separate command needed to “add” it.
3. Configure Nginx for the First App
File: /etc/nginx/conf.d/app1.conf
upstream app1 {
server unix:///var/www/app1/app1/app1.sock;
}
server {
listen 80;
server_name app1.yourdomain.com;
charset utf-8;
client_max_body_size 75M;
location /static {
alias /var/www/app1/app1/static;
}
location / {
uwsgi_pass app1;
include /etc/nginx/uwsgi_params;
}
}
4. Configure Nginx for the Second App
File: /etc/nginx/conf.d/app2.conf
upstream app2 {
server unix:///var/www/app2/app2/app2.sock;
}
server {
listen 80;
server_name app2.yourdomain.com;
charset utf-8;
client_max_body_size 75M;
location /static {
alias /var/www/app2/app2/static;
}
location / {
uwsgi_pass app2;
include /etc/nginx/uwsgi_params;
}
}
Note: Each app gets its own
upstreamblock andserver_name, so Nginx routes each domain to the correct app’s socket. This is the actual “multiple applications” pattern — two independent Nginx server blocks pointing at two independent uWSGI sockets.
5. Verify Nginx Configuration
nginx -t
You should see syntax is ok and test is successful.
6. Restart Nginx
systemctl restart nginx
7. Reload the uWSGI Apps
To reload a single app without restarting everything, touch its .ini file — Emperor detects the change and reloads just that vassal:
touch /etc/uwsgi/vassals/demo.ini
To restart the Emperor process itself (all apps):
systemctl restart uwsgi-emperor
Note: The original guide referenced a custom script (
/opt/scripts/uwsgi_restart.sh) with no explanation of what it actually does. If your server doesn’t have a systemd-managed Emperor service, check how uWSGI’s Emperor was originally started on your system before assuming either command above applies directly.
Conclusion
Running multiple uWSGI applications behind Nginx relies on Emperor mode automatically managing every .ini file placed in the vassals directory, paired with a separate Nginx server block per app pointing at each app’s own socket. Adding a third, fourth, or further app follows the exact same pattern — a new vassal .ini file, plus a new Nginx server block.
Frequently Asked Questions
Do I need to restart Emperor every time I add a new app? No — that’s the point of Emperor mode. It watches the vassals directory continuously, so a new .ini file symlinked in starts running automatically.
Why use separate socket files instead of one shared socket? Each app needs its own independent uWSGI process and socket so they don’t interfere with each other — sharing a socket between unrelated apps isn’t supported.
What if two apps need to share the same domain but different paths? Use a single Nginx server block with multiple location blocks, each with its own uwsgi_pass pointing at a different app’s upstream, instead of separate server_name entries.
Related Articles
How to setup SSL Certificate in Nginx on Ubuntu 20.04
How to install and configure PHP with Nginx on centos7
Talk to Our Technology Experts
Deploying multiple applications on a single server or need help with your Nginx/uWSGI setup? Our team can help with application deployment, server architecture, and ongoing infrastructure support.