Host a Python Flask App on AWS EC2 with Gunicorn and Nginx

By Ravindra Bagale, trainer · LinkedIn · Last updated: 18 October 2026

1. Website or API

Why: a web page built for a laptop screen does not fit an Android phone, an iPhone and a tablet at the same time. Modern apps solve this by asking the server only for data.

What:

1. A website answers with a whole HTML page: layout, text and images together. The browser just shows it.
2. An API (Application Programming Interface) answers with data only. Each app, Android, iPhone or web, draws its own screen from that data.
3. The data usually travels as JSON: key: value pairs inside curly braces { }. Text values go in double quotes, numbers do not, and a comma separates the pairs.

Worked example: one reel in a short-video app. The app asks the server for the next reel and gets:

{
  "username": "ravi",
  "profile_pic": "https://.../ravi.jpg",
  "caption": "on the top",
  "video_url": "https://.../reel42.mp4",
  "likes": 50
}

1. The app shows username and profile_pic at the top of the screen.
2. It plays video_url in the middle.
3. It writes caption and the likes count below the video.

In the rest of this chapter you build a small API like this in Python and host it on EC2.

2. What hosting a Python app needs

Why: A Python app is a stack, not one program. Knowing the six pieces tells you what to install and, when the app is down, which piece to check.

What: six pieces, from the bottom up:

1. python3, the language itself. Python 2 is retired; Python 3 changed enough that the two use different commands, python2 and python3. Amazon Linux 2023 ships only python3.
2. pip, Python's package manager. It downloads libraries such as Flask.
3. A virtual environment (venv), a folder that holds one app's libraries, separate from every other app.
4. The app: app.py, written with Flask, plus requirements.txt that lists the libraries it needs.
5. gunicorn, the production app server. It is a WSGI server: it runs Python web apps such as Flask and Django. For async frameworks such as FastAPI you would use an ASGI server such as uvicorn.
6. nginx in front, on port 80, passing requests to gunicorn.

Package managers you will meet:

1. yum (or dnf) installs Linux packages on Amazon Linux: sudo yum install nginx -y.
2. pip installs Python libraries: pip install flask.
3. npm installs Node.js libraries, and composer installs PHP libraries.

Python comes preinstalled on most Linux systems and on macOS; on Windows you install it yourself.

3. Launch the server and check Python

Why: Everything below runs on this server. Checking the Python version first avoids installing libraries that need a newer Python.

How:

1. Launch an EC2 instance: Amazon Linux 2023, t2.micro or t3.micro, your key pair, an 8 GiB gp3 disk, and a security group that allows SSH (22) from My IP and HTTP (80) from anywhere.

2. Connect from your laptop:

   ssh -i mykey.pem ec2-user@PUBLIC_IP
   

3. Check Python and install pip:

   python3 -V
   sudo yum install python3-pip -y
   pip3 -V
   

4. python3 -V prints a version such as Python 3.9.x. Typing just python gives command not found, because the command is python3.

4. Create a virtual environment

Why: one server often runs several Python apps. App A may need Flask 3.1 and app B Django 4.2 with different versions of the same helper libraries. Installed together, they clash. The system Python is also used by the operating system and yum, so app libraries do not belong there.

What: a venv is a folder with its own python, its own pip and its own libraries. The venv module is built into python3; no extra package is needed.

How:

mkdir ~/pythonapp
cd ~/pythonapp
python3 -m venv myenv
ls
source myenv/bin/activate

1. ls now shows a folder called myenv.
2. After source, the prompt starts with (myenv). From now on python and pip mean the ones inside myenv.
3. deactivate leaves the venv.
4. Inside a venv, never use sudo pip or sudo python: sudo runs as root with root's PATH and skips the venv, so the libraries land in the system Python.
5. If pip install says Permission denied, the folder was created with sudo. Give it back to your user, then run pip install without sudo:

   sudo chown -R ec2-user:ec2-user ~/pythonapp
   

5. Write requirements.txt and app.py

Why: requirements.txt lets anyone install exactly the libraries the app needs with one command. app.py is the app itself.

How: inside ~/pythonapp, with the venv active:

1. nano requirements.txt and type two lines:

   Flask
   gunicorn
   

2. nano app.py and type:

   from flask import Flask
   
   app = Flask(__name__)
   
   @app.route('/')
   def home():
       return 'Hello from Python on EC2'
   
   @app.route('/hi')
   def hi():
       return 'Hi! This is the second page.'
   
   if __name__ == '__main__':
       app.run(host='0.0.0.0', port=5000)
   

What each part does:

