Question

How to deploy multiple Django apps (as subdomains) using nginx and Gunicorn

I have a new 18.04 Droplet running a Django website on nginx. I’d like to use this droplet to serve several websites at subdomains. I have successfully:

  1. Followed this excellent tutorial to set up my first website: https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu-18-04

  2. Configured nginx and DNS to serve (static) websites & subdomains on this server

  3. Set up a second Django app that I can run on port 8000, using Gunicorn as a console process

So where I’m hung up is what I add to the systemd configuration? I tried copy/pasting the [Service] block for my new site but when I try to restart gunicorn I get this error:

systemd[1]: gunicorn.service: Service has more than one ExecStart= setting, which is only allowed for Type=one

Should I create a second *.service file in /etc/systemd/system/? Is there some way to put multiple Django apps into one ExecStart directive? Each app runs in its own virtual environment.

Submit an answer
Answer a question...

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Ben • February 15, 2019
Accepted Answer

I believe you need to create multiple socket and service files.

  1. I created a separate *.service and *.socket file for each web app
  2. I changed the WorkingDirectory and ExecStart values in the *.service files appropriately

Then I was able to host multiple django projects, each one with a different domain.

From my surface understanding, the process goes something like this. Nginx listening on port 80 receives an HTTP request. This request includes a Host header, which includes myDomain.com. Nginx then looks through it’s sites-available configs for a site that accepts myDomain.com. If it finds one it will look at the appropriate location section in the config file. In my case this includes

proxy_pass http://unix:/run/[MySockFileName].sock;

Some kind of information is then pushed into the unix socket file, named [MySockFileName].sock, inside the /run directory. SystemD notices this and starts up gunicorn if it’s not running already. Gunicorn consumes the information in the socket and after that magically runs python and sends you a rendered web page.

If you find best practices on this for production please let me know.

axoplasm • February 16, 2019

Thank you so much BenSa! This got me on the right path. I’m not sure if this is “best practices” but it works.

It helps to walk through DO’s tutorial (linked above) but substitute a handle for the subdomain for gunicorn. So for a subdomain foobar.example.com:

File /etc/systemd/system/foobar.service:

[Unit]
Description=gunicorn daemon
Requires=foobar.socket
After=network.target


[Service]
User=myUserName
Group=www-data
WorkingDirectory=/home/myUserName/foobar
ExecStart=/home/myUserName/foobar/.env/bin/gunicorn \
    --access-logfile - \
    --workers 3 \
    --bind unix:/run/foobar.sock \
    foobar.wsgi:application

[Install]
WantedBy=multi-user.target

File /etc/systemd/system/foobar.socket:

[Unit]
Description=gunicorn socket

[Socket]
ListenStream=/run/foobar.sock

[Install]
WantedBy=sockets.target

File /etc/nginx/sites-available/foobar:

server {
    server_name foobar.example.com;

    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /home/myUserName/foobar;
    }
    location / {
        include proxy_params;
        proxy_pass http://unix:/run/foobar.sock;
    }
}

Make sure to symlink the nginx site file:

$ ln -s /etc/nginx/sites-available/foobar /etc/nginx/sites-enabled/foobar

And enable the socket for the subdomain:

$ systemctl start foobar.socket
$ systemctl enable foobar.socket

Each socket is its own service. So if I need to restart the foobar site (for example after updating views.py):

$ systemctl restart foobar

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.

Sign up now

jpablomayorga • March 16, 2021

Muchas gracias a todos por el aporte, me ha servido mucho!!