Gunicorn for production serving in Flask - Step-by-Step Execution

Concept Flow - Gunicorn for production serving

Write Flask app

↓

Install Gunicorn

↓

Run Gunicorn with app

↓

Gunicorn starts workers

↓

Workers listen for requests

↓

Requests received -> handled by workers

↓

Responses sent back to clients

↓

Monitor and restart workers if needed

This flow shows how you write a Flask app, then use Gunicorn to run it in production by starting worker processes that handle incoming requests and send responses.

Execution Sample

Flask

from flask import Flask
app = Flask(__name__)

@app.route('/')
def home():
    return 'Hello, World!'

# Run with: gunicorn app:app

A simple Flask app that returns 'Hello, World!' at the home page, served by Gunicorn workers in production.

Execution Table

Step	Action	Gunicorn Process	Worker Process	Result
1	Start Gunicorn with 'gunicorn app:app'	Master process starts	No workers yet	Gunicorn master ready
2	Gunicorn spawns worker processes	Master manages workers	Workers start and load Flask app	Workers ready to accept requests
3	Client sends HTTP request	Master routes request	Worker receives request	Worker begins processing
4	Worker calls Flask app route function	Master waits	Flask app returns 'Hello, World!'	Response generated
5	Worker sends HTTP response	Master waits	Response sent to client	Client receives 'Hello, World!'
6	Worker waits for next request	Master monitors workers	Idle, ready for next request	System stable
7	If worker crashes	Master detects failure	Worker restarts	Service continues without downtime

💡 Gunicorn master and workers run continuously to serve requests until stopped.

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 5	Final
Master Process	Not running	Running, managing workers	Running	Running	Running	Running
Worker Processes	None	Started, loaded app	Received request	Processed request	Sent response	Idle, waiting
Request	None	None	Received by worker	Being processed	Response sent	None
Response	None	None	None	Generated	Sent to client	None

Key Moments - 3 Insights

Why does Gunicorn start multiple worker processes instead of just one?

Gunicorn starts multiple workers to handle many requests at the same time, improving performance and reliability. See execution_table step 2 where workers start and load the app.

What happens if a worker process crashes during request handling?

The master process detects the crash and restarts the worker automatically, so the service keeps running without downtime. This is shown in execution_table step 7.

Why don't we run the Flask app directly in production?

Flask's built-in server is for development only and can't handle many users or restart workers. Gunicorn manages multiple workers and is designed for production, as shown in the concept flow.

Visual Quiz - 3 Questions

Look at the execution_table, what is the state of worker processes after step 2?

A Workers are idle and waiting for requests

B Workers have crashed

C Workers are started and have loaded the Flask app

D Workers have sent responses to clients

💡 Hint

Check the 'Worker Process' column in execution_table at step 2

At which step does the worker process send the HTTP response back to the client?

A Step 5

B Step 4

C Step 3

D Step 6

💡 Hint

Look for 'Response sent to client' in the 'Result' column of execution_table

If the master process stops managing workers, what will happen according to the flow?

A Workers will continue handling requests normally

B Workers will crash and not restart

C Workers will become master processes

D Nothing changes, system runs as usual

💡 Hint

Refer to execution_table step 7 about master detecting worker failure and restarting

Concept Snapshot

Gunicorn runs Flask apps in production by starting a master process and multiple worker processes.
Workers handle incoming HTTP requests concurrently.
Master monitors workers and restarts them if they crash.
Run with: gunicorn app:app
This setup improves performance and reliability over Flask's built-in server.

Full Transcript

This visual execution shows how Gunicorn serves a Flask app in production. First, you write a Flask app with routes. Then you install Gunicorn and run it with your app. Gunicorn starts a master process that manages several worker processes. Each worker loads the Flask app and listens for HTTP requests. When a client sends a request, the master routes it to a worker. The worker calls the Flask route function, generates a response, and sends it back to the client. Workers stay ready for new requests. If a worker crashes, the master detects this and restarts it automatically. This setup allows your Flask app to handle many users reliably and efficiently in production.

Practice

1. What is the main purpose of using Gunicorn with a Flask application in production?

easy

A. To automatically generate Flask routes based on database models

B. To provide a graphical user interface for Flask applications

C. To efficiently handle multiple user requests by running the Flask app with multiple workers

D. To replace Flask's built-in development server with a simpler one

Solution

1. Step 1: Understand Flask's built-in server limitations

   Flask's built-in server is single-threaded and not suitable for handling many users in production.

2. Step 2: Role of Gunicorn in production

   Gunicorn runs multiple worker processes to handle many requests efficiently in production environments.

