My Favorite Python Servers To Deploy Into Production
By: Emmett Boudreau
Tags: Programming, Deployment, Python, Data Science, DevOps

Gunicorn3

Gunicorn3 is the “ classic” and industry-standard Python production server. Compared to its competitors, the biggest thing that shapes Gunicorn as a separate entity is its ability to manage workers. It is also incredibly light on resources, and that in tandem with worker management means that you can set the priority of certain endpoints and retain performance on your servers for where it is needed most!

Another significant advantage to using Gunicorn is that it is the only WSGI web-server for Python that is compatible with almost everything. Given that it is typically seen as the standard for Python deployment in production, packages often lean on it during development, and as a result, are entirely compatible at launch. This is the typical server that you might use when working with both Flask and Django, which are easily the two most popular web-frameworks used in Python.

The final advantage of using Gunicorn is that it is by nature fairly quick. A lot of what Gunicorn holds is simplicity — which isn’t a bad thing. This means that it can typically be implemented very easily and still run incredibly fast. It is also primarily written in the C programming language, meaning it is likely on top of any other server written in pure Python in terms of speed.

Another advantage to Gunicorn is that I already have a tutorial on how to deploy Flask using it along with NGINX:

Waitress

Waitress is another great option for those who seek a truly light experience with their Python servers. One significant difference, and maybe advantage that it might have to Gunicorn is the ability to run on Windows as well as UNIX, whereas Gunicorn can only be used on UNIX-like operating systems. While this might be an advantage to those looking to deploy on Windows, I also do not remember the last time I saw a Windows server, so this could be great if it pertains to you, but might not be an advantage to most end users.

Waitress runs on CPython and has quote

“ Very acceptable performance”

I have not tested this, though that might make for some interesting observations in the future — so I would have to take their word for it. While I suspect the performance is pretty decent, I also imagine that Gunicorn out-performs it solely based on their use of C as the primary driving force behind the serving of Python code.

The last important thing I would like to note about Waitress is that it is free from dependencies that are not in the standard library. This circles back to the idea of keeping things incredibly lightweight. If you’re looking for a server that is purely Pythonic, lightweight, and doesn’t require any dependencies to run, then this might be the one for you!

GEvent

GEvent is another great web-server, but it is a pretty large leap away from something like Gunicorn or Waitress. While those libraries are focused primarily on being light-weight, simple, and fast, GEvent focuses more on the segmentation of sub-processes, also called coroutines, that can be stopped and resumed at a moments notice. This provides a significant boost to speed while retaining a lot of the features that some might desire.

One great thing that GEvent prominently features is SSL support and cooperative sockets. This makes it a lot easier to have multiple inbound connections work together to achieve the same goal, thus balancing the load across many connections rather than just one. SSL support is always a great thing to have, as well!

To solve the issue of potential incompatibilities with certain libraries, GEvent uses a system they call “ Monkey Patching.” It actually works surprisingly well, and is in fact rather impressive and can easily be automated. On top of that, it features easy support for thread-pools. While a bit bulkier than some of its counterparts, for a lot of full-stack applications it could be the best choice currently available.

uWSGI

The final option on this list is a C library called uWSGI. Like Gunicorn, uWSGI has a high-priority focus on CPU-usage. This in turn makes it fantastic for use with many different endpoints or applications that might be working in tandem. However, this is not to say that the primary usage for uWSGI will always be end-points, as there are a lot of features included that could make it suitable for fullstack, as well.

Firstly, uWSGI includes request plugins. This allows for actual extensibility of the server itself, making it more applicable to most solutions rather than only a few.

Additionally, uWSGI has an enormous focus on process control. Processes can quite easily be managed and are incredibly easy to control. Furthermore, you have access to the more low-level options not typically seen in competing libraries.

With all of the extensibility and versatility of uWSGI, however, it does come with some drawbacks. I found that it was much more difficult to use than something like Gunicorn or even GEvent. While I must confess, I only started to use it quite recently, it seemed to have a steep learning curve and a lot larger barrier of entry than any of the others on this list.

Final Thoughts

The web-server that is going to be deployed alongside your model or full-stack application is a very important thing to consider. Whether your application is light-weight, requires authentication, or is just a simple endpoint is all going to factor in to the decision on which server is the most optimal for your specific case. For me personally, I usually go with Gunicorn3. This is partially because it partners so well with Flask and NGINX, but also contributed to by its lightweight nature, which is something I look for in most of my web-development with Python endeavors. This is of course because most of my web-deployment is in the specific use case of endpoints. However, I have deployed some great web-applications with GEvent as well and it has worked quite well in those circumstances. Typically I would use Gunicorn for something like and endpoint, and use GEvent for a full-stack application. Regardless of which option fits the bill for your use-case, it is fortunate that there are different options for most deployment scenarios, and that makes it a lot more fun to talk about!