1. app = Flask(__name__) creates the Flask app object, named app.
2. @app.route('/') connects a URL path to the function below it. / is the bare address with no page name; /hi is http://ADDRESS/hi.
3. Python uses indentation to group code. The return lines must be indented the same way, with spaces; one extra space gives an IndentationError.
4. host='0.0.0.0' accepts requests arriving on any of the server's addresses; port=5000 is the port the test server listens on.

6. Install the libraries and test with the Flask server

Why: Running the app with Flask's own server first proves the code and libraries work, before gunicorn and nginx add more places for something to go wrong.

How:

1. Try to run the app before installing anything:

   python3 app.py
   

   It fails with ModuleNotFoundError: No module named 'flask'. The same error appears whenever the venv is not active.

2. Install the libraries into the venv, and record the exact versions:

   pip install -r requirements.txt
   pip freeze > requirements.txt
   

   pip freeze writes lines such as Flask==3.1.x, so the next server gets the same versions.

3. Start the test server:

   python3 app.py
   

   It prints Running on http://127.0.0.1:5000 and a warning: "This is a development server. Do not use it in a production deployment." The Flask server is for testing only.

4. In the EC2 console, add a temporary inbound rule to the security group: Custom TCP, port 5000, source 0.0.0.0/0.

5. Open http://PUBLIC_IP:5000 and http://PUBLIC_IP:5000/hi in the browser. Plain http://PUBLIC_IP does not work yet, because nothing serves port 80.
6. The terminal is now busy: the server runs in the foreground. Press Ctrl+C and it stops, and the site goes down with it. Closing the SSH window stops it too.

7. Run the app in the background with gunicorn

Why: a live app must keep running after you log out, and must handle many requests at once. gunicorn does both.

How: with the venv active, inside ~/pythonapp:

gunicorn --bind 0.0.0.0:5000 --workers 2 --daemon app:app
curl http://127.0.0.1:5000
curl http://127.0.0.1:5000/hi

1. app:app means "the file app.py, the Flask object called app inside it".
2. --bind sets the address and port. Without it gunicorn listens on 127.0.0.1:8000, its default.
3. --workers 2 starts two worker processes under one master process.
4. --daemon runs it in the background: the prompt comes back, and the app keeps running after you log out.
5. curl tests the app from the server itself, without a browser.
6. If SSH disconnects, the venv is no longer active in the new session. Run cd ~/pythonapp and source myenv/bin/activate again before any python, pip or gunicorn command.

8. Put nginx in front as the reverse proxy

Why: visitors should use plain http://ADDRESS on port 80 (and later 443 for HTTPS), not port 5000. nginx is built to face the internet: it handles thousands of connections, serves static files, and later terminates HTTPS.

What:

1. nginx is a reverse proxy: like a front desk, it receives every request and passes app requests to gunicorn, the back office, with proxy_pass. The visitor only ever talks to nginx.
2. nginx runs a few worker processes; worker_processes auto starts one per CPU. Each worker runs an event loop that juggles many connections at once, up to worker_connections, which Amazon Linux's nginx.conf sets to 1024.

How:

1. Install and start nginx:

   sudo yum install nginx -y
   sudo service nginx start
   

2. Open the config with sudo nano /etc/nginx/nginx.conf. Inside the existing server { ... } block, after the root line, add:

   location / {
       proxy_pass http://127.0.0.1:5000;
       proxy_set_header Host $host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto $scheme;
   }
   

3. Every directive ends with ; and every { needs its }. Check the file, then reload:

   sudo nginx -t
   sudo service nginx reload
   

4. nginx -t must say syntax is ok and test is successful. If it shows an error, nginx keeps running with the old config; fix the line it names and test again.

5. Open http://PUBLIC_IP without a port: the Flask app answers through nginx.

The proxy_set_header lines pass the real visitor address and the original host name on to the app; without them every request seems to come from nginx itself.

Close port 5000: now that nginx is in front, nobody outside needs port 5000.

1. Stop the test gunicorn (section 9 shows how to find its PID) and start it bound to the server only:

   gunicorn --bind 127.0.0.1:5000 --workers 2 --daemon app:app
   

2. Delete the port 5000 rule from the security group. Keep 22 from My IP, 80, and 443 if you add HTTPS.

3. http://PUBLIC_IP still works; http://PUBLIC_IP:5000 no longer answers.

9. Add an API route and reload gunicorn

Why: an API is just a route that returns data. Adding one shows the most common surprise with a background server: new code does nothing until the server reloads it.

How:

1. Add a route to app.py, above the if __name__ line:

   @app.route('/getusers')
   def get_users():
       return {"username": "ravi", "likes": 50, "caption": "on the top"}
   

