Question

Problem running multiple workers with gunicorn/nginx to deploy python/flask web app

Posted on March 24, 2025
Flask Nginx DigitalOcean Droplets
Asked by Andrew J Montanus

My app works perfectly with 1 worker, for example:

gunicorn -w 1 -b 127.0.0.1:8000

works perfectly. However,

gunicorn -w 2 -b 127.0.0.1:8000

Does not - the site will load and I can log in. Upon login there is a request to the database for some info. I know this works because some of it writes to sessionStorage. But then the app becomes unresponsive. Also, I can see the route to the root and login routes in the nginx log, but nothing flows to gunicorn log.

Steps Taken: gunicorn systemd file in good shape, firewall is not a problem, nginx configuration is good. I thought my use of session variables in client cookies might be the problem so I switched to Flask-Session and using redis to make session variables available to multiple workers.

I welcome any suggestions you have.

Submit an answer

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!

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.

alexdo

Site Moderator

• March 24, 2025

Accepted Answer

Heya, @andrewjmontanus

If you’re behind a reverse proxy or load balancer that balances between workers (rare with just Gunicorn + NGINX), you may need to ensure “sticky” session behavior or that session state is truly centralized (e.g. Redis).

Hope that this helps!

Andrew J Montanus • March 26, 2025

Thanks for replies. I figured out the problem - I had a decorator function @login_required that I had imported from a helper module that was being applied to certain routes. This decorator function had some prior code in it that was using a global variable. I removed these decorators and handled the login_required in those routes using the session data now stored in redis. That fixed the problem and the app now works great. --> So if you have this problem and all other methods to fix it fail, check any custom decorators that use or create variables that might not be consistently available to all gunicorn workers.