3. Final Answer:

   To efficiently handle multiple user requests by running the Flask app with multiple workers -> Option C

4. Quick Check:

   Gunicorn improves concurrency = A [OK]

Hint: Gunicorn runs multiple workers to handle many users [OK]

Common Mistakes:

• Thinking Gunicorn provides a GUI
• Believing Gunicorn auto-generates routes
• Assuming Gunicorn is a simpler server than Flask's

2. Which of the following is the correct command to start a Flask app named app inside a module called myapp using Gunicorn?

easy

A. gunicorn myapp:app

B. gunicorn myapp.app

C. gunicorn app.myapp

D. gunicorn app:myapp

Solution

1. Step 1: Understand Gunicorn command syntax

   The syntax is gunicorn module:app, where module is the Python file or package and app is the Flask app object.

2. Step 2: Apply syntax to given names

   Given the module is myapp and the app object is app, the correct command is gunicorn myapp:app.

3. Final Answer:

   gunicorn myapp:app -> Option A

4. Quick Check:

   Use colon between module and app = B [OK]

Hint: Use colon between module and app name in command [OK]

Common Mistakes:

• Using dot instead of colon
• Swapping module and app names
• Omitting the app object name

3. Given the command gunicorn -w 3 -b 0.0.0.0:8000 myapp:app, what will happen when you run it?

medium

A. Gunicorn will start 3 worker processes and listen on all network interfaces at port 8000

B. Gunicorn will start 1 worker and listen only on localhost at port 8000

C. Gunicorn will start 3 workers but listen only on localhost at default port 5000

D. Gunicorn will fail because the binding address is invalid

Solution

1. Step 1: Analyze the command options

   The -w 3 option sets 3 workers. The -b 0.0.0.0:8000 binds the server to all interfaces on port 8000.

2. Step 2: Understand the effect of binding and workers

   Binding to 0.0.0.0 means accessible from any network interface, and 3 workers allow handling multiple requests concurrently.

3. Final Answer:

   Gunicorn will start 3 worker processes and listen on all network interfaces at port 8000 -> Option A

4. Quick Check:

   -w sets workers, -b sets bind address = A [OK]

Hint: -w sets workers, -b sets bind address and port [OK]

Common Mistakes:

• Assuming default port 5000 is used
• Thinking 0.0.0.0 is invalid
• Confusing workers with threads

4. You tried to run gunicorn myapp.app but got an error saying module not found. What is the likely cause?

medium

A. The Flask app must be run with flask run only

B. You used a dot instead of a colon between module and app

C. You need to run Gunicorn inside a virtual environment

D. Gunicorn requires the app to be named 'application' not 'app'

Solution

1. Step 1: Check Gunicorn command syntax

   Gunicorn expects module:app with a colon, not a dot.

2. Step 2: Identify error cause

   Using a dot like myapp.app makes Gunicorn look for a module named myapp.app, causing module not found error.

3. Final Answer:

   You used a dot instead of a colon between module and app -> Option B

4. Quick Check:

   Use colon, not dot, in Gunicorn command [OK]

Hint: Use colon, not dot, between module and app in command [OK]

Common Mistakes:

• Using dot instead of colon
• Assuming app name must be 'application'
• Thinking virtual environment causes this error

5. You want to deploy a Flask app with Gunicorn on a server with 4 CPU cores. Which Gunicorn configuration is best to maximize performance without overloading the server?

hard

A. Run Gunicorn with 8 workers and bind to 0.0.0.0:80

B. Run Gunicorn with 1 worker and bind to 0.0.0.0:5000

C. Run Gunicorn with 2 workers and bind to 0.0.0.0:8080

D. Run Gunicorn with 4 workers and bind to 127.0.0.1:8000 behind a reverse proxy

Solution

1. Step 1: Match workers to CPU cores

   Best practice is to run Gunicorn with number of workers equal to CPU cores (4 here) for optimal concurrency.

2. Step 2: Bind to localhost and use reverse proxy

   Binding to 127.0.0.1:8000 and placing a reverse proxy (like Nginx) in front is a common production setup for security and performance.

3. Final Answer:

   Run Gunicorn with 4 workers and bind to 127.0.0.1:8000 behind a reverse proxy -> Option D

4. Quick Check:

   Workers = CPU cores, bind localhost + proxy = C [OK]

Hint: Match workers to CPU cores; use localhost bind with reverse proxy [OK]

Common Mistakes:

• Using too many workers causing overload
• Binding directly to port 80 without proxy
• Using too few workers limiting performance