2. Flask turns a returned dictionary into JSON and sets the application/json content type.

3. Open http://PUBLIC_IP/getusers: it shows 404 Not Found. gunicorn loaded app.py when its workers started, and it is still running the old code.

4. Find the gunicorn processes:

   ps aux | grep gunicorn
   ps -ef | grep gunicorn
   

5. ps aux lists every process: a all users, u user-oriented columns, x processes without a terminal too. ps -ef adds the parent PID column: the master is the gunicorn process whose parent is not another gunicorn; the workers are its children.

6. Reload the code gracefully, using the master's PID:

   kill -HUP 4101
   

7. HUP makes the master start new workers with the new code and stop the old ones after they finish their requests. Open /getusers again: it returns {"caption":"on the top","likes":50,"username":"ravi"}.

8. To stop gunicorn, run kill 4101 (TERM): it shuts down cleanly. Use kill -9 only if it is stuck.

10. Run gunicorn as a systemd service

Why: a --daemon gunicorn does not start again after a reboot or a crash, and you must hunt for PIDs to manage it. A systemd service fixes all three. This is the proper way to run a live app.

How:

1. Stop the --daemon gunicorn with kill <master PID>.

2. Create the unit file with sudo nano /etc/systemd/system/gunicorn.service:

   [Unit]
   Description=Gunicorn for pythonapp
   After=network.target
   
   [Service]
   User=ec2-user
   Group=ec2-user
   WorkingDirectory=/home/ec2-user/pythonapp
   ExecStart=/home/ec2-user/pythonapp/myenv/bin/gunicorn --workers 2 --bind 127.0.0.1:5000 app:app
   ExecReload=/bin/kill -s HUP $MAINPID
   Restart=on-failure
   
   [Install]
   WantedBy=multi-user.target
   

3. ExecStart uses the full path to the venv's gunicorn, so no activate is needed. There is no --daemon: systemd itself keeps it in the background.

4. Load, enable at boot, and start it:

   sudo systemctl daemon-reload
   sudo systemctl enable gunicorn
   sudo service gunicorn start
   sudo service gunicorn status
   

5. After a code change: sudo service gunicorn reload (the same HUP as section 9). After changing the unit file: sudo systemctl daemon-reload, then sudo service gunicorn restart.

6. Read its logs with sudo journalctl -u gunicorn.

11. Several sites on one nginx

Why: One EC2 server can host several apps and sites. Separate server { } blocks keep them apart, so you don't pay for one server per site.

What: one nginx can serve many sites, each in its own server { } block.

1. The first block in /etc/nginx/nginx.conf has server_name _;. The _ is a catch-all name: this default block answers requests whose host name matches no other block, for example a bare IP.

2. Add one block per site, each with its own server_name and its own proxy_pass or root:

   server {
       listen 80;
       server_name api.example.com;
       location / {
           proxy_pass http://127.0.0.1:5000;
       }
   }
   

3. A second Python app runs on another port, such as 127.0.0.1:5001, with its own venv and service.

4. Run sudo nginx -t and sudo service nginx reload after each change.

12. When something goes wrong

1. python: command not found: use python3.
2. ModuleNotFoundError: No module named 'flask': activate the venv, then pip install -r requirements.txt.
3. Permission denied during pip install: the folder was made with sudo; run sudo chown -R ec2-user:ec2-user ~/pythonapp, then pip install without sudo.
4. Commands fail after SSH reconnects: cd ~/pythonapp and source myenv/bin/activate again.
5. http://PUBLIC_IP:5000 does not open while testing: check host='0.0.0.0' and the port 5000 rule in the security group.
6. The nginx welcome page instead of your app: the location / { proxy_pass ...; } block is missing or outside the server block, or nginx was not reloaded.
7. 502 Bad Gateway: nginx works but gunicorn does not answer. Start gunicorn, or fix the port in proxy_pass.
8. nginx -t says unexpected end of file, expecting "}": a closing } is missing. Add it, run sudo nginx -t, then reload.
9. nginx -t says invalid number of arguments: a ; is missing at the end of the line it names.
10. A new route gives 404: the old code is still loaded. Run kill -HUP <master PID> or sudo service gunicorn reload.

When you're done practising, stop the EC2 instance.

13. The whole class on one page

