Consider gunicorn

[stets]

No reason to prematurely optimize just yet, but gunicorn should be considered if/when the site starts to hit any kind of scale

The default server is mostly meant for debug purposes

https://vsupalov.com/flask-web-server-in-production/

https://stackoverflow.com/questions/20843486/what-are-the-limitations-of-the-flask-built-in-web-server

[cc-d]

Absolutely.

Originally I was using uwsgi, but for whatever reason, it would start throwing permission errors for the socket shared with nginx randomly. It absolutely boggled my mind, and looking at the internet I discovered that this was a particularly common bug. Something like 20% of the requests would return 502s... which is a really weird pattern for that type of error lol.

I switched back to werkzeug just to have something that wouldn't error out. Surprisingly, it handled the HN load with no problems whatsoever.

While reading into the possible uwsgi replacements, gunicorn seemed like the best option. If/when werkzkreug starts to approach it's limits, gunicorn is the next choice.

[nomorepanic]

I'd suggest gunicorn + meinheld

[cc-d]

Closing this for now just to help clear issues. If scale becomes relevant. I will re-open it.

[stets]

Re-opening because I just implemented this on a side-project of mine and it was super-simple.

apt-get install gunicorn3

gunicorn3 app:app --bind 0.0.0.0:443 --workers 4

You can then make it into a systemd service or just be ghetto and run it in screen/background/whatever

Let me know if you want some help with this @cc-d , not sure what current deployment looks like.

[cc-d]

Yep, works perfectly. I actually tested this today and the only difference I had to accommodate was a slightly different request.environ dict

I migrated from the old host to an entirely fresh VPS as well. Originally there were some strange issues with socket permission errors being thrown randomly, but I haven't observed any problems in the time this has been running.

Closing as everything works.