Posts on deploying Python web applications with mod_wsgi are as follows. The list leaves out the release announcements, of which there have been many over the years.
Please note older posts may not reflect what I now regard as best practice, or may describe software which has since changed or been superseded.
This batch of posts covers getting mod_wsgi installed and pointed at the right Python installation, which is where most problems begin:
- What is the current version of mod_wsgi?
- Installing mod_wsgi on MacOS X with native operating system tools.
- Using Python virtual environments with mod_wsgi.
- Python module search path and mod_wsgi.
- Setting LANG and LC_ALL when using mod_wsgi.
This batch of posts is about mod_wsgi-express, which packages a working Apache and mod_wsgi configuration so that no Apache configuration has to be written at all:
- Introducing mod_wsgi-express.
- Using mod_wsgi-express with Django.
- Using mod_wsgi-express as a development server.
- Integrating mod_wsgi-express as a Django admin command.
- Packaging mod_wsgi into a zipapp using shiv.
This batch of posts deals with processes and threads, and why the mode an application runs under matters more than any other setting:
- Why are you using embedded mode of mod_wsgi?
- Use of threading in mod_wsgi daemon mode.
- Vertically partitioning Python web applications.
This batch of posts covers what to do when an application misbehaves under Apache:
- Debugging with pdb when using mod_wsgi.
- Requests running in wrong Django instance under Apache/mod_wsgi.
- An improved WSGI script for use with Django.
This batch of posts covers mod_wsgi 6.0.0, which added support for the free threaded build of Python and for a separate GIL per interpreter:
- Free-threading in mod_wsgi 6.0.0.
- Per-interpreter GIL in mod_wsgi 6.0.0.
- Free-threading vs the GIL in mod_wsgi 6.0.0.
- WSGISwitchInterval in mod_wsgi 6.0.0.
How the applications being hosted are meant to behave is covered separately under how WSGI applications and servers work.