1. A website returns whole HTML pages; an API returns data as JSON, key: value pairs in { }, and each app draws its own screen.
2. Hosting Python needs python3, pip, a venv, the app, gunicorn (WSGI) and nginx. yum, pip, npm and composer are package managers.
3. On Amazon Linux 2023: python3 -V, sudo yum install python3-pip -y. The command is python3, not python.
4. python3 -m venv myenv, source myenv/bin/activate, prompt (myenv). Never sudo pip; fix Permission denied with chown.
5. requirements.txt lists the libraries; pip install -r requirements.txt; pip freeze pins versions.
6. Flask: @app.route('/'), indentation matters, app.run(host='0.0.0.0', port=5000). The Flask server is for testing only.
7. gunicorn --bind 127.0.0.1:5000 --workers 2 --daemon app:app; without --bind it uses 127.0.0.1:8000. Re-activate the venv after SSH reconnects.
8. nginx is the reverse proxy: location / { proxy_pass http://127.0.0.1:5000; }, then sudo nginx -t and sudo service nginx reload. Workers with event loops, worker_connections 1024.
9. Behind nginx, close port 5000 in the security group.
10. New code needs a reload: ps aux | grep gunicorn, kill -HUP <master PID>; kill stops it, kill -9 only if stuck.
11. The proper way: a systemd unit with the venv's gunicorn, systemctl enable, sudo service gunicorn start|reload|restart, journalctl -u gunicorn.
12. server_name _; is the catch-all default block; add a server { } block per site.

14. Hands-on lab: a Flask app behind gunicorn and nginx

Why this lab. This lab builds the stack from the bottom up and tests each layer with curl before adding the next: Python, the virtual environment, Flask, gunicorn, then nginx in front.

1. Check Python and install pip
   • Command: python3 -V && sudo yum install python3-pip -y
   • You should see: Python 3.x, then Complete!.
   • Check: pip3 -V prints a version.
   • Why: Amazon Linux ships python3 but not pip. On this server the command is python3, not python.
2. Create the app folder and a virtual environment
   • Command: mkdir ~/pythonapp && cd ~/pythonapp && python3 -m venv myenv && source myenv/bin/activate
   • You should see: The prompt starts with (myenv).
   • Check: which python → /home/ec2-user/pythonapp/myenv/bin/python
   • Why: Each app gets its own libraries, so two apps needing different Flask versions don't clash.
3. Write requirements.txt and app.py
   • Do: nano requirements.txt with the two lines Flask and gunicorn; nano app.py with the two-route app from section 5.
   • Check: ls → app.py myenv requirements.txt
   • Why: requirements.txt lets anyone install exactly these libraries with one command.
4. Install the libraries
   • Command: pip install -r requirements.txt
   • You should see: Download lines ending in Successfully installed ... flask ... gunicorn ....
   • Check: pip list shows Flask and gunicorn.
   • Why: Inside (myenv) they install into this app only, and no sudo is needed.
5. Run it with gunicorn in the background
   • Command: gunicorn --bind 127.0.0.1:5000 --workers 2 --daemon app:app
   • You should see: Nothing.
   • Check: curl http://127.0.0.1:5000 → Hello from Python on EC2; curl http://127.0.0.1:5000/hi → Hi! This is the second page.
   • Why: app:app means the object app in app.py. 127.0.0.1 keeps port 5000 private, so only nginx on the same server can reach it; --daemon keeps it running after you log out.
6. Install nginx as the reverse proxy
   • Command: sudo yum install nginx -y
   • You should see: Complete!
   • Check: nginx -v prints a version.
   • Why: Visitors use port 80. nginx takes their requests there and passes them to gunicorn on 5000.
7. Add the proxy settings
   • Do: In the server { } block of /etc/nginx/nginx.conf, add the location / { proxy_pass http://127.0.0.1:5000; ... } block from section 8.
   • Check: sudo nginx -t → syntax is ok and test is successful.
   • Why: proxy_pass is the line that forwards each request. Testing before starting catches a missing semicolon.
8. Start nginx and open the app
   • Command: sudo service nginx start && curl http://localhost
   • You should see: Hello from Python on EC2
   • Check: With HTTP allowed in the security group, http://PUBLIC_IP/hi shows the second page in a browser.
   • Why: The same answer on port 80 proves nginx forwards to gunicorn. Port 5000 never needs to be opened to the internet.
9. Make it survive a reboot
   • Do: Create the gunicorn systemd service from section 10, then run sudo systemctl daemon-reload and sudo systemctl enable gunicorn.
   • Check: After a stop and start of the instance, curl http://localhost still answers (also sudo systemctl enable nginx).
   • Why: A --daemon gunicorn does not come back after a reboot or a crash; systemd restarts it for you. Stop the --daemon copy first so the two don't fight over port 5000.

15. Try at home

Recap

Revision, comparison and interview cards

Revise this lesson in a few minutes. Save the cards on your phone or download them as PNG files. The QR code on each card opens this lesson.

More cards: Ravi Sir's Cards.