SadServers
  • Scenarios
  • Labs
    All Labs Linux & Bash Web Servers Databases Data Processing Docker Kubernetes CI/CD Infrastructure as Code Tooling / Applications
  • Dashboard
  • Solutions
    For Individuals For Businesses
  • Ranking
  • Newsletter
  • Documentation
    FAQ Support Pro Accounts Pro+ Accounts Business Accounts Gift API CLI/TUI Privacy Troubleshooting Interviews
  • Blog
  • Pricing
  • Gift
    Gift Purchase Gift Redeem
  • About
Log In - Sign Up
  1. Labs
  2. Gunicorn
  3. Guide

Guide

Concepts and learning path

Troubleshooting

Failure modes and fixes

Cheatsheet

Commands to keep handy

Gunicorn guide

What Gunicorn does in production

Gunicorn runs Python web applications that speak the WSGI protocol. It does not serve static files or terminate TLS in most setups — nginx or another reverse proxy handles that and forwards requests to Gunicorn over HTTP or a Unix socket. A master process manages worker processes that handle requests concurrently.

How a request is handled

In a typical production stack:

  1. Reverse proxy — nginx/Apache receives the client connection on port 80/443
  2. Forward — proxy passes the request to Gunicorn via proxy_pass or a Unix socket
  3. Master accepts — Gunicorn master receives the connection and hands it to a free worker
  4. WSGI call — the worker invokes your application callable (module:app)
  5. Response — the app returns an iterable response; Gunicorn streams it back to the proxy

The application entry point is specified as myproject.wsgi:application (Django) or app:app (Flask) — module path plus callable name.

Workers and concurrency

  • workers — number of worker processes (rule of thumb: 2 × CPU + 1 for sync workers)
  • worker_class — sync (default), gevent, gthread for async/threaded workloads
  • threads — per-worker threads when using gthread
  • timeout — kill workers silent longer than this (default 30s)
  • max_requests — restart workers after N requests (memory leak mitigation)

Binding and deployment

Gunicorn binds to an address workers listen on:

  • TCP — --bind 127.0.0.1:8000 (localhost only; proxy connects here)
  • Unix socket — --bind unix:/run/gunicorn.sock (lower overhead; proxy uses proxy_pass http://unix:...)

Production deployments usually run Gunicorn under systemd with a unit file, or historically under supervisord. Config can live in gunicorn.conf.py or command-line flags.

Key settings to know

  • --chdir — working directory before loading the app
  • --user / --group — drop privileges after binding
  • --access-logfile / --error-logfile — log destinations (- for stdout)
  • --reload — dev only; auto-restart on code changes
  • graceful-timeout — time to finish in-flight requests on reload/shutdown

Learning resources

  • Gunicorn documentation — docs.gunicorn.org (official docs)
  • Settings — docs.gunicorn.org/settings (all configuration options)
  • Deploying Gunicorn — docs.gunicorn.org/deploy (production deployment guide)
  • Django deployment — docs.djangoproject.com — Gunicorn (Django + Gunicorn setup)

Practice scenarios

Hands-on Gunicorn scenarios on live Linux VMs: gunicorn

Troubleshooting →
SadServersSadServers

Real-world Linux and DevOps scenarios for hands-on learning and technical assessment.

Uptime Robot ratio (30 days)
Product
  • Scenarios
  • For Individuals
  • For Businesses
  • Pricing
Resources
  • FAQ
  • Blog
  • Newsletter
Company
  • About Us
  • Support
  • Privacy Policy
  • Terms of Service
  • Contact
Connect With Us
info@sadservers.com

Made in Canada 🇨🇦
Updated: 2026-06-13 16:06 UTC – 2d2950a