Ask HN: Host multiple flask and django apps on single server | Hacker News Reader

Ask HN: Host multiple flask and django apps on single server

5 pointsgingerjoos6 comments

What would be the best way to host multiple flask and django apps on a single server? From reading around it seems to better to use nginx and/or gunicorn, but I can't decide between nginx alone OR nginx + gunicorn. Should I consider Tornado? I don't really plan to have real-time stuff in my apps.

I'm using an EC2 micro instance (Ubuntu Precise)

View on HN

In my experience using nginx + gunicorn will help here is why: gunicorn create child processes for your server. This way you can have 3-4 process all working towards serving your web-application. Nginx helps for serving static files and reverse poxing to either flask / django process. You should also consider using something like supervisord. Supervisord will make sure you're processes are restarted if they crash for some reason.

Thanks, iamsidd2k7. That was helpful.

I have more experience with Nginx + Gunicorn, but I can tell you that it's pretty painless. "manage.py run_gunicorn" to get started, and you can assign it an arbitrary port and number of worker nodes depending on how many users you expect. Supervisor will obviously be needed to keep it up and running, but I've got dev instances that are fairly heavily trafficked I'm not running supervisor with, and I've yet to see Gunicorn crash, where I used to see Flup crash constantly.

In addition to what's already been mentioned, you'll definitely want to be using virtualenv for portability. Being able to maintain different libraries for different apps is essential, and virtualenv does a great job of keeping things isolated.

Thanks, bmelton. Decided to go with nginx + gunicorn. Was a little hesitant to use virtualenv, will go ahead and use it based on your recommendation. Thanks again! :)

It took me awhile to get used to it, but there's really no reason not to use virtualenv.

The more you use it, the more you have to use it. I had two projects with different authentication mechanisms that were unfortunately named the same thing. I accidentally deployed one without virtualenv and spent the next whole day figuring out what happened.

Virtualenv is a life-saver, and it's so easy to do that you might as well just always do it everywhere.

Just hit a similar situation at work and realised why I had to use it. Had a django app called taxonomy in a project, couldn't use the same name in another django project. Now I definitely have to use it!

Reply on news.ycombinator.com