gunicorn
Run Python WSGI applications
TLDR
Run Python web app
Listen on port 8080 on localhost
Turn on live reload
Use 4 worker processes for handling requests
Use 4 worker threads for handling requests
Run app over HTTPS
SYNOPSIS
gunicorn [OPTIONS] APP_MODULE
PARAMETERS
-b BIND
The socket to bind. Format is host:port or unix:PATH.
-w INT
The number of worker processes for handling requests. More workers generally means higher throughput.
-k STRING
The worker type to use. Common choices include sync (default), gevent, eventlet, and tornado. Choosing the right worker type is essential for high concurrency.
-t INT
The timeout for pending requests.
--preload
Preload application code before the worker processes are forked. This reduces memory usage when copy-on-write is used.
--chdir DIR
Change directory before loading the application module.
--daemon
Daemonize the Gunicorn process. Run in the background.
--access-logfile FILE
The Access log file to write to.
--error-logfile FILE
The Error log file to write to.
--config FILE
The Config file to use.
APP_MODULE
The Python application module to load. Format is module:app or package.module:app.
DESCRIPTION
Gunicorn, or Green Unicorn, is a pre-fork WSGI server for serving Python web applications. It's designed to be simple to deploy, highly scalable, and compatible with a wide range of web frameworks. Gunicorn manages worker processes to handle incoming HTTP requests, allowing Python applications to efficiently serve multiple concurrent requests. It typically sits behind a reverse proxy like Nginx or Apache which handles static files, SSL termination and load balancing, while Gunicorn focuses on executing the Python application code.
Gunicorn excels in production environments where performance and reliability are crucial. It's a robust and widely used option for deploying web applications built with frameworks like Django, Flask, and Pyramid. Configuration options allow fine-tuning to optimize resource utilization and concurrency for specific application needs. The server is designed to handle various deployment scenarios, making it suitable for both small-scale and large-scale applications. Its simplicity and ease of use make it a popular choice among Python web developers.
CAVEATS
Gunicorn relies on WSGI. Therefore, your Python application must be WSGI compatible.
Gunicorn is a process manager. It does *not* serve static files. Use a reverse proxy like Nginx or Apache to handle static file serving efficiently.
WORKER TYPES
The choice of worker type significantly impacts concurrency and performance. sync is the default and suitable for simple applications. gevent and eventlet are asynchronous worker types that can handle more concurrent connections, but require patching the Python standard library and using compatible libraries.
tornado is also an asynchronous worker type, which requires the use of tornado web framework.
DEPLOYMENT STRATEGY
Gunicorn should typically be deployed behind a reverse proxy like Nginx or Apache. The reverse proxy handles static file serving, SSL termination, and load balancing, while Gunicorn focuses on serving the dynamic application code.
This separation of concerns leads to better performance and security.
HISTORY
Gunicorn was created to provide a robust and simple-to-use WSGI server for Python web applications. It grew in popularity alongside Python web frameworks like Django and Flask, becoming a standard choice for production deployments. It was created because existing WSGI servers had shortcomings in terms of ease of use and robustness. The primary goal was to create a server that could be easily configured and deployed in a variety of production environments.
The development was focused on ease of integration with existing Python Web frameworks and a simplified deployment process.