Gunicorn

Gunicorn (‘Green Unicorn’) is a Python WSGI and ASGI HTTP server for UNIX, built on a pre-fork worker model ported from Ruby’s Unicorn project. A master arbiter process supervises a pool of worker processes, restarting them when they die and reloading your application on signal, so a single command turns any WSGI or ASGI app into a resilient, production-ready service.

Broadly compatible with Django, Flask, Pyramid, FastAPI, Starlette, and any framework speaking the WSGI or ASGI protocol, Gunicorn is simply implemented, light on server resources, and fast. It ships several interchangeable worker types — synchronous, threaded, gevent, tornado, and ASGI — so you can match the concurrency model to your workload without changing application code.

What You Get

• A single gunicorn command that boots and supervises a pool of worker processes for any WSGI or ASGI application.
• Interchangeable worker types — sync, gthread, gevent, tornado, and asgi — selectable via --worker-class to fit your concurrency needs.
• A master arbiter that keeps workers alive, restarts crashed processes, and supports zero-downtime reloads via SIGHUP and USR2.
• Extensive configuration through CLI flags, a Python config file, or environment variables, with server hooks for lifecycle events.
• Broad framework compatibility with Django, Flask, Pyramid, FastAPI, Starlette, and Paste-compatible deployments.

Common Use Cases

• Serving a Django or Flask application in production behind an nginx reverse proxy.
• Running FastAPI or Starlette ASGI apps with the dedicated ASGI worker class.
• Scaling request handling across CPU cores by tuning the number of pre-forked workers.
• Handling large numbers of concurrent, I/O-bound connections with gevent or threaded workers.

Under The Hood

Architecture Gunicorn implements a classic pre-fork model centered on the Arbiter class in gunicorn/arbiter.py, a master process that owns the listening sockets, spawns a configurable pool of workers, and keeps them alive by trapping UNIX signals — SIGHUP for reload, USR2 for binary upgrades, TTIN/TTOU to scale workers up and down. Your application is wrapped by a BaseApplication in gunicorn/app/base.py (with WSGIApplication as the CLI entry point), which loads your callable and hands it to workers; each worker in gunicorn/workers/ runs its own accept-and-serve loop, from the blocking SyncWorker in sync.py to threaded, gevent, tornado, and ASGI variants that subclass a shared base.

Tech Stack The project is pure Python (99% of the codebase), targets Python 3.10+, and is remarkably dependency-light — the only hard runtime requirement is packaging. Optional extras pull in gevent, tornado, or h2 for alternative worker classes and HTTP/2, and setproctitle for nicer process names. It builds with setuptools via pyproject.toml, exposes gunicorn and gunicornc console scripts, and integrates as a paste.server_runner entry point.

Code Quality The repository is mature and well-tested, with roughly 280 test modules under tests/ covering config parsing, HTTP handling, worker behavior, and the arbiter, driven by pytest and tox across multiple Python versions. A .pylintrc, structured config.py with a declarative KNOWN_SETTINGS registry, and clear module boundaries reflect a disciplined, long-maintained codebase. Every source file carries the MIT license header and the code favors explicit, readable control flow over cleverness.

API Design Developer experience is a core strength: a single gunicorn myapp:app command gets an app into production, and nearly every behavior is tunable through consistently named CLI flags, a Python config file, or environment variables. Settings are self-documenting via the config.py metadata, worker models swap in with a single --worker-class flag, and lifecycle hooks let operators inject custom logic, backed by a full documentation site at gunicorn.org and an examples/ directory of ready-to-run